We just finished the Final Design Review event for IPPD. It was an amazing experience and a great way to cap off an amazing experience with IPPD. It was really fun to see all the work the other teams accomplished and showcase our work to our liaisons. The event was also open to the public so we were able to show our project and our work to many people who were excited to learn about ECM systems and security.

We also were able to showcase our demo to our liaisons for the first time and were really glad to hear all their positive feedback. The team also received a lot of positive feedback about our overall performance over the past year and a lot of feedback and questions from liaisons for other projects.

Overall, we have had an amazing time in the IPPD program and have thoroughly enjoyed working with our Raytheon liaisons, our coach, and the IPPD staff. It’s an experience that we would all easily recommend to anyone else looking for a career in engineering, and it prepared us very well for our upcoming careers.

This post serves as a quick introduction to our project and supplementary information about our poster. Team ReptileRepo is working with Raytheon Technologies to replace their existing enterprise content management (ECM) system with a newer and more modern solution that meets their needs for future development and scalability.

ECM systems are software systems that allow companies to easily store and manage their digital documents. Some examples that you might be familiar with are Microsoft OneDrive or Google Docs. The system that Raytheon needs, however, has much more strict requirements and needs to enable them to securely store their sensitive information.

Our system has to follow the strict access control requirements that Raytheon has provided us. Each user has their own associated groups and security roles. When accessing a file, these roles are checked to ensure that the user has the correct requirements needed in order to access the file.

To describe these security requirements, every file has its own associated metadata. The metadata gives things like the security level, project name, or any additional security information needed for the access control system.

To upload files securely with their associated metadata, the team created a custom file upload application that utilizes the ECM systems’ application programming interface (API). It ensures that all uploaded files have the correct metadata. By ensuring this, the system is guaranteed to correctly assign access control requirements for every file. The team also created a custom frontend web application that interfaces with the backend file upload app to make uploading files much easier for the Raytheon engineers.

Finally, the system is integrated with Microsoft Active Directory, which is where the users and user groups are created and stores. This makes our ECM system much easier to integrate with Raytheon’s existing software and hardware. The system we created currently uses a PostgreSQL database, but it is easily exchangeable for any other database technology (Microsoft SQL Server, MongoDB, etc.)

This week the team has been working on preparing for the upcoming FDR event. We’ve been working on finalizing our poster and presentations and we are finishing preparing all of our work to be ready to present to our liaisons. Since our project is mostly software, we’ve also been working on documenting all of our work so that Raytheon engineers can easily replicate our work in the future.

In addition to documentation, we’ve been working on writing user tutorials for our system. A lot of ECM systems use custom terminology for their features, so we realized that it might be hard for a first-time user to understand the different things that the system can do. We’ve been working on writing tutorials for uploading files, searching files, accessing metadata, and configuring roles. Also, since our project focuses a lot on integrating with other technologies like Active Directory, we’ve been consulting their user manuals and adapting them to better fit our project.

As we are coming towards the finish line of our project, we are finalizing some of the last aspects of our project and getting things ready for when we turn our work over to our liaison engineers. This week we have been finalizing all of the product testing for our system and work towards integrating our frontend web application with the system. We were able to integrate the login system with Active Directory, and we were able to successfully upload and view files through our frontend.

The reason we designed the custom frontend application was to give Raytheon engineers the ability to upload files to the system and have an application automatically verify that the metadata is properly formatted. Before, when uploading files it was possible to have incorrect or incomplete metadata. This system now guarantees that all uploaded files are properly formatted and that the system can properly assign the access requirement rules on them.

This week we finished the 2nd IPPD prototype day and we had an amazing time. Our presentation went really well and all the hard work we put into ensuring the demo would work payed off! We also gained some extremely valuable feedback from the judges that we will use going forward in our final design review.

Alex was able to get a virtual machine running on his laptop that had a small demo version of our full system in the lab. The prototype system also had an instance of Active Directory running, which allowed us to demo one of the most important features of our project. Our file upload application worked wonders during the demo and the judges were happy to see how much progress we have made after the setbacks we had at the beginning of this semester.

