1 / 25

Siemens Project

Siemens Project. Architecture Review – 2/16/2006. Perfusion Assessment Tool of Cardiac MRI. Valerie Barnhart – Project Manager Margarita Gurevich – Programmer/Tester Jason Salvo – Programmer/Tester. David Goldberg – Programmer/Tester Daniel Mirota – Client Consultant/Programmer

zoe
Download Presentation

Siemens Project

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. Siemens Project Architecture Review – 2/16/2006 Perfusion Assessment Tool of Cardiac MRI Valerie Barnhart – Project Manager Margarita Gurevich – Programmer/Tester Jason Salvo – Programmer/Tester David Goldberg – Programmer/Tester Daniel Mirota – Client Consultant/Programmer Robert Shemeley– Architect/Tester

  2. Overview • We are developing a system to determine points of interest on graphs from cardiac MRI perfusions. • The software will consist of two tools: • Tool 1: a graphical interface which displays the graphs, input data, selected points, and allows for user modification of points. • Tool 2: tool that is run which will take in the data and select the points of interest • Currently, doctors either determine the points by hand, which takes about 20-30 minutes, or use tools that take anywhere from 2 min – 10 minutes to determine the points • Our software will allow points to be chosen, on average, 4 times faster than previous available tools.

  3. Architecture – Logical (End User) • Tool 1: Two-Dimensional Graph Viewer - This tool takes as input one or more signal intensity curves and display them with axes and labels appropriate to the data. - The user can interrogate points on the curve for their coordinates and zoom in on sections of the curve to allow more accurate point interrogation and selection. - This tool interacts with Tool 2 via a Control Interface component, reading in its data, displaying it on the curve, and allowing the user to interrogate and change its selected points. - This tool must be able to save its display as an image in a format that can later be printed. - Tool 1 returns frame of interest data to Siemens’ proprietary software by means of the Control Interface component.

  4. Architecture – Logical (End User) • Tool 2: Frame of Interest Detection - This tool has no user interface. It receives data in the form of a signal intensity curve of the same format that would be supplied to Tool 1 for graphing. - This tool, using the data received, finds well-defined points of interest with 80% accuracy.* - This tool is expected to work only on data typical of a healthy heart, though the data may contain noise or other anomalies that cannot be predicted in advance. - This tool passes its data to Tool 1 for display and modification by the user via the Control Interface. * These frames of interest are detailed in a specification provided by the NIH.

  5. Architecture - Process • Tool 2 must be able to receive data from Argus, process it, and send new data to Tool 1, which in turn must be able to receive, display, and modify it internally. This is done through the Control Interface. • Tool 1 must be able to return confirmed data to Siemens’ proprietary application, Argus. This is also done through the Control Interface. • System availability: Each DLL and OCX is callable synchronously on-demand. • Tool 1 Response time*: Tool 1 user interface response time is designed to be under 5 seconds for initialization, loading, and displaying intensity curves. Point interrogation, selection, and movement have instantaneous response time. • Tool 2 Response time*: Tool 2 processes the data it receives and find all points of interest in under 2 seconds. • All tools will operate synchronously, and the Control Interface will be called synchronously by Argus, so there will be no race conditions as there is no multithreading. * Response times necessary to meet MOV and human factors requirements.

  6. Architecture – Physical • Target System Specifications - Intel Pentium 4 Processor - Mid-Range to High-End nVidia Graphics Card • Target System Software Environment - Operating System: Windows XP - Graphics API: OpenGL • No distributed processing, middleware, database systems, or other extended machine features are required. • Software will be run by a single user on a single computer and needs not interface with any networks. The computer will be located in an office, laboratory, or clinical setting.

  7. Architecture - Development • Prototype: Prototypes for tools 1 and 2 are developed using Matlab. • Target System Language & Compiler: Microsoft Visual C++ • Supplemental Graphics API: OpenGL • Prototype Build Process: Matlab Source Code -> Execute Matlab Interpreter • Final System Build Process: Visual C++ & OpenGL Source Code -> Visual C++ Compiler -> Visual C++ Linker / OpenGL Library Integration -> Executable

  8. Architecture - Development

  9. Architecture - Development • Error Handling • Tool 1 error handling will be consistent with typical behavior for Windows applications. If an unrecoverable error occurs, an error message will be displayed and the application will gracefully terminate. Current working data will be lost, but consequences of corrupt data or inaccurate display are much more severe than the user having to “start over,” or relaunch Tool 1, with original input data from Argus. • Tool 2 error handling is performed in two parts: - Unrecoverable errors (crash scenarios): Tool 2 returns an error code to Tool 1 indicating an error so that inaccurate data is not displayed, and Tool 2 gracefully terminates. - Inaccurate frame of interest selection: Tool 2 may be inaccurate in its point selection up to 20% of the time due to noise or anomalies in data. This is normal, and the data will be passed to Tool 1 where it can be corrected by user intervention via Tool 1’s user interface.

  10. +1 Business Scenario - Use Cases • This system will be used primarily by doctors to reduce the time that is needed and to increase the accuracy of selecting the points of interest for MRI Cardiac Perfusion. • The system will save doctors time and help them save lives. • Our goals: • To make our system 4 times faster then any current systems that exist for points selection. • The points selected correctly 80% of the time. In other words, users only need to modify the points 20% of the time.

  11. Use Cases (cont’d) • Simple Use Case: • User launches our toolset from Argus (internally, Argus calls the entry point of the Control Interface). • Tool 2 processes the curve data supplied by Argus. • Control Interface sends the curve data from Argus along with the output from Tool 2 to Tool 1. • Tool 1 displays the curve and frames of interest selected by Tool 2. • User reviews, modifies, interrogates, and ultimately confirms points of interest by clicking a Confirm button. • User saves a screenshot of the current graph display for printing. • Tool 1 returns confirmed frame of interest data to Argus via the Control Interface.

  12. Use Case Diagrams

  13. Complexity • The complexity of the system has changed. NIH informed us that the algorithm will not have to handle “abnormal” MRI perfusion data. • This greatly effects our system complexity, function points, schedule, COCOMO, etc. • These changes are shown in the following slides.

  14. Code Reuse/Open Source • We have found several C++ Libraries that contain functionality that is needed for our system. • This allowed us to remove some items from our function points since we no longer need to produce our own code for them. • For Tool 1, we are using NTGraph, an open source 2D grapher. We are reading and analyzing the code to determine its featureset and robustness.

  15. Function Points • Changes have occurred to our Function Points since last semester again during this semester for several reasons: • Narrowing of the requirements • Open source code found • Changes in complexity of the system

  16. Function Points (cont’d) Prior to our reductions of our function points, we calculated our Unadjusted Function Points to be 356, and Adjusted Function Points to be 406

  17. Function Points to LOC • This conversion cart is shown below • Thus for our system using the conversion factor of 53 LOC/FP since we will be programming in C++ we can find the estimated LOC for our system through the following formula: LOC = 53 * UFP • Thus we can solve this equation to find the LOC estimated for our system. LOC = 53 * UFP, where UFP = 189 LOC = 53 * 189 = 10,017 LOC From http://www.stsc.hill.af.mil/crosstalk/2005/04/0504Roetzheim.html

  18. COCOMO Effort/Staff Hours = a*(KDLOC) b Where KDLOC = thousands of delivered lines of code = NCSLOC/1,000 For our system we will use: • Semi – detached: a=3.0 b=1.12 • NCSLOC = 10,017 thus KDLOC = 10,017/1,000 = 10.017 Where the b coefficient is: • b > 1.0 means that diseconomies of scale exist (software development) b = 1.01 + 0.01 + ∑ωi ωi: risks of the projects Effort = 3.0*(10,017/1,000)1.12= 39.623

  19. Schedule We will be using the following Productivity per staff-month: • 500 SLOC for normal applications (low risk, on-line) To find the amount of time it will take to so a project you can solve: Staff-Months = LOC/(SLOC per staff-month) Thus, since we are estimating 10,017 LOC, we can find the amount of months it take to complete the project by plugging in these numbers Staff-Months = 10,017/ 500 = 20.034 Staff-months ** This tells us that in order to complete this project on time, that we need to about 15% of the code that remains to be completed needs to be found as open source or other useable code.

  20. Gantt Chart

  21. sQFD Importance IMPORTANCE RATING: (1) WEAK (3) MODERATE (5) STRONG (7) VERY STRONG (9) EXTREMELY STRONG Customer Needs Plot points on a graph 7 Save Time Fit a curve to the points 9 Pick important points on curved graph 9 Easy to understand controls 4 Plotted points are correct 8 Reliable Curve to fit points is accurate 9 Important points are accurately picked 8 Easy to compare data sets 7 Save diagram 5 Open previously saved diagram 7 Functions Run Tool 2 from within Tool 1 5 Clear loaded data sets 3 Change generated important points 7

  22. ICED-T

  23. Test Plan • NIH will be doing testing of our point finding algorithm throughout development. • Testing will be done continuously through the project as well as after the implementation phase • The main goal of testing during development is to assure requirements are met. Along with requirements, quality is measured as well. • We will be testing 4 categories for the completeness of the requirements as well as quality. These categories are: • Internal • Unit • Application • Stress

  24. Test Plan (cont’d) • Throughout this entire phase, we will be defect testing, debugging as well as validation testing. Our goal is to discover all system defects as well successfully demonstrate all the requirements are met. • The procedures for testing will go as follows:

  25. Thank you. Any Questions?

More Related