LSU 10/09/2007System Design1 Project Management Unit #2.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Lecture # 2 : Process Models
Using the Crosscutting Concepts As conceptual tools when meeting an unfamiliar problem or phenomenon.
Protocol & Test Review Spaceport America Student Launch University/Institution Team Members Date.
Proposal Analysis Review NMSGC Student Launch University/Institution Team Members Date.
The Experience Factory May 2004 Leonardo Vaccaro.
Data Test Review Spaceport America Student Launch University/Institution Team Members Date.
The Architecture Design Process
Team Name Conceptual Design Review University/Institution Team Members Date.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
SE 555 Software Requirements & Specification Beyond Requirements Based on Weigers Chapter17.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
9 1 Chapter 9 Database Design Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel.
LSU 10/09/2007Risk Management1 Risk & Risk Management Project Management Unit #5.
LSU 10/09/2007Drawing a System Diagram1 How to draw a system diagram Project Management Unit #2a.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
LSU 10/09/2007Project Tasks & Costs1 Defining the Project Tasks, Cost and Schedule Project Management Unit #3.
LSU 07/24/2004Defining Project Tasks1 Defining the Project Tasks Project Management Unit, Lecture 4.
LSU 01/18/2005Project Life Cycle1 The Project Life Cycle Project Management Unit, Lecture 2.
Introduction to Computer Technology
LSU 07/07/2004Communication1 Communication & Documentation Project Management Unit – Lecture 8.
What is Business Analysis Planning & Monitoring?
Chapter 4 Requirements Engineering
S/W Project Management
INFORMATION SYSTEM APPLICATIONS System Development Life Cycle.
Cybersecurity: Engineering a Secure Information Technology Organization, 1st Edition Chapter 7 Software Supporting Processes and Software Reuse.
BSBPMG502A Manage Project Scope Manage Project Scope Project Scope Processes Part 1 Diploma of Project Management Qualification Code BSB51507 Unit.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Common PDR Problems ACES Presentation T. Gregory Guzik March 6, 2003.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Software System Engineering: A tutorial
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
Software Requirements Engineering CSE 305 Lecture-2.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
Software Engineering Management Lecture 1 The Software Process.
Testing Workflow In the Unified Process and Agile/Scrum processes.
Copyright 2008 Introduction to Project Management, Second Edition 2  Many people have heard the following sayings: ◦ If you fail to plan, you plan to.
LSU 01/17/2006Spring LaACES Schedule For the semester and the next few weeks.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Lecture 7: Requirements Engineering
Chapter 6 Supporting Knowledge Management through Technology
THE PROJECT LIFE CYCLE PROJECT MANAGEMENT LIFE CYCLE LSU 01/18/2005 PROJECT LIFE CYCLE 1.
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
PMI-Planning Process Group Lecture 08 Ms Saba Sahar.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
RBSP Radiation Belt Storm Probes RBSP Radiation Belt Storm Probes 12/25/20151 Flight Software Template for Instrument Critical Design Review Gary M. Heiligman.
Software Requirements Specification Document (SRS)
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
How the NCSX Project Does Business
SRR and PDR Charter & Review Team Linda Pacini (GSFC) Review Chair.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Copyright 2015 John Wiley & Sons, Inc. Project Planning Part II.
LSU v09/08/05SBC Overview1 Introduction to the LA ACES Student Ballooning Course A summary of the motivation, contents and status of the materials available.
Dillon: CSE470: ANALYSIS1 Requirements l Specify functionality »model objects and resources »model behavior l Specify data interfaces »type, quantity,
Software Engineering Process - II 7.1 Unit 7: Quality Management Software Engineering Process - II.
Information Technology Project Management, Seventh Edition.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Principles of Information Systems Eighth Edition
Chapter 33 Estimation for Software Projects
Software Requirements
Software Requirements analysis & specifications
Chapter 33 Estimation for Software Projects
How to draw a system diagram
CS 8532: Advanced Software Engineering
Requirements Document
Project Management Unit #2
Defining the Project Tasks, Cost and Schedule
Presentation transcript:

LSU 10/09/2007System Design1 Project Management Unit #2

LSU 10/09/2007System Design2 What is system design? High level design identifying the system processes, functional components and their interfaces Derived from system requirements Provides an overview of the project –Define the components that are needed –Establish how components “communicate” with other components –Determine how to modularize the project into discrete work packages –Identify critical interfaces that must be well defined Used to provide initial cost, schedule & resource estimates Usually little or few implementation details –As system design is refined, and lower level subsystems are included, implementation issues may need to be addressed

LSU 10/09/2007System Design3 System design steps Define project goal and objectives Develop the project system requirements Identify the major system components that satisfy the system requirements Identify the major system interfaces Refine the system design –Define subsystems making up each component –Specify interfaces between subsystems Establish management controls for the system interfaces