This week the team has also been working on our FDR draft, which is the final report for IPPD. It’s extremely important that we collect all information and documentation on our project, so we’ve also been working on writing as much as we can about the work we’ve done. Since our work is supposed to be reproduceable by Raytheon, we need to provide them with good documentation so that they understand how we made our prototype. Thankfully the ECM we are working with has extremely good documentation, so we don’t have to start from scratch.

Last week was spring break and the team enjoyed some much-needed time off from school and work. We used the time off to recharge our batteries so that we can continue working on.

This week, we accomplished a lot on finalizing our testing plan and implementing some unit tests for the ECM API applications. During the course of our project, we have developed a custom file upload application and a custom front-end web application that both make use of the API and require automated testing to ensure that they are guaranteed to function as expected.

Now that we’re back from break, the team also worked a lot on finalizing our prototype for next week’s prototype inspection day. We’ve been working on ensuring that we will be able to present our system to the judges and that (hopefully) everything will go well. One of the problems we’re facing is that our system is isolated in our lab and it’s difficult to get remote access to it from UF campus. Since the system is containerized, an easy workaround would be to clone the system on our of our laptops and demo it from there. Although it might be slow for the demo, this is likely the way that we will do it moving forward.

This week the team focused on researching different methods to test our ECM system. Because we are using an off-the-shelf product, there are many tools available to help us with testing the ECM. For testing the complicated access control requirements and file permissions, we can use the API.

There are many ways to test code, but since we’ve done most of our API and backend work using Python, we have been researching different methods and strategies for testing our system using the Python API. One of the easiest ways to test a Python project is using the testing library Pytest. It enables us to write as many tests as we need and Pytest will execute them automatically and give us a readout of which tests passed and failed. Since our tests have to be performed on our system, it’s also possible to configure the tests to undo any changes they make to the ECM when they are done. This ensures that none of the tests can break anything for any of the other tests. When we’re finished, all we have to do is launch the application, run the testing script, and it will handle the rest.

This week the team presented our work in the QRB 2 event. We had accomplished a lot on the project since the last presentation, so we were very excited to showcase what we’ve been working on and get some feedback. Now that we’re in the final stages of our project, most of our future work will be on testing the system, finalizing the security groups and roles, and gathering feedback from our sponsor liaisons.

Speaking of finalizing security groups, we made great progress this week on our custom file upload application. It’s now able to upload files to specific folders based on their assigned clearance level. It’s also able to set file permissions based on many different values that are stored in its metadata. One of the most important aspects of our project was that uploaded files are separated depending on their clearance level so this was an important milestone. We’ve also finalized the method we will use to organize the files in the system. Before, we were placing all the files in the same upload folder and setting permissions on each file accordingly. Now we’re moving files to corresponding folders based on their categories and setting permissions on the folder itself. This is much more efficient than our previous solution and it will allow us to be more flexible when developing our upload application further.

This week we finished work on the initial prototype of our file upload application. It allows users to upload many files at once and along with each file, it tracks and uploads their corresponding metadata. Metadata is stored in a separate .json type file. In creating this application, we learned a lot about the process of using the ECM API and integrating it with custom applications. We created the application using the Python programming language, but the API can theoretically be used with any programming language.

The custom application that we made will also work as the grounds for further development using the ECM API. We plan on testing the ECM’s security and integrity using API calls and simulated interactions on the browser. Also during the development process, we learned a lot about user authentication and application security that will hopefully enable us to ensure that our custom application is fully secure and meets Raytheon’s requirements.

This week we’ve been working on integrating a custom application to work with our ECM system. We’ve been looking for some solutions on how to upload custom metadata to the system, and were not able to find any so we are resorting to creating a custom solution using the system’s API. The API allows us to create custom applications that integrate with the system and allow us to make changes to the settings, create users, create groups, and even upload and download files. Creating a custom application will also allow us to explore integrating it with our frontend demo that we have been working on.

Also this week we were able to integrate the ECM with Microsoft Active Directory. This will allow us to have a single source of truth for all users and groups and will allow our work to integrate with Raytheon’s systems more easily. Active directory also allows us to add single-sign-on functionality to the system which means that if you are logged in with the same Windows account on your computer, you don’t even need to sign into the ECM system and it is all handled automatically.