30 September 2004PRIMA AOS CDR1 Data reduction library I. requirements Eric Bakker I. Requirements II. Design (Jeroen) III. Implementation (Jeroen) IV.

Slides:



Advertisements
Similar presentations
Companies can suffer numerous problems due to poor management of resources and careless decisions. In real-world decision- making, many organizations lack.
Advertisements

Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
PRIMA Astrometry Calibration and Operation Plan PRIMA Astrometry Calibration and Operation Plan VLT-PLA-AOS draft Scope of the Document 
July 11 th, 2005 Software Engineering with Reusable Components RiSE’s Seminars Sametinger’s book :: Chapters 16, 17 and 18 Fred Durão.
Unit 231 Software Engineering Introduction to SWE What is SDLC Phases of SDLC.
Unit 191 Introduction to Software Engineering The objective of this section is to introduce the subject of software engineering. When you have read this.
I.1 ii.2 iii.3 iv.4 1+1=. i.1 ii.2 iii.3 iv.4 1+1=
LGS-AO Performance Characterization Plan AOWG meeting Dec. 5, 2003 A. Bouchez, D. Le Mignant, M. van Dam for the Keck AO team.
PRIMA Astrometry Object and Reference Selection Doc. Nr. VLT-PLA-AOS Astrometric Survey for Extra-Solar Planets with PRIMA J.Setiawan & R. Launhardt.
The Waterfall Model A Case Study
29 September 2004PRIMA AOS CDR1 Welcome Eric Bakker Who is and will attend Objectives Agenda Specific tasks: –List of questions –Risk factors –Follow up.
I.1 ii.2 iii.3 iv.4 1+1=. i.1 ii.2 iii.3 iv.4 1+1=
Supplement 02CASE Tools1 Supplement 02 - Case Tools And Franchise Colleges By MANSHA NAWAZ.
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
Numerical Grid Computations with the OPeNDAP Back End Server (BES)
Data Processing and User Software Ken Ebisawa (Astro-E2 GOF) presentation and demonstration.
1 Shawlands Academy Higher Computing Software Development Unit.
Safety Driven Performance Conference 2013 Capstone RBMI spotlight: software roadmap and user advisory council Oswaldo Rodriguez Deputy Product Manager.
13 ° COSMO General Meeting Rome VERSUS2 Priority Project Report and Plan Adriano Raspanti.
Implementation Considerations Yonglei Tao. Components of Coding Standards 2  File header  file location, version number, author, project, update history.
Designing a HEP Experiment Control System, Lessons to be Learned From 10 Years Evolution and Operation of the DELPHI Experiment. André Augustinus 8 February.
DCS Overview MCS/DCS Technical Interchange Meeting August, 2000.
Distortion in the WFC Jay Anderson Rice University
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
CS CS 5150 Software Engineering Lecture 3 Software Processes 2.
Installation and Maintenance of Health IT Systems
Software Engineering Management Lecture 1 The Software Process.
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
Koji Murakawa (ASTRON) B. Tubbs, R. Mather, R. Le Poole, J. Meisner, E. Bakker (Leiden), F. Delplancke, K. Scale (ESO) Conceptual Design Review for PRIMA.
E-Science Data Information and Knowledge Transformation Edikt : e-Science Data, Information and Knowledge Transformation E-Science Centres of Excellence.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
SIMO SIMulation and Optimization ”New generation forest planning system” Antti Mäkinen Dept. of Forest Resource Management / University of Helsinki.
Bill Sahr EVLA M&C EVLA Advisory Committee Meeting December 14-15, EVLA Monitor & Control.
© ABB University - 1 Revision C E x t e n d e d A u t o m a t i o n S y s t e m x A Chapter 4 Engineering Workplace Course T314.
University of Southern California Center for Systems and Software Engineering Vu Nguyen, Barry Boehm USC-CSSE ARR, May 1, 2014 COCOMO II Cost Driver Trends.
Request for Proposal (RFP)
McGraw-Hill/Irwin Copyright © 2013 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 12 Implementing Business/IT Solutions.
WEEK INTRODUCTION CSC426 SOFTWARE ENGINEERING.
The Software Development Process
WG 6 and Support Activities Overview Status Report Reference Version and Implementation WG Coordinator and Project Leader: Ulrich Schättler.
HARPS Data Flow System Christophe Lovis Geneva Observatory HARPS-N PDR, 6-7 December 2007, Cambridge MA.
SDD/DFS A. Modigliani VLT 2 nd Generation Instrumentation Pipelines, 19 Apr ACCEPTANCE TESTS Andrea Modigliani.
20/04/02 - F.A.DMS/PS organisation 1 Proposal for tasks and schedule -Coordination is needed -Tasks -Tools -Topics -Which areas are not covered -Manpower.
Design and Implementation of Spacecraft Avionics Software Architecture based on Spacecraft Onboard Interface Services and Packet Utilization Standard Beijing.
COS PIPELINE CDR Jim Rose July 23, 2001OPUS Science Data Processing Space Telescope Science Institute 1 of 12 Science Data Processing
Software Engineering Issues Software Engineering Concepts System Specifications Procedural Design Object-Oriented Design System Testing.
ESO, 17 April 2007ESAC meeting1 ALMA offline User Test 5 Silvia Leurini, ESO.
Mountaintop Software for the Dark Energy Camera Jon Thaler 1, T. Abbott 2, I. Karliner 1, T. Qian 1, K. Honscheid 3, W. Merritt 4, L. Buckley-Geer 4 1.
WFC3 PIPELINE CDR Jim Rose October 16, 2001OPUS Science Data Processing Space Telescope Science Institute 1 of 13 Science Data Processing
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
PROGRAMMING FUNDAMENTALS INTRODUCTION TO PROGRAMMING. Computer Programming Concepts. Flowchart. Structured Programming Design. Implementation Documentation.
Request for Proposal (RFP) In response to the RFP – the first step is to prepare a proposal 1. Review Customer Requirements and come up with candidate.
CS646: Software Design and Architectures Introduction and Overview †  Definitions.  The general design process.  A context for design: the waterfall.
Slide title :40-47pt Slide subtitle :26-30pt Color::white Corporate Font : FrutigerNext LT Medium Font to be used by customers and partners : Arial HUAWEI.
LBC-OB Gui User Interface v 2.0 Stable Stefano Gallozzi & LBC-Team Stefano Gallozzi & LBC-Team © Copyright 2007.
LSST Commissioning Overview and Data Plan Charles (Chuck) Claver Beth Willman LSST System Scientist LSST Deputy Director SAC Meeting.
Duration: How long will a lecture take?
Software Engineering Management
From LSE-30: Observatory System Spec.
LSST Commissioning Overview and Data Plan Charles (Chuck) Claver Beth Willman LSST System Scientist LSST Deputy Director SAC Meeting.
Design and Implementation of Spacecraft Avionics Software Architecture based on Spacecraft Onboard Interface Services and Packet Utilization Standard Beijing.
Maintaining software solutions
UNIFIED PROCESS.
Software Requirements analysis & specifications
Software Quality Engineering
Chapter 12 Implementing Business/IT Solutions.
Databases, Web Pages and Archives
Gustaaf van Moorsel September 9, 2003
Instrument Performance Requirements
Presentation transcript:

