Spring 2016 Projects - Section 3
  1. Boeing
  2. Bronto
  3. Cisco
  4. LexisNexis
  5. SAS
  6. WebAssign

Project Archives

2001:SpringFall
2002:SpringFall
2003:SpringFall
2004:SpringSummerFall
2005:SpringFall
2006:SpringFall
2007:SpringFall
2008:SpringFall
2009:SpringFall
2010:SpringFall
2011:SpringFall
2012:SpringFall
2013:SpringFall
2014:SpringFall
2015:SpringFall
2016:Spring


Spring 2016 Projects - Section 3

  1. Boeing
  2. Configurable Security Analysis Tool

    Summary Description

    We have a large number of systems/applications within Boeing Business Systems, each with their own set of security configuration to define user access. Configuration includes usernames, which access the users have (i.e., list of tables and web pages they can access), whether they have update or read-only access, etc. This can make it difficult to quickly address questions regarding access to the applications and the underlying databases.

    This project is to design and develop a configurable tool that can display information regarding user security. Information will be provided (see below for list of items) regarding the underlying meta-data (table schemas and data) for the security configuration which should be utilized to address the inquiries regarding access. The meta-data will vary by application and will involve multiple levels, including parent/child relationships.

    This should be a web application and the students would be expected to choose the technology stack (with input and guidance from Boeing). Students should feel free to leverage any open source tools or code.

    The tool should be able to address questions such as:

    • What access does a user have?
    • Who has access to a particular page in the application?
    • Does a specific user have access to a particular page?
    • Who has read-only access to a specific table in the database?
    • Who has update access to a specific table in the database?
    • Etc.

    Key components of this project include:

    • Build a flexible, configurable tool that has the capability to show detailed information from multiple levels and about multiple objects, including parent/child relationships.
    • Configuration should be savable and persistent. The tool will be for reporting/analysis purposes, but will not update the actual security configuration.
    • Configuration Interface should be intuitive.
    • End-user interface should present itself dynamically based on configuration (no hard coded configuration).

    Information provided by Boeing will include:

    • List of Application or Database names to be included
    • Table schema information for the security configuration (list of tables and fields that define the configuration)
    • Sample data for the security configuration

    Back to the top...
  3. Bronto
  4. ElasticQueue

    Bronto Software offers a sophisticated marketing platform for its corporate clients, tracking billions of events per month. Customer events such as opens, clicks, and purchases (conversion) are recorded and analyzed in real-time and displayed to our customers to give them a clear view of how their campaigns are performing.

    Bronto takes in billions of behavioral events per month. The rates of ingestion vary by hour of day, day of week, seasonally, etc. Our queuing systems buffer this input so that our servers which apply business logic to respond to these events may process them asynchronously and just get behind by a few minutes/hours rather than crashing or rejecting some portion of the traffic.

    An example response to these events, at the human level, would be an email automatically sent to a shopper to offer them a discount on a product they've viewed but not purchased.

    Our main queueing solution is Redis. This project will implement a cluster of Redis servers that is Highly Available.

    The students will build on existing Bronto technologies to implement a queueing system that can automatically shrink/grow the queueing cluster as machines are added/removed/crashed. The EQ will have to orchestrate the efficient utilization of available hardware, ensure enough redundancy to lose no data when a server dies, and rebalance loads as servers are added or dropped. A REST API will also be required for manual cluster management tasks, e.g., making configuration changes and polling for status to be displayed on a monitoring dashboard.

    The project may be developed locally on whatever hardware the student team has available to them. They can run each Redis instance in a container on one machine, VMs, or network their machines together, whatever works. The speed and capacity of the cluster aren't important as those properties will scale up when placed on real servers. What needs to be demonstrated is the ability of the students' software to respond to changes in network topology (addition or loss of a Redis instance) and any monitoring/dashboard features that are implemented.

    Technologies: Redis, Java

    Back to the top...
  5. Cisco
  6. Large Scale IoT System Simulation

    Program proposal: Discussion of large scale IoT Sensor deployment with Cisco SME's and understanding the IoT deployment landscape from real world use cases. We propose that the students model a large scale IoT system and measure a limited number of options in deployment architectures and the related results. This will require domain specific research and understanding by the students as well as collaboration with Cisco SME's. A simulation program will be a necessary tool to quantify and qualify the differences in deployments taking into consideration several configurable variables. This simulation will provide a basic representation of the trade-offs for logic decisions to be made on architectural deployments. E.g., Fewer more accurate sensors are better than more expensive more accurate sensors in large scale deployment. [Consider smart building deployments or clean power generation].

    Requirements: Data/measurements. Leverage open data sources. We encourage NCSU to leverage real data from campus or existing use case. Cisco will help in terms of providing guidance and sensor data. Programming for modeling and simulation.

    Premise: Very large scale deployments are coming roaring our way (literally, drones and autonomous vehicles). No matter how well designed the individual components, their interfaces, and the communication infrastructure; something will fail in the system all the time. Hence, the issue is how to design and manage systems under failure. The toy example is Google - when it decided to use off-the shelf servers, Google realized that failures would be the rule, rather than the exception. Hadoop was an environment to make a large scale system work, and work well, under failures. I am talking now about systems that will more than order of magnitude more massive and more complex.

    Consider a massive deployment of IoT sensors - to measure pollution, humidity, nitrogen, temperature ... your pick - over a large area. Consider the sensors prone to failure (matter of measurement and reliability). Also, to a larger degree, the sensors acting as a "system" which may be prone to regular problems (power, network, failure, interference, etc). The issue is how to design the overall system to generate reliable data even in the face of failures. Some possibilities: use fusion techniques; to produce reliable (with error bounds) data over each sector; model the whole area as a random field, an use statistical techniques. Trade-offs of high cost, high functioning sensors with lower deployment numbers vs high density sensor deployment using lower cost, lower accuracy sensors (trade-offs). What is the cross-over line between cost/function?

    Tech focus areas:

    • Data Fusion
    • Machine Learning
    • Statistical analysis
    • Time-series
    • Random fields

    Additional Resources: TBD

    Back to the top...
  7. LexisNexis
  8. Break the Ice Social Graph

    Visualizing social web to understand human interactions

    Description. In a previous senior design project "Break the Ice" we implemented an API that would analyze tweets and categorize them into areas-of-interest (such as sports, entertainment, politics) enabling users who are intending to interact to have an idea for topics for conversation (hence breaking the ice).

    The goal with this project is to extend and expand the idea of breaking the ice to provide a visualization of the social graph. A core concept with social graphs is who-know-who (WKW). Being able to infer WKW and provide the context for that inference visually is the primary requirement. The context will be derived from the classification/categorization of the content in the social graph. The content will be the original posts from users, the other user they follow, or the users that follow them, the posts that they like (thumbs-up or heart icon), the posts they reply to, the depth of the reply chain and so on.

    More complex information can be gathered by extracting geographical nature of the relationships - if two users following each other are in the same geographical vicinity, then there is a higher chance of them having a face-to-face meeting or other forms of communication beyond online social tools (which would be important in pursuing a business lead).

    The social graph will extend across the popular social networks. For the context of this project let us limit interfaces to Twitter, LinkedIn and Facebook. These products have public APIs that provide mechanisms to navigate and extract content from the graph.

    Technologies. As a part of implementing this project a few technologies will come in use. The following is a list of some potential (but not limited) technology choices.

    • Programming language and platform
      • Java/J2EE
      • C# and .NET
      • Python
    • Graph Databases and APIs
    • Webserver
      • Tomcat or TomEE (enterprise edition)
      • ASP.NET 4.5
    • REST library
      • RESTeasy is a good Java library
      • ASP.NET 4.5 has great support for REST in .NET
    • LinkedIn, Twitter, Facebook APIs
      • The APIs are available for various programming languages
    • JSON serializer/deserializer
      • Java: Jackson is the best Java library
      • JSON.NET for C#/.NET
    • Database
      • NoSQL databases such as MongoDB
      • SQL database such as MariaDB, Postgres, MySQL
    • IDE
      • Java: IntelliJ Community Edition or Eclipse
      • .NET: Visual Studio (open source edition is available)

    Back to the top...
  9. SAS
  10. Interactive Dashboard for IT Operational Support Teams

    Overview

    SAS has the need for an interactive dashboard displaying the monitoring state of critical external facing resources. The dashboard is a component of our overall IT Event Management Process, based on ITIL best practices. ITIL is an acronym for Information Technology Infrastructure Library, which is a set of practices for IT Service Management (ITSM) that focuses on aligning IT services with the needs of business. It is the foundation for most IT organizations.

    The Project

    Utilizing technologies such as Amazon Web Services and ServiceNow, design an interactive dashboard that can be used by IT Operational Support teams to view the state of critical resources (aka configuration items) as well as drill down and help diagnose incidents as they occur. Examples of configuration items are routers, servers, applications, databases, etc. An example of an incident is when the server becomes unresponsive and the resulting service is unavailable to the users.

    High level requirements

    • The dashboard is to be an alert and notification receiver for critical configuration items.
    • It should be able to receive alert messages from monitors external to it (e.g., Nagios, Zabbix, Panopta, etc).
    • It should allow for users to dynamically work with specific details about a configuration item (e.g., incidents, changes, etc.) and therefore have the ability to drill down into ServiceNow for this additional information.
    • Overall Service Level Agreements (SLA) statistics should be available where applicable.
    • The dashboard should have an administration feature to allow for easy setup and changes.
    • The monitoring tools, feeding in the resource events are not part of this project but in order to integrate successfully the dashboard should allow RESTful web posting of status changes.
    • The dashboard needs to be designed with High Availability Principles in mind. Use of network load balancer, multi-region failover will be need to be considered. No one component should be designed with a single point of failure.

    Technology Available to Use

    Utilize AWS services such as S3 storage, Lambda and RDS for construction of an event router and then ServiceNow as the User Interface layers for display of resources. The construction of dashboard will require analysis by the student for best fit for purpose components from the available options. A Nagios monitoring install into an AWS EC2 instance would be used as an example of one of the many monitoring tools that would be used to feed alerts to this dashboard. The work can be handled remotely since these are all cloud based or software as a service options.

    SAS would provide a separate standalone AWS account and the student would be able to obtain a free personal developer instance of ServiceNow so the work would be isolated from SAS's corporate network.

    We have decided to extend this proposal by doing a comparison of two differing approaches, one based upon a mixture of various technologies within AWS and the other being the extension of an existing monitoring product that provides dashboarding capabilities. This is a typical exercise that we would go through to determine the best approach to a problem based upon existing technologies. A review and research spike would kick us off.

    Deliverables

    The outcome will be a Highly Available interactive dashboard that we can install and use at SAS. Hence it needs to be able to be packaged up (with documentation) for install. Besides the software components for installation there would need to be documentation covering operational components and user interface documentation.

    Benefits to Students

    Project exposes the Students to cutting edge industry technologies such as:

    • AWS Cloud and AWS services
    • ServiceNow IT Service Management Tool and custom application design
    • Experience with Open Source tooling (Nagios)
    • Use of scripting languages such as python
    • Designing for High Availability and redundancy.

    Project would also require the Student to gain valuable experience in the operational side of producing an application such as:

    • Installation of designed software (AWS CloudFormation and/or ServiceNow plugin design).
    • Source Code control
    • Documentation creation (User and Operational Support).

    Back to the top...
  11. WebAssign
  12. Toolshed

    Business Need

    WebAssign has many "behind-the-scenes" tasks that are run through various internal tools. These tasks involve everything ranging from changing ebook prices to updating question assets. These tools currently live in different locations on various systems which all have their own authentication methods. We need a system that will bring all of these tools together under one roof with a singular authentication method.

    Target Audience

    • Internal WebAssign employees that want a more efficient and centrally located platform for their various job related tools

    Requirements

    Authentication

    • Ability to authenticate user access to the system against an Active Directory server
    • Ability to control an individual user's access to specific tools through Active Directory
    • Ability to control an individual user's CRUD access within a specific tool through Active Directory

    User History

    • Ability to track a user's every action within the system (i.e. the user logged in)
    • Ability to track the context of a user's action within the system (i.e. the user changed value A in tool X to value B)
    • Ability for users with correct Active Directory permissions to view user actions within the system

    Tool Management

    • Ability for users with correct Active Directory permissions to enable and disable specific tools
    • Ability for users with correct Active Directory permissions to modify a specific tool's name, description, and any other field that is deemed relevant (based on your design!)

    Tool Access

    • Ability for a user to see which tool(s) they have access to
    • Ability for a user to interact with the tool(s) that they have access to

    General

    • WebAssign adheres to Agile principles of development, using Agile roles, artifacts and ceremonies

    Stretch Goals

    • Usage Statistics Tool
      • Implement a tool that provides statistics about usage of the system. These statistics can include what tools and functions within a tool used most, what time users typically access a tool, and how long users typically interact with a tool. This tool would be useful for determining areas of improvement that can be streamlined to improve employee efficiency.
    • Job Queue
      • The ability for a tool to schedule an action to take place at a certain time, and allow tasks to run outside the realm of a page request would provide immense benefit for the system. A companion example tool would be useful for showing off this functionality.

    Your Task

    You will design and implement a microservice based system that will host various WebAssign internal tools and authenticate WebAssign employees' access to said tools. The system's backend will be written in Go, and the frontend written in AngularJS. The system will use Active Directory via LDAP for authentication purposes. Your code should include tests and be extensible, maintainable, and well-documented. We recommend using an iterative Agile development style in order to ensure you meet the project goals.

    You will not be expected to write, integrate, or adapt any existing WebAssign tools for this project. However, including a User History tool and Tool Management tool is a suggested way to meet parts of this project's requirements.

    While we don't want to dictate how you design the system, we envision that each tool will be its own microservice. It is assumed that existing tools will be adapted or rewritten before being integrated into the system.

    Skills

    The team will be working with the following technologies and tools:

    We expect team members to have the following:

    • Familiarity with Web Development Principles
    • Understanding of unit testing strategies

    We would be pleased to have team members with the following:

    • Web Application Development experience
    • Go experience
    • Docker experience

    Back to the top...