1 / 17

Portfolio Management System Development: Team Overview and Key Insights

This document presents a comprehensive overview of the Portfolio Management System developed by our team. Each member contributed uniquely to aspects such as database structure, interface design, and system demonstration. The project utilized Visual Studio 2008 for the user interface and an Access database for data management, where we addressed both advantages and disadvantages of our chosen design. Our reflections on the project's execution highlighted efficient teamwork and challenges in documentation and coding practices. Recommendations for improvement include prioritizing documentation and adopting pair programming techniques.

colton
Télécharger la présentation

Portfolio Management System Development: Team Overview and Key Insights

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. Team Limited Scope Portfolio Manager

  2. Team Members • Yenlin Lai – Introduction and Basic Overview • Charlie Brown – Database Structure • Vinny Brown – Demonstration of Systen and Front End • Huan-Chieh (Jessy) Wang – Demonstration of Graphing and Summary

  3. IntroductionPortfolio Manager Description • Stand-Alone Portfolio Management and Tracking System • Designed and Implemented as a Single User System • User Interface and Middle Tiers Built Using Visual Studio 2008 C# • Graphics Built using ZedGraph Add-in • Data stored in Access Database with Stored Procedures and VBA Subroutines / Functions to Emulate a “Real” Database

  4. Basic Design • User Layer – Holds User Interfaces and Supporting Code • Business Layer – Holds Connection Objects, Security Code • Access Database – Single File Distributed with Executable Code Requires no Setup

  5. User Interface Design Accessed from Both Menu and Tabbed Form

  6. Database Overview • Choice of Access • Database Design • Entity Relationship Diagram • Advantages • Disadvantages

  7. The Choice of Access • It would not cost us any thing to use • How hard could it be to use “Database for Idiots”? • Vinny said, “Hey this works” when we first tested accessing Access objects from Visual Studio.

  8. Database Design • 8 Tables 3rd Normal Form • Keeps Data About Both Securities and Accounts • Supports many types of Securities • Trades Stored, but not Positions • Keeps track of Position History by Rolling up Trades • Supports Multiple Accounts, but Not Multiple Users per Account

  9. Database ERD

  10. Advantages • Easy to Attach to Project • The .accdb file Can be Included With Project – no End-User Setup required • User Does Not Need to Have Copy of Access on PC • Even Though Access Does Not Support a Scripting Language Like PL/SQL Complicated Queries Can be Replicated Using Visual Basic for Applications

  11. Disadvantages • It is Still an Access Database • Use of VBA Code Means Stored Procedures Will Not be Optimized • Connection to VS Code Not as Seamless as it Should be • Migrating to a Real Database Will be Made Tougher by use of VBA Code Even Though Access can Replicate Tables as an Interim Step

  12. Basic Features Demonstration

  13. Charting Design • Visual Studio 2008 Has no Built-in Graphing • 2 Options: • Use an Excel Object and Pass it Parameters • Use a 3rd Party Graphing Add-in • We chose ZedGraph • A dll that was Easy to Implement and Free • Unfortunately does not Easily Implement 3D graphs

  14. Charting Demonstration

  15. What Went Well • Team Performance - for a group that had been thrown together all members remained constructive and helpful throughout the project • Limiting Scope – forced team to concentrate on getting the project without wandering off course • Having Database designed early in the process allowed team to concentrate on application

  16. What Didn’t Go Well • Documenting While Coding • Could not Concentrate on Doing One Part • Would Document to the Code Instead of the Other Order • Group Tended to work Individually • Members concentrated on single portion of the Project • More Learning Would Have Occurred Using Pair Programming • Time Constraints Meant Too Much Attention Paid to Deliverables

  17. What We Would Change • Document First, Then Code • Use Pair Programming

More Related