Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

System Design - Challenger Shuttle Disaster

No description
by

Christopher Long

on 27 May 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of System Design - Challenger Shuttle Disaster

Unreliable or
unavailable data Challenger Shuttle Air Disaster Introduction The Space Shuttle Challenger disaster occurred on Tuesday, January 28, 1986, when Space Shuttle Challenger broke apart 73 seconds into its flight, leading to the deaths of its seven crew members. The spacecraft disintegrated over the Atlantic Ocean, off the coast of central Florida, United States, at 11:38 a.m. Presentation Requirements stage The overall purpose of the system- The constraints placed upon the functions- The sensitivity of the functions to variation and failure- To ensure that the final decision to launch is fully informed The system must have a well estabilished means of gathering information and provide support for the final launch decision. Design System concept System technology System architecture N-square analysis Brainstorming HOW CAN STRATEGIC DECISION MAKING BE AIDED Time
Management Meetings Voting Brainstorming Hierarchy Electronically Democracy Information
Availability Expertise Feedback Face to Face Phone Email Light Dashboard FMA (Function Means Analysis) HOW TO ENSURE STRATEGIC DECISION MAKING IS NOT AIDED Inadequate
information a
vailable from
stakeholders The limitations of Function Means Analysis Inadequate research/product development Breakdown in communication • Missing functionality.
• Deselecting at the wrong level of generality.
This can result in the premature elimination of such solutions. In such cases it is important to ask the question “can we really decide between these solutions at this point?” If the answer is no, then the solutions are too lower level and should be aggregated into groups for which the selection/de-selection decision can be sensibly be made.
• Team membership: The quality of a Function Means Analysis depends on the idea generating capability of the team.
• Thoughtlessly defined or chosen selection/de-selection criteria: This needs time and thought about the criteria to use. If possible use criteria that have been validated in some way – such as the primary customer requirements for a Quality Function Deployment phase 1. No integrity in
heirachy/
management
structure Bias Decision
Making Inadequate
training Politically/ Monitory influenced decision making Negative Brainstorming Brainstorm Map Input your feeling, emotional, thought Input the weakness/disadvantages Input new possible ideas, out of box ideas input your possitive thoughts(benifits) Input Information, additional information needed input system, summary, conclusions Morphological Analysis Information Delivery Audiably Email Facetoface Paper Decision Making Process Information
Availability Stakeholders Method
of retrieval Decision
making
mechanism Decision recieved Information Gathering
Electronic Audiably Raw Data The Concept From using the tools that we selected we can design a system which would suit the problem scenario by looking at the various options, advantages and disadvantages of these options and the most viable of the options. Below is the concept we have decided on : Input This is a simple flow diagram to show the inputs and outputs of the system The system we have decided on is a type of dashboard which has a series of lights which are connected to inputs from the main stakeholders involved with the final launch decision. The main stakeholders individually use their expertise, knowledge and information available to them to evaluate whether the launch is safe according to their input to the launch. Buttons are pressed by these stakeholders to indicate they feel that the launch is safe and will display on the dashboard. The lights can be displayed in 3 states, red - not cleared, orange - clearance pending, green - cleared. The launch decision can then only go ahead when all the lights on the dashboard are lit. Lateral Thinking it is not necessary to include all the "hat" in every situation and there is no particular sequence as well. For this scenario(design and improvement), it is recommended to follow the step below: objective: to support the stratigic decision making for a final launch decision available information: currently the decision are made during the meeting and voting suggest new idea: an electronic dashbord that collect all the information to confirm the launch. Everyone incharge need to agree the launch. Risk and disadvantage:
in an event where there is no power, faulty bulb,electronics etc.
Require a professional skill to design the dashbord. idea to overcome the risk:
Use paperwork to sign, provide a regular maintainence, do the "6 thinking hat meeting" to decide the launch.
Hire engineer and programmer to design the dashbord design objective: designing the dashbord New ideas for dashbord:
Able to commuicate to the person incharge,
Fast and responsive ,
User friendly so that a new user can adapt it well without intense training,
Shows only the possition(engineer etc.) not names to prevent biasses Feelings to the new design: It is time efficient interms of decision making. NASA Meteorological branch
Chief Engineers
Government
Mission Control
Sub Contractors Design: Blue,Green,Red. Improvement: Black,Green; First idea: Blue,White,Green; Dashboard System Output Final launch decision made NASA Meteorological branch
To provide data on humidity, temperature and wind speeds for a safe launch.

Chief Engineers- Provides technical go-ahead for all the components, testing and research.

Government- Gives a supporting decision for the safe launch in the local area.

Mission Control- To check if all the procedures prior to launch have been completed.

Sub Contractors- To provide the go-ahead for all the components and testing launch equoment To check if the system is reliable and not prone to failure. Input Functions Advantages Disadvantages INFORMATION DISPLAY DESIGN - DASHBOARD
(illustration) NASA
METEOROLOGICAL
DEPARTMENT CHEIF ENGINEERS GOVERNMENT
(Eg. USA) MISSION CONTROL SUB CONTRACTORS
E.G MORTON-THIOKOL) GO FOR LAUNCH
CLEARED STANDARD LAUNCH PROCEDURES
AT MISSION CONTROL Time Efficient in gathering information for decision making
Unbiased, the decision is from all the main departments
Reliable, (e.g. is not prone to failure)
User-friendly (e.g. can be easily understood, users do not require intense training)
The final decision for the launch is a very safe one. High-maintenance (e.g. LED Failure, Power Failure and Internet Failure)
It is not completely risk-free (e.g. False Feeback, the dashboard may display a false positive)
Expensive to set up(e.g. the designers and programmers) Design Features Water-proof (e.g. coffee spills in the office)
All department dashboards are connected via the Ethernet to the main mission control dashboard
Users are only allowed to input their decision in a certain time period. To reduce mistakes.
There is a cool-off, which means that a decision can be altered after a certain period of time.
Every decision button has a safety latch switch, which will further reduce any accidental pressing. Meteorologist
Homeland Security
Director of Engineers
Marshall Space Flight Cente
Suppliers
Subcontractors
Flight Crew
Launch Co-ordinators List of System Stakeholders Quantified requirements Functional Requirements
Well designed management structure hierarchy - the management hierarchy must be read through in no more than 2 minutes by any person reviewing the structure.
Efficient time management - it must not take more than 20 seconds for the system to update with the feedback data from all the departments.
Quick and effective decision making - a decision must be made within 2 minutes of the feedback update coming to the information system.
Work with and communicate with all stakeholders - the system must include input from all the departments directly linked to the final launch decision
Carry out extensive testing and development - at least 20% of the costs of the information system must be put into testing and research of the system. Non Functional Requirements
Communication barriers eliminated - at least 95% of all data sent from the departments will be received by the intended recipient within the allocated time limit of 20 seconds.
Budget figure met - the budgeted finances for the system must not be exceeded.
Time deadlines kept to- the allocated deadline for the project completion and implementation must not be exceeded.
Research equipment (advances in technology) are utilised - the recommendations for the tools and design from the research team must be implemented for the final information system.
Skilled Personnel are utilised and not restricted - the technical personnel must have unrestricted access and time to analyse and develop the information system. Ensures correct system properties like:

Sub-contractors efficiently reports problems of components and provides testing
NASA meteorological branch make quick decisions with the government's full backing
Chief engineers and mission control provides information and testing
Safe launch made though the information dashboard display system Consistency Techniques Conclusion Gathering Stakeholders for our system!
Full transcript