1 / 17

Post Mortem Review

Post Mortem Review . HFS500 Fall 2012. Course Goals. Be able to navigate systems development Familiarity with philosophies and methods of systems development their implications for HF & alternatives. . Familiarity with methods: A Check Goods and Others. Just Checking….

jimbo
Download Presentation

Post Mortem Review

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. Post Mortem Review HFS500 Fall 2012

  2. Course Goals • Be able to navigate systems development • Familiarity with philosophies and methods of systems development • their implications for HF • & alternatives \

  3. Familiarity with methods: A Check • Goods and Others

  4. Just Checking… • Model-based systems engineering • SysML, UML • DoD AF • Validity • Verifiability • Traceability • Incremental Commitment Model (ICM)

  5. 4.6.2.1.1 Crew Interface Usability-Nominal Crew interface usability shall be verified by analysis (TBR-006-056). An analysis shall consist of usability evaluations using 20 participants who are crew or representative of the crew population. Per usability evaluation guidelines, as described in "Usability Engineering" (1993)by Jakob Nielsen, participants will be asked to perform a set of high-fidelity onboard tasks in a flight-like simulator or mockup using the crew interface. The usability error rate will be computed as a percentage, (i.e., ratio of number of errors to number of task steps performed).The verification shall be considered successful when the analysis shows that usability error rate is less than or equal to 5% (TBR-006-072). [HS7066V]

  6. Goods • Effort, Creativity, Teamwork • Will definitely have winners • Best class so far—by far—at describing system development approach used • Probably also the best at incorporating additional analyses, developing additional artifacts, going above and beyond the basic report requirements. • High level requirements • Problem of change • Handle/Manage change • Flexibility in system design

  7. Others • Balancing project with other course objectives • Synching up class time with project work • Explaining conops, commercialization, and impact sections; SysML • Overworking you? • Not keeping you engaged • The divide between requirements and implementation

  8. Snowden’s Cynefin Framework

  9. Space-Based Infrared Satellite System (SBIRS)— Training System Requirements For Mission training, the training software must support the injection of simulated mission events on top of a live or recorded background data stream under instructor control and replay of recorded historic or simulated events, with X-Launch/SKREP simulator scenarios able to be modified interactively by the instructor.

  10. Navy Training System Requirement Given the potential that one or more pilots may lose situation awareness and need to know which aircraft are live, i.e., pose true safety risks, a person with exercise oversight shall have a means of revealing which aircraft are live and which are not.

  11. Reasons for Requirements • Communication, coordination, common ground • Researchers and builders • Development team and customers • Archive • Get paid • Anchor for system specs; Resource for managing scope & risk

  12. Problems with Requirements • Loaded term. You HAVE to build something that meets it. You DON’T have to build anything else. • If it doesn’t say “shall” it’s not a requirement • Criteria?? • People get carried away—on both the developer and the client side.

More Related