30 September 2004PRIMA AOS CDR1 Data reduction library I. requirements Eric Bakker I. Requirements II. Design (Jeroen) III. Implementation (Jeroen) IV Operations

30 September 2004PRIMA AOS CDR2

30 September 2004PRIMA AOS CDR3 Categories 1.Scientific performance 2.Technical performance 3.User interfaces 4.Data flow interfaces 5.Quality control 6.Simulations 7.Trend analysis 8.Calibration 9.Software design 10.Software implementation

30 September 2004PRIMA AOS CDR4 Category 1/10 Scientific performance 10 micro-arcsecond calibrated data Verification of performance –sets of visual binaries –simulated data sets

30 September 2004PRIMA AOS CDR5 Category 2/10 Technical performance Processing time –Pipeline solution< 5 minutes (for 1 OB) –Nightly solution< 8 hours (full night of data) –Global solution< 5 days (for full data-set) Installation –self-contained, auto install –IDAF versus pipeline Documentation –Central WW-site on-line access –incode extensive description by developers Error handling

30 September 2004PRIMA AOS CDR6 Category 3/10 User interfaces Flexibility Settting constraints –insert spectrum –Doppler orbit etc. if available Anomaly handling –software limits on variables

30 September 2004PRIMA AOS CDR7 Category 4/10 Data flow interfaces Data flow in to the DRS/pipeline –ESO PRIMA OS product Data flow within the DRS/pipeline –calibration engine, format TBD Data flow out of the DRS/pipeline –IAU standard astrometric FITS

30 September 2004PRIMA AOS CDR8 Category 5/10 Quality control Quality control (both IDAF as pipeline) on the subsystem performance should be quantified –STS, MET, FSU, DDL Quality control on the data reduction chain –Long-term stability, repeatability Quality control on the observing efficiency –TBD

30 September 2004PRIMA AOS CDR9 Category 6/10 Simulations Sets of simulated data should be produced –3 sets These sets can be feed back to the DRS Each module should have a simulation mode

30 September 2004PRIMA AOS CDR10 Category 7/10 Trend analysis Determination of parallax Determination of proper motion Extensive (manual) trending of parameter A versus B, and other non-linear combinations.

30 September 2004PRIMA AOS CDR11 Category 8/10 Calibration analysis IDAF uniformly calibrates data over the period of the program Pipeline uses the calibration parameters of the IDAF (the calibration engine concept) Correct for dispersion effects Correct for polarization effects Correct for elevation effects Correct for the color of the star

30 September 2004PRIMA AOS CDR12 Category 9/10 Software design Allow evolution of DRS

30 September 2004PRIMA AOS CDR13 Category 9/10 Software implementation Version control Weekly builds Comply with ESO standards If no ESO standards available, define standards to be proposed to ESO

30 September 2004PRIMA AOS CDR14 Closing words Requirements do not provide new insights Requirements aim to define the deliverable Sabine will continue this work Next steps –Try to quantify the requirements