LSU 10/09/2007System Design4 Project goal and objectives The goal specifies the overall purpose of the project –Defines what one wishes to accomplish as a result of the project Objectives are discrete intended accomplishments during and resulting from the project –Science objectives describe the specific scientific results expected from the project –Technical objectives describe the specific technical accomplishments expected during the project Together the project goal and objectives define and constrain the project scope –Leads to defining the system requirements

LSU 10/09/2007System Design5 System requirements A document listing the constraints imposed upon and the results necessary from the project –The project goal as well as the scientific and technical objectives should be reflected in the system requirements Time spent on detailing the system requirements is worthwhile –A greater understanding of what is required facilitates design and implementation and improves the chances of success Initially focus on developing the high level scientific and technical requirements –Based upon current science knowledge, what is to be measured with what resolution and accuracy? –What constraints impose what technical limitations on your design?

LSU 10/09/2007System Design6 Initial System Design Development of the initial system design can, at times, go hand-in-hand with refinement of the system requirements –Functions needed to satisfy the science requirements define the initial system For example, to perform any science measurement –You will need a sensor (detector system) –You will need to power the sensor (power system) –You will need to read data from the sensor (data acquisition system) –You will need to store the data (data archive system) –You will need to control the sensor, readout, storage (control system) –You will need to analyze the data (ground data system) These functions will also need to have a set of requirements specified –For example, the power system will need to supply volts & milliamps to the sensor, data acquisition, archive and control systems

LSU 10/09/2007System Design7 Traceability Matrix Shows the relationship between requirements and the components that satisfy these requirements –Commonly used in software engineering, but has application to hardware as well –Used to assure that the system design properly addresses the project needs and does not incorporate any unnecessary components Format of the matrix can vary widely but generally includes the following for each requirement –Identification number –Description of the requirement –Description of the component that satisfies the requirement –Description of test that verifies the components meets the requirement One example is provided by the U.S. Department of Energy, Requirements Traceability Matrix Template Requirements Traceability Matrix Template

LSU 10/09/2007System Design8 Major System Interfaces An interface describes the linkage between two functions or processes Neglecting how your systems fit together can lead to disaster –NASA Mars Climate Orbiter failed in 1999 because ground systems used “English” units while the flight systems used “Metric” units! There are multiple types of interfaces –Mechanical: How systems physically fit together –Power: What voltage and current flows between the systems –Electronic: The characteristics of electrical signals between systems –Data: Format and content of information transferred between systems –Thermal: How does heat flow between systems –Software: How modules communicate with other modules or hardware The type and characteristics of all interfaces need to be identified and defined

LSU 10/09/2007System Design9 System Level Drawing Example High level overview of a balloon platform that could carry eight student built payloads –Primary subsystems are identified –Directionality and content of major interfaces are identified

LSU 10/09/2007System Design10 Refining the System Design After the major systems and interfaces are identified the subsystems are described –Each major function is composed of multiple activities, processes or modules each with a specific function of its own For example, the Power System in the previous slide has the following subsystems –Power source that supplies the energy for the entire platform –Separate supplies to convert the source power to the proper volts and amps required by the FCU, DAU, DAU Disk, Aux XTM and Cubesats Each of the subsystems has interfaces that need specification –How many of what kind of interface do the subsystems have? –Is the interface to another subsystem or another system? –What is the content of the interface? Traceability matrix should include these new subsystems

LSU 10/09/2007System Design11 Subsystem Level Example Subsystem design provides additional details –Major functional components are identified and expressed –Shows that system requirements are satisfied –Most important interface details are revealed Still little hardware or implementation dependence

LSU 10/09/2007System Design12 Moving to Design Specifics The system design refinement process continues by specifying the subsystems of the subsystems For example, the FCU supply in the power system might include the following sub- subsystems –A relay to turn the supply on / off by computer control –A DC / DC converter to provide the required voltage from the source power –An inline sensor so that volts and amps can be monitored in real-time by the computer With enough iterations the system design can evolve into an actual implementation –Actual components to use in the design start becoming apparent –Interfaces become very specific and well defined

LSU 10/09/2007System Design13 Refined Subsystem Example Implementation and hardware details are starting to appear Interfaces are close to being fully defined Next step would be full hardware and interface specification

LSU 10/09/2007System Design14 Controlling Interfaces Critical interfaces need to closely monitored by use of an Interface Control Document (ICD) –Written description of the interface that is modified only under specific, previously defined conditions and is used by team personnel for implementation Not all interfaces need to be controlled, but an ICD can be helpful during system design –Written specification of the interface –Obtain agreement between stakeholders on the interface characteristics Controlled ICDs should be used to help manage potential risks –When an interface error or mismatch could result in project failure –When stakeholders implementing the interface ends are separated in either geographic distance or time

LSU 10/09/2007System Design15 References Managing Requirements Website, Ludwig Consulting Services, LLC, U.S. Department of Energy, Office of the Chief Information Officer, Systems Engineering / Project Management website U.S. Department of Energy, Office of the Chief Information Officer, Systems Engineering Publications and Templates