This project ended up being my capstone project for my Masters program at Santa Clara University.  I say “ended up” being my capstone, because this project was really a last minute addition to our class the final quarter of my degree.  My group had been working on the Fortune Launcher Project for the previous two quarters before our professor gave us the option to switch and work on this project.  Little did we know when deciding which project we wanted to pursue, that our professor was leading our hand.  Without giving us much of a option, we were going to do this project whether we wanted to or not.  His reasons being that this was more of a real world situation that would educate us on the ups and downs of the software development life cycle.  As our professor saw it, we had a customer who had requirements and we would need to traverse through the entire development life cycle to deliver this project on time and to the required specifications.  So, this article is kind of my postmortem for this project, as well as a way to showcase what we accomplished in just six to seven short weeks.

 EVCS Project Dashboard Example 1
 EVCS Project Dashboard Example 2


Our “customer” for this project was a previous professor of Santa Clara University, who was now working with BMW Research Labs in Mountain View.  Dr. Bräunl was looking for students to do some proof of concept projects, which if done well would be reviewed by management at the BMW Research Labs and possibly moved forward into development for commercial use.  There were in total seven projects that Dr. Bräunl wanted completed.  He originally presented them to in our second or third week of the final quarter.  All projects are based around electric charging station and vehicle statistics, to help enable BMW to make more informed decisions about charging rates, times and how best to distribute that information to their customers.  The project we ended up doing was providing statistical charging information to management for the six charging stations that BMW Research Labs has at their headquarters.

The Problem

The problem we were tasked with solving was providing statistical information about the EV charging stations at the Mountain View location.  Dr. Bräunl wanted to see when peak charging times occurred and on which stations, as well as if cars were actually utilizing the charging stations; are the cars on the charging stations actually pulling power or just sitting on the station taking up space.  To the left is the part of the project document that Dr. Bräunl presented to our class.  What is shown is only the project our class ended up doing (I didn’t want to show his other projects as I’m not sure if he was going to have future classes peruse them or if they are owned by BMW).  The reasoning behind wanting this dashboard is due to how energy companies charge for peak hours versus non-peak hours.  If the grid is getting hit hard power costs more.  If BMW can find a way to…

The Tech Stack

When deciding to take the project we had to determine the tech stack we were going to use.  I wanted to use Node.js, and presented it to our class, not really knowing much about Node. Only knowing Node.js is becoming widely adopted and it is known for being able to quickly iterate on client-server applications.  There’s nothing like trial by fire to help you figure out a new technology.  After a little research online we decided to go with Node, and use MongoDB as our database, we also saw that most people using Node used Express to created their web interfaces.  Without even realizing it we were almost using the MEAN stack.  When we presented our tech stack to our professor, he kept asking about Angular.js and where it fit into our decision.  I, as well as the rest of the class, didn’t get that he was pointing us in the direction of the MEAN stack.  Numerous times he asked us about Angular, but we just weren’t getting it.  We never did get it… We didn’t use Angular.js in this project, but we should’ve.  Looking back now it would have made things a whole lot easier to deal with, but such is life.  Our persistence that we didn’t need Angular was all part of the learning process (and why the A in MEAN is X’d out in the picture on this post).  Now that we had a plan it was time to officially start this project.  Most would think this meant we would start coding because we were already behind the eight ball at this point, I think we were at like week four of the ten week quarter, but that wasn’t the case.  Because this was a software engineering capstone class we needed to go back an re-visit every step of the software development life cycle.  Granted, by default we needed to use the agile methodology to even have a shot of delivering a final project that would work.

Context Diagram EVCS Project

The Software Development Process

The software development process as it was taught to us is first analysis, second design, third implementation or coding, fourth testing and fifth maintenance.  All of these steps or phases were visited in some manner during this project.  We had started the analysis step without even realizing it, while debating if we were going to take on the project.  We got our customers initial requirements, but needed more information than the simple project description could offer.  We met as a class with Dr. Bräunl to flesh out all the requirements and interfaces needed to make this project feasible.  Because of the quick turn around time of this project, we defaulted to the agile development method.  This was done so we could accomplish weekly sprints to status where we were with the project.  Half the class focused on the documentation of the analysis phase, while the other half focused on gaining and understanding of the technology stack and building out prototypes of specific parts of the project.  I mainly focused on the database schema and implementation, SOAP API implementation to get the data for the database as well as front end UI development.  While others focused on graph creation using the D3 library.  We were doing the analysis and design steps in parallel, providing status updates every week.

Download (PDF, Unknown)

System Requirements Specification EVCS Project

After we had a firmer grasp on the requirements and interfaces for the project we moved into the implementation phase of the project.  This was an exercise in patience.  Some members were on one page while others were on a different page.  As with any software project we hit road blocks because of this.  We ran into issues with API data consistency, data manipulation which lead to wrong output, and finally we had issues with communication between client and server requests.  We had created the individual parts, but didn’t focus on how the interfaces could communicate.  This is where we should have listened to our professor and dug deeper into Angular which would’ve made our lives a whole lot easier and in the end our project a whole lot more modular.  One thing we didn’t get to accomplish with this project was a strong test plan.  The testing phase mostly consisted of manual testing of our dashboard.  Although not ideal, we were crunched for time and didn’t have the resources to create let alone implement a solid test plan.  If we had to do it all over again I would have opted for test driven development to make sure that when individual pieces came online and were integrated into the main line that they wouldn’t break working code, but that’s more for later in this post… The final phase we didn’t do, but rather provided concise documentation to BMW for future interns to read, understand then maintain our code.  As with testing time constraints didn’t allow us to create as detailed documentation as we would’ve liked to, but all of these glossed over steps show just how important the analysis and planning phases of the software development cycle truly are.