Spring 2016 Projects - Section 1
  1. Entrepreneur Project
  2. BCBS of NC I
  3. DBGT
  4. Fujitsu America
  5. IBM
  6. Ipreo I
  7. Ipreo II
  8. Schwab Performance Technologies
  9. Undergraduate Research I

Project Archives


Spring 2016 Projects - Section 1

  1. Entrepreneur Project - Preformed Team
  2. Video games are at an interesting crossroads between becoming an increasingly public activity and a perfectly immersive, private one. We want to create a game that forces communication between two players, outside of the computer. We were inspired by games like Keep Talking And Nobody Explodes , and Space Team which rely on such communication between the players. Each player has either the information about a problem, or the ability to act on it, but never both. The game will also be accessible to people who are not hardcore gamers (as it will not be strictly console based), but will be more thrilling and engaging than casual games.

    Games of this new unnamed genre are creating a subdivision of the gaming universe. The type of person who plays Keep Talking is not the same as the hardcore, competitive gamer that would play League of Legends or Call of Duty. They are also distinct from the "purely casual" type of gamer that plays Candy Crush or Angry Birds. These social PC games are a new frontier that will create completely unique experiences from anything we've seen thus far. Rather than emphasizing and subsequently rewarding any individual player for their skill, these games create a cooperative bond between two players whose only path to success lies in efficient, tactical communication.

    Our game in particular will provide entertainment to an underserved and growing market of people who want a more involved gaming experience in a social, cooperative environment. Our main focus, therefore, will be tailoring the game to the needs of such players. We want to fill the social void in modern gaming while creating something incredibly unique and fun to play.

    Back to the top...
  3. BCBS of NC I
  4. Common Healthcare Platform: Provider App for Mobile


    In today's medical practices, Doctors typically must make decisions without the ability to quickly reference necessary information, because information is either not available, or is available only in non-mobile legacy solutions not designed for quick information retrieval. This project will focus on one specific use case, prescribing drugs and labs for patients. Doctors have shared that they prescribe drugs or labs without knowing the copay that the patient must pay. Once the patient reaches the pharmacy, they call the doctor wanting another prescription -because the prescription is more expensive than they realized, or is not covered by their specific plan.


    Doctors need a simple app that lets them see what the patient's health insurance plan will require the patient to pay. This app needs to be available on a mobile device so the doctor has immediate and constant access to it. (Note: there are web based tools available but they require a laptop, and a lengthy log in /navigation to reach the information required.)

    The student team will need to create a database that will contain what we call obfuscated data or non-identifiable data. This is realistic data that looks like the actual data used by BCBS, but is not attributable to any known person. This is required by HIPAA law which governs how protected health information (PHI) is used and protected. Students will be provided with a dataset of realistic non PHI data that can be used to populate the database.

    So for this project, students will develop a working mobile prototype app as follows:

    • Empowers a role (Doctors and medical staff) with easy access to key data.
    • Make use of leading low cost or open source technologies
    • The app will be designed for daily usage by doctors and medical staff.
    • The app will demonstrate the ability to access and display medical data, as follows:
      • Allow a doctor to look up a patient's name, and display the health insurance membership information to verify that patient's coverage.
      • Allow doctor to then lookup a drug prescription or lab procedure. In response the app will display the drug or lab, and the copay the patient will pay. This will allow medical staff prescribe a drug that is affordable for the patient's needs.
      • As a stretch goal, other functionality may be included as agreeable to BCBSNC and the students.
    • This prototype will not contain PHI, but will use realistic dummy data that has the same characteristics as standard health information but will not be attributable to any individual. BCBSNC will provide realistic dummy data sets as needed and/or guide the students in creating them.
    • Would prefer that students work on a weekly cadence. If possible we would like the prototype app to be reviewed/used by medical staff as early as possible, so that the students have the benefit of feedback from actual pilot users, and can refine the app further. BCBSNC will introduce students or otherwise make arrangements to ensure that medical professionals are able to review this app as it is developed.

    Key Takeaways Expected/Questions to answer

    • What functionality will be most compelling and used most regularly by doctors and medical staff?
    • What are the mobile design standards for designing a secure, HIPAA compliant but compelling mobile healthcare experience?
    • What set of technology capabilities are needed to enable this mobile healthcare experience?
    • How does this change/improve the user experience of patients and doctors? BCBSNC is interested in comparing/validating whether or not this app truly improves the doctor/patient experience so much that it really can be a high usage app/platform on which we could introduce additional functionality to drive health quality outcomes.


    Sponsor is open to leveraging the skillsets of the student team. If the team has had previous experience doing an iOS or Android app, and feel they could make it happen in the available time, sponsor is open to that. Also, Cordova/js, HTML5, Bootstrap kind of approaches could also work well.

    Back to the top...
  5. DBGT
  6. How well do you really know what's going on in a global company? If you follow the news from one publication, do you miss out on a tweet alerting you to a potential problem? What about the press release you just put out, how is that affecting the employees in the 2nd largest office? Determining what information is relevant and useful for companies is becoming critical for internal awareness. A solution to share that internally can improve the company's position on multiple fronts.

    The Assignment:

    We are looking for a group of dynamic students who can create a user-centric tool to help organize and view sentiment about our company in a rich and engaging way. Deutsche Bank can provide some representative data from our internal social network ( Jive ) that would be one of the data sources.. The others include Twitter and various news feeds from around the world. Students will use their course knowledge, ideas and technical expertise to create a dynamic solution that will lead to a better understanding of the big picture. For example, some of the questions that this interface could help answer are: "What is the latest external news about DB (social media etc.)? What is the latest internal news about DB (good or bad) in a quick and easy way to digest? Are there any important topics, trends happening in DB that everyone is talking about? What are the quarterly earnings for DB at a glance?"

    This Semester (Spring 2016):

    This semester the goal is to deploy a working version of the product in Deutsche Bank. The goal is to see the hottest topics and the mood surrounding the bank in an engaging way, which will be presented to our internal employees across the globe. Our team is here to aid and guide the students' workflow processes and design ideas. We are open to the students' input and new ideas or technologies that fit within a few technical limitations that the bank has. As far as front-end code, we recommend using openStyle, our front-end UI toolkit, which is based on Bootstrap.

    NCSU Student Experience:

    Senior Design students in the College of Engineering Department of Computer Science will have a unique opportunity to partner together over the course of the semester to create an information tool, as they would experience in real world product development. Additionally, students will have access to industry professionals to assist in the design, Agile/Scrum practices, and the overall developing/coding and testing.

    Back to the top...
  7. Fujitsu America
  8. Creation of Diagram Production Documentation

    Fujitsu America is one of the top three suppliers of retail systems and services worldwide. Using Microsoft's .NET development platform, these systems offer a high performance yet open platform that retailers as diverse as Nordstrom, RadioShack and Dressbarn are able to customize.

    Fujitsu's next generation POS, Market Place, has been released and Fujitsu is looking at ways to leverage its architecture to enable the creation of diagram production documentation and potentially, performance reporting.


    MarketPlace Store Application Design

    Fujitsu's MarketPlace is a SOAP web service based product. Each use case implemented by the applications within the product requires collaboration between multiple web services. During the design phase for Market Place UML sequence diagrams were used extensively to document the messaging required between the services. This helped to define the service interface operations and parameters, as well as prioritize the development of the services.

    However, over time as development proceeded and the service pattern became familiar, these diagrams stopped being maintained and fell into disuse. Now that we are entering engagements in which customer development teams may be involved, the utility of these diagrams for in ongoing documentation appears high. However, the system now has more than 450 service operations distributed across more than 230 service interfaces implemented by more than 120 services, and the task of creating diagrams, much less maintaining them, is daunting. The effort is only viable if it can be highly automated, and this automation is the focus of this project.

    Project Data for Automation of Diagram Production

    Two factors make automation of diagram production possible: an XML standard for the diagrams and detailed tracing that effectively documents the sequences. XML Metadata Interchange (XMI) is a public standard for representing UML diagrams and is generally supported by most modeling tools. Two variants of the standard (1.x and 2.x) are in general use in the industry. Each tool vendor can in turn extend the XMI specification to capture details specific to that vendor. The target vendor tool for this effort is Enterprise Architect.

    For tracing, MarketPlace has utilized extensibility points with the web service infrastructure of Microsoft's WCF and extensibility features SOAP. The MarketPlace infrastructure assigns each SOAP message a unique identifier at the message's point of origin. This identifier is then carried as a SOAP header throughout any subsequent service interactions for the lifetime of the message. MarketPlace also provides interceptors within the WCF SOAP infrastructure that have access to the SOAP envelope. These interceptors format information including the service interface and method along with the unique identifier and publish the result to the .NET tracing infrastructure. Configurable TraceListeners can then pick up the data and log it in a variety of ways for subsequent use. As a side effect the interceptors provide high resolution timing information about the duration of a service operation.

    Project Primary and Stretch Goals

    The primary goal of the project in its simplest form is to reformat the trace data into a UML sequence diagrams that can in turn be graphically displayed by EnterpriseArchitect (using the Microsoft Toolset and .NET development platform).

    The student team will be involved mostly in data processing, analysis, and visualization. Fujitsu America has already built the tracing into the system although it will be slightly extending for this project. Sponsors plan to provide the traced data and/or a system by which more can be collected.

    Data management is a key factor as well. The traces themselves may be large and contain repeating sequences. Ideally only unique sequences produce diagrams. Current tracing data may be inadequate and new data elements may be required to achieve the goal. Where repeating sequences occur, it may be useful to collect statistical results on elapse time of the operations to identify areas of performance concern. This would be a Stretch Goal.

    Back to the top...
  9. IBM
  10. IBM Services Asset Program: Enterprise Exception Handler (EEH)

    Open Project for NCSU: Pattern Engineering Development


    The Enterprise Exception Handling pattern provides a standardized method of reporting exceptions in the organization through the Enterprise Service Bus (ESB) that may be analyzed in the future. Most application and system exceptions are reported in an inconsistent manner and often reported in logs that are distributed across every node in the subsystem. The pattern addresses this concern by standardization and centralization of system-wide exceptions in a heterogeneous environment.

    Community: https://www.ibm.com/developerworks/community/groups/community/asset/eeh

    Repository: https://hub.jazz.net/project/arunava/eeh/overview



    The exception handling pattern has been one of the most effective methodologies for standardizing and reporting of exceptions for Java and Message Broker flows. However, thousands of existing applications find it difficult to manually incorporate changes to enable EEH in their applications. This project will provide the ability to scan and discover existing exception handling in the Java and Message Flows and present the developer to engineer their code with EEH by mapping these to the exceptions in the catalog. The scan and discover will present the developer with the option to accept/change and then replace the code. A simple UI will be required to accomplish this. This can be done as a stand-alone SWT UI. A stretch goal could be to convert that into an eclipse plugin if time permits. The scanned data will also be persisted in an XML so that the developer(s) can do this in multiple sessions.

    The replaced code suggestions will be presented with a checkbox to the Developer. That will give the option for the developer to edit the suggested code as well and accept or reject the change. This is a safety feature. Of course the developer will also be able to "Select All" and accept all changes. The sponsor will work through the different use cases with the student team -- the goal is to make the engineering of code perfected so that very little intervention will be required.

    Technology knowledge required: Java, Java Script

    Preferred additional optional knowledge: IBM MQ, IBM Integration Bus

    Back to the top...
  11. Ipreo I
  12. Creating Automated Tests without Automation Engineers

    The Software Test Engineering field is ever changing and ever increasingly important. Many companies have moved on from the days of no tests, undocumented tests and spreadsheet tests. Today's modern software companies employ new software testing methodologies and automated tools which help reduce risk while providing reliable and reusable tests. With this dramatic shift in the field, the skillsets of testing professionals has also changed to be more aligned with software developers. The position with these responsibilities that has emerged in the last decade is known the SDET (Software Development Engineer in Test), which also has provided a viable alternative career path for computer science majors who may not want to become software developers. This role now bridges the gap between manual software testers and developers as the SDET will write code (in automated test cases) that is robust, maintainable and provides direct feedback to the health of the codebase. With the gaining importance and popularity of the SDET role, we present the following project to expose the Computer Science students' concepts and tools needed for growth in Software Test Engineering:

    Students who elect to participate in this project will be first asked to dive into the world of Software Test Engineering. They will learn concepts and ideas that are not limited to: importance of software testing, terminology, levels of testing [unit, integration, functional, regression and non-functional] software testing ideologies/methodologies [risk-based testing, behavior-driven development] and automated testing tools/concepts [NUnit 3.0, Selenium and Protractor].

    Once the students have spent time with learning the concepts of Software Test Engineering, their project goal will be to help develop a tool to help solve the following problem:

    As an organization, we have the need to test scenarios against our application repeatedly to insure that the scenario still works as designed as we introduce code changes. There are two ways to do this, either by manually testing the application or by automating the testing effort using a test automation tool.

    When using the test automation tools, the user generally needs to be an expert in programming and programming best practices; though we have users that will be creating test automation whom do not have a programming background. As such, we want to build an interface and framework that abstracts the complexities of using a test automation tool from our users and allow them to interact with the test automation tool via simple actions, such as input, output, and verify.

    The application under test is web based and runs in multiple environments (Development, QA, Pre-Production, and Production). The testing tool selected must be able to interact with the objects in our application and perform actions on those objects like: select values from drop down, find record in a table, input values in edit fields, et cetera.

    To ensure the application is working as expected, automated test scenarios should also be created to verify newly created scenarios within the interface.

    Back to the top...
  13. Ipreo II
  14. Gamification/Training Project


    Ipreo is a privately held company with a market cap of over $1 billion. We make and sell software that helps drive all core processes and activities of financial markets. Thus, we refer to ourselves as a Financial Technology company, FinTech for short.

    We want to "gamify" our employee training. We want an engaging simulation, a computer game, that while playing also creates a fundamental understanding of how our software is used by the myriad people in finance, be they issuers, sellers, buyers, etc.

    An engaging game that takes our employees through the lifecycle of a company from the beginning, through a potential IPO, and beyond as a company continues to thrive and grow will help our employees learn how Ipreo's many software products are key to important and successful financial services and transactions. For example, two recently large and successful IPOs, Facebook and Ali Baba, ran on Ipreo software.


    In the world of finance you basically have four major roles or activities.

    • Issuers, typically investment banks, institutions that take companies public and/or help them borrow money by issuing (corporate) bonds.
    • Sellers of financial instruments (stocks, bonds, etc.).
    • Buyers of financial instruments.
    • Investor relations, typically performed by a corporate investor relations officer or IRO; someone at a publicly traded company who ensures people in roles described above have information necessary to look favorably upon a company's stock, to encourage the purchase of said stock at the highest possible price, and to make available to high end investors senior officers of a company (CEO, COO, CFO) to share insight into company strategy and direction.

    One of the challenges we face when we hire new people is training and so-called onboarding. It's usually not difficult to find talented developers. It's much more challenging, however, to find software engineers who are also well versed in the myriad idiosyncrasies of the world of high finance. Therefore, most of the time when we hire new talent we not only have to make sure they're fully immersed in how we develop software, but also fundamentally understand the customers who use our software, how they use it, and which features are most important depending on which persona a customer represents.

    Because, of course, a "customer" is not one person. A customer typically is a company that employs many people. To facilitate understanding these different people we create profiles of what a typical role requires. We call these profiles, personas. A CFO or VP will have different needs and expectations than a line manager of a department. An analyst at a bank is very different from a stock broker who is under tremendous pressure to sell, sell, sell, etc.

    The better our people understand our customers and how our customers expect our software to support their work, the higher the quality our software generally is. And the higher our employees' job satisfaction tends to be. No one enjoys doing something difficult if they don't at least have some idea how the result of their hard work is used or appreciated. It's one thing for your boss to say "good job." It's another thing entirely when a customer calls you and thanks you because your software just saved them two weeks of work and major grief.

    Thus, we need a good, repeatable way of training our employees, at least at a high level, about how the world of high finance works. And we need this training to be engaging, not boring, so people want to pay attention and really absorb and assimilate the information we want them to learn.

    Your mission, should choose to accept it ...

    We want to "gamify" our training. We want to create an engaging simulation, a computer game, that while playing it also creates a fundamental understanding of how our software is used by the myriad personas in finance. Since IPOs are things people know about and generally pay attention to, we thought taking people through the entire IPO lifecycle using a fun and engaging game would be our best option.

    And by entire lifecycle we mean from two people in their basement all the way to the opening bell on the stock exchange and beyond. When you start a company and have no or few employees your financial life is still fairly simple. However, the minute you accept money from private investors such as venture capitalists (VCs), those investors expect you to share how your company is performing using artifacts and language they're used. So almost immediately you'll begin looking for tools to help you do this inexpensively but also effectively. The last thing you want is for your board to replace you because they have no confidence in your financial management skills.

    And it grows and grows. Ipreo has software products that start all the way at the beginning of a company's life, and spans the entire spectrum of the needs of a company's lifecycle, including when they go public and become a large, successful publicly traded institution.


    The team that begins this project does not necessarily need to use Microsoft technology to help solve our challenge. However, it should use a technology stack that is widely used. Ipreo is mostly a Microsoft shop. There are exceptions, but many of our databases run on SQL Server, a lot of our code is written in .NET, our web servers run on IIS, and so on and so forth.

    For our front end, however, we're aggressively transitioning from ASP.NET to Single Page Applications (SPA) using libraries such as Angular to create a modern, engaging user interface that easily runs in any browser on any device, be it desktop, laptop, tablet or phone. We're excited about micro-services and have embraced this important concept as well.

    Moreover, since this project only runs over a semester, extensibility has to be built in up front. Ideally, you create a basic framework that teams in subsequent semesters and projects can build on and enhance. In a real way, the game itself begins as a software product; initially simple ("solve the problem") but over time larger, more sophisticated with more options and features, and with multiple teams continuing to evolve it.

    At the end of the day, though, the most important part is the creation of a fun, engaging game you're proud of having been a part of, and that our new employees agree helps them get up to speed faster and without having to sit through hours of boring presentations.


    You will not be alone in this. We will make available to you most of our knowledge and know-how. We'll help ensure you have the resources you need to be successful. And, of course, we'll appoint liaisons who will be easily available and will spend as much time with you as is necessary to make this project fun, amazing and successful.

    Thank you and good luck. We can't wait to see what you'll create ... ☺

    Back to the top...
  15. Schwab Performance Technologies
  16. RoadMapper

    Who We Are

    Schwab Performance Technology (SPT) is a subsidiary of Charles Schwab that builds comprehensive technology offerings for financial advisors to help them manage their business and their client's investments. A large part of SPT's technology team is based in Raleigh, NC. This team develops applications for desktop, web, and mobile platforms that provide industrial strength solutions using technologies and frameworks such as C#, Mongo, SQL, C++, HTML5, Angular.JS, JSON, and REST. We concentrate on the fundamentals of architecture, design, development, and quality assurance to build applications that stand the test of time which is critical in the financial industry.

    What SPT Gains From the Senior Project

    SPT is interested in engaging with the brightest students in top tier computer science programs. New projects have allowed us to open a number of positions for recent and upcoming graduates. We hope to establish strong ties with the best students during their senior year which could then lead to jobs opportunities when they graduate.

    These students will build an application that will help SPT improve how the company uses agile development practices. Schwab uses SCRUM development methodologies. One of the challenges is the ability to provide a roadmap view for our business partners who require longer term planning information that is not consistent with SCRUM practices. Our development teams have created an ad hoc methodology to provide this information but it is a manual white board activity that takes significant effort to transcribe to electronic format (currently Excel) and maintain.

    Project Roadmapper

    Project Roadmapper was started as an NC State 2015 Fall Senior Project. That team made significant progress against the first set of requirements building the base infrastructure for Roadmapper including the ability to enter most base information and a first version of the drag and drop capabilities. The Spring 2016 project will be based on the same requirements listed below. The intent is for this team to pick up the project from its current point, enhance the visualization experience, complete the retained data, and achieve the goals of Roadmapper automatically projecting sprint assignments and providing export capabilities. The team that takes this assignment benefits from the work of the Fall 2015 team but also gain experience working on both refinement of an existing application while adding significant new functionality that will greatly improve the user experience.

    SPT is proposing a tool that allows users to create visual representations of roadmaps and team layouts for Agile projects. Most SCRUM tools focus on epics, user stories, tasks, team velocities, sizings, and backlog management. While these are all important aspects to the methodology, there is a gap between the sprint to sprint view of SCRUM and the quarterly and annual view of projects required by business and finance to plan application development and deployment. The Roadmapper application is intended to bridge this gap. The tool will allow users to create SCRUM teams with specified capacities, manage backlog epics and/or user stories, establish complexities, relationships, and development needs from specific SCRUM teams, and most importantly provide a dynamic user interface that allows a team to quickly show what is required to deliver on a loosely defined set of epics. The project will deliver a working application with the intent that Schwab will use the application for future program estimation and planning.


    Entering Base Information and Settings

    Allow users to create the base information and settings required to drive Roadmapper. This will include: Sprint List Settings, Releases, Scrum Team Skills, Teams with staff and team's specific skill set, Products, Project List, and Epic Information.

    Views to Assign Epics to Teams and Map to the Roadmap

    The views are highly interactive and allow users to quickly build a high level roadmap.

    Automatic Assignments

    Hours are spent to manually populate the board. A major enhancement will be for the system to use priorities, epic information, and team information to automatically populate the board for an initial view that the users can then alter. This will include the ability automatically assign epics to teams, associate teams for epic distribution for improved velocity (e.g. team A and team B work well together so pair assignments when necessary), and provide the ability to lock "confirmed" assignments while allowing a reprioritized list to be readjusted automatically.

    Export to Scrum Tool

    Roadmapper is not intended to be a scrum tool. Once the plan has been set, the team, epic, and assignment information should be able to export to TFS (or Jira) to speed the integration into the scrum tool for user story and task management.

    Project Approach and Technology

    The project will be based on some of the technologies SPT has been using for product development. This list may be altered depending on the teams' existing technology strengths. SPT technologies may include:

    • C# will be used for backend development.
    • REST for web services
    • MongoDB for database storage
    • JavaScript and HTML5 for UI Development

    SPT strives to develop using best practices while remaining agile. We use the SCRUM methodology and will run the senior project within a similar methodology used by our teams. One mentor will be selected from our development team to be the primary interface with the project team, but other members of our staff will be brought in from time to time to assist with the project.

    Project Success

    Success will be based on the following accomplishments:

    • Participating using a SCRUM methodology to understand the benefits of agile development.
    • Requirements (epics and user stories) will be provided to the team by the SPT staff. The team will successfully groom the user stories to provide initial estimates.
    • Breaking down the user stories into logical tasks and providing task estimation. This will be used to prioritize features within the semester's time box.
    • Architectural and design documentation produced for data and user interface components. A variety of UML and white boarding documentation will be used.
    • Producing quality code (well organized, performant, documented)
    • Developing a test strategy for unit, component, and end to end quality assurance. Testing will likely be done manually but students can be exposed to the automated quality assurance system that SPT has in place for existing products
    • Working application completed and demonstrated to internal SPT staff. The goal will be for the team to participate in customer feedback session and generate a feature request backlog.

    Back to the top...
  17. Undergraduate Research I - Dr. Blair Sullivan - Preformed Team
  18. Many NP-hard graph optimization problems can be solved with polynomial-time algorithms if the input graph is "structurally sparse," a fact that has informed significant amounts of research in theoretical computer science and structural graph theory over the last decade.

    The parameterized algorithms that exploit this structure often follow a two-phase paradigm. First, the structural features of the graph are identified, frequently by computing a special decomposition of the graph. This structure is then used to guide the computations in the second phase (which often consist of dynamic programming). Unfortunately, it is often NP-hard to produce an optimal decomposition (or perfectly identify appropriate structure) in the first phase, so most practical pipelines use approximations and/or heuristics. Although a suboptimal decomposition will not affect the correctness of the solution found, it can have significant impact on the runtime of the second phase. The specific effects of variations in outputs from different first-phase constructions are not well understood (thus impeding progress on improved structure-identification methods).

    This project aims to design and implement a tool to aid users in their understanding of structure-based algorithms, and specifically the way that variations in the first phase are manifested in the second phase. This tool will not implement any specific structural algorithms itself, but will instead be a general analysis engine and GUI that can interface with an arbitrary implementation of an algorithm that uses the two phase paradigm. Two such implementations of structural algorithms will be used to demonstrate the use of the tool, namely CONCUSS and INDDGO, which are implemented in Python and C++, respectively. The design team will collaborate with the Theory in Practice research group, which will provide support from the developers of both open-source pipelines mentioned above as needed.

    The tool must incorporate the following components:

    • An interactive graphical interface that reports changes in the decomposition caused by the changes in heuristics and allows a user to compare two runs of the algorithm.
    • A set of visualizations of the graph structure which illustrate these changes
    • A modular design and well-defined API which enable easy integration with additional structural algorithms in the future (which may be in one of several programming languages).
    • Well-developed interface and modules for evaluating CONCUSS (including colorings and transitive fraternal augmentations), including potential identification of appropriate metrics for impact of edge addition on dynamic programming.
    • Working interface with INDDGO, including proof-of-concept-level visualization and tracing modules.

    At project initiation, the team will work with the Theory in Practice team to develop additional specific project requirements, and will be responsible for brainstorming to settle on a programming language and interface mechanism that will support the desired split use-cases:

    1. A visually engaging demo of structure-based algorithms for non-familiar audiences
    2. Testing and evaluation of hypotheses and/or new first-phase algorithms in an existing pipeline by knowledgeable researchers.

    Back to the top...