Each portion of Edison Co.'s design and development process faced its own, unique challenges. By breaking down the project into smaller, manageable bites to assess, the group hopes to provide some insight for Ms. Mason and future PLTW students.

In order to get an idea of what problem Edison Co. was actually trying to solve, the group first did a fair bit of background research. From this information, each group member assembled a problem statement using the "Five Facts" model. Each problem had to be specific, and contain its own facts to support the statement itself. Overall, Edison Co. does believe that each member presented a compelling, engaging statement. This gave the group a wealth of options to choose from in the next step. Creating a problem statement is crucial to defining the problem, but just as important is choosing amongst the statements available. For this, a matrix was employed, as shown in Matrix 1.

Overall, the matrix employed to decide between statements was pretty accurate, and weighted well. That said, Edison Co. believes that it would have been worth increasing the weighting of whether or not the problem was engaging enough. As the project progressed, it definitely felt like there was a period around Element D where the group lost a bit of interest in the problem. This engagement picked back up with the start of prototyping, but that brief loss of interest made planning a bit difficult. As such, when defining the problem, the group strongly suggests landing on an option that is as engaging as possible, and weighting that heavily in the matrix.

At the end of the day, Edison Co. ended up going with Ely's sleep problem. While the problem might have lost the team's interest for a bit, there were numerous benefits to it that outweighed this one issue. Namely, the problem was plenty specific enough, while also being broad to allow for a number of solutions. This is evidenced by the breadth of brainstorming that occurred in Elements C and D. But there was by no means an issue of the problem being too wide-stretching. The group always felt like it knew what it needed to be focusing on. In this regards, the problem was defined perfectly, with just enough specifics but not too many. Any other group should shoot for this goal.

Of course, with a problem in mind, the next step for Edison Co. was to delve a bit deeper into the issue, which was exactly what the team did. In terms of general or non-technical information, most came in the form of Existing Solutions research. While Existing Solutions are generally considered technical, due to the user-friendly and overall basic nature of the alarm clock, Edison Co. has categorized them as General Research. Jace and David were assigned to this task. Usually, products were acquired via a Google search, which was probably the most efficient way to go about things. When working on Existing Solutions, David and Jace really tried to avoid ruling out ideas before they'd been considered, and this is a philosophy Edison Co. highly recommends future PLTW groups to adopt. What exactly is meant by this? Consider the fact that an air conditioning unit was included in the Existing Solutions document. David and Jace thought outside the box on this one, realizing that an air conditioner on a timer could potentially be used to cool a room in the morning, waking the user up in a non-jarring way. Obviously, the idea has flaws, but it is certainly a viable and pre-existing solution. In fact, it inspired David's cooling bed, a particularly interesting idea, in the brainstorming section of the project. Just because a particular product doesn't seem to immediately overlap with a given problem, it is still worth considering. When analyzing the market, there should be no "stupid idea." By applying this principle, Edison Co. was able to come up with quality Existing Solutions research, providing a wide breadth of ideas to inspire future design. Some of the products members expressed that they'd even be interested in purchasing themselves, such as the Clocky (Figure 2) and Ruggie (Figure 3).

In terms of research validating the problem itself, most of the sources gathered were technical research papers, as to be covered in the following section. Edison Co. definitely appreciated that Ely chose to largely verify his problem using research papers. It provided a bit stronger validity to the issue, allowing Edison Co. to trust that their solutions will be based on actually facts. Several articles from user-friendly sources such as WebMD were employed. While Edison Co. does not always recommend the use of such sources to future groups, they felt it was justified here as articles were verified by experts.

Quite a lot of technical research supported Edison Co.'s problem and design process. Early on, Ely used a number of research papers to support and validate the problem at hand. Even documents that were not published research papers were often posted on sites associated with scientific research, or proven to be verified by medical experts. It is definitely important for any group to spend a lot of time on technical research for the problem itself, and Edison Co. as happy that they did. A problem can easily die right out of the gates if the justifying research is only half-heartedly assembled, and it is realized later that the problem is, in reality, not as relevant as the group had originally estimated.

Next, Edison Co. moved on to a second form of Existing Solutions research: patents. Overall, the group found this style of research to be far more difficult than the prior Existing Solutions. The US Patent Search tool had a very poor interface, making it difficult to discover new patents. Google Patents was a bit easier to use, and Edison Co. would definitely recommend a future group at least try out Google Patents before defaulting to the USPTO's tool. Most of Edison Co.'s patents were found via Google Patents, which also indexes some international patents, a nice benefit. Additionally, Parker specifically would advise one to stay grounded when investigating patents. It's important to remember that patents are developed by professional engineers, often backed by companies with large sums of money at their disposal. While it's a good idea to get a feel for what types of patents exist in the market, a PLTW DD group should not expect that their project reach such heights. There were a couple of features Parker noted within some patents, like the biometrics monitoring of Figure 1, which he really wanted to pursue, but simply weren't feasible for a high school project. Overall, Parker admits he was probably a bit naive in this regards, and cautions future groups against a similar pitfall, as it can be pretty time-consuming to delve into the complex features highlighted in patents.

Lastly in the division of technical research, there was the Industry Market research completed by Parker. This research was relatively routine, but also the most time-consuming of all the assignments due to the need to consolidate a variety of sources. At times, research became difficult because many of the documents were behind a paywall. Edison Co. feels that it probably would have just been easier to email the research institutions who control the research doc and ask for samples of the specific portions of the research, namely market size data, as this was most often paywalled. However, after much looking, Parker was able to find workarounds, though he was a bit concerned that the numbers from different market analyses often contrasted each other. The only real slip-up in this particular document came when Parker misinterpreted the meaning of a graphic organizer not just once, but twice. First he created a flowchart, and then a table. While both of these resources were useful, it was a good reminder to just do a quick check if you aren't sure about the instructions of an assignment. In some ways, Edison Co. felt a bit of remorse at how the Industry Market research was actually used. The group definitely agreed that it felt like they'd forgotten about the doc once it had been created. It probably would have been a bit smarter to reference it when selecting ideas for their following decision matrix to see what designs would fit well into the market. While this never became an issue for Edison Co. and they do feel that their chosen solution had a spot in the market, they would highly recommend other groups referencing back to this doc at the time of their Decision Matrix.

For Edison Co., a majority of the design phase was conducted via exercises in engineering notebooks, as instructed by Ms. Mason. Step one was to draw thumbnails, rapid-fire sketches of designs that popped into each group member's minds. Overall, this process went well, but Edison Co. members probably should have thought a bit more closely about what aspect of the project they were actually designing. For example, Ely focused on designing the UI of the clock, before it was even decided whether or not the product had a display or took the form of a traditional alarm (which the final product did not). This meant that his UI designs really needed to be coupled with a physical design, which just made selecting favorite designs for the next step a little more difficult. To combat this issue, Edison Co. recommends future groups focus on thumbnails as broad designs, not ways to encapsulate specific features.

That said, the team recovered in time for detailed drawings, which went as expected. Soon, the group was ready for the decision matrix. As instructed, the same matrix as for Similar Solutions was employed, and while the group thought that it might have been useful to add the top Existing Solutions for a direct metric to compare the Edison Co. ideas, selecting the top 3 designs was not a trouble. Plus, Edison Co. chose a 4th design as a backup in case the other 3 did not require enough CAD, which didn't turn out to be an issue but was definitely a good insurance technique. Coming into the final selection between these top designs, Edison Co. got the impression that it was more or less assumed at this point that groups knew what design they wanted to pursue, as comparatively less time was given to chose between the top 3 than other steps (like the decision matrix). In the end, the top 3 decision was actually very painstaking for Edison Co. Both Jace's more traditional alarm design and Parker's paper lamp seemed competitive. Meanwhile, feedback from classmates had been very useful, as it had been used to rule out David's cooling bed. The fight between the remaining two was fierce and a bit rushed, and Edison Co. strongly suggests future groups think ahead to this decision to be prepared when the time comes. In the end, Parker's paper lamp was chosen due to its simplicity, and Edison Co. felt satisfied with decision.

Edison Co. applied Agile methodology when determining what features would be needed in prototypes. The group began with considering different end users, or personas, which would require the use of their product. These personas were pretty well-constructed, but there were several individuals (i.e. hotel manager) that the group was not able to interview for as Ms. Mason had instructed. Nonetheless, the group still covered most bases with the personas. It was in generating user stories, or more specific cases, where Edison Co. felt the largest disconnect occurred. To begin with, the group ended up with a number of duplicate stories which either served the same functions or represented very similar people/circumstances. In example, both a student, represented in Figure 6, and the armed forces member of Figure 7 wanted a gentle stimuli to wake up with a lot of energy; after all, who doesn't benefit from waking up refreshed? Edison Co. wasn't sure, and still isn't sure, whether this was expected behavior of user stories, or an issue that resulted from overlapping personas. At the end of the day, Edison Co. tried to differentiate these similar user stories in the features requirement checklist, which described exactly what should be done in order to satisfy that user.

Additionally, Element C required that stories be organized into categories such as epics, themes, etc. The team certainly didn't design their stories with this organization system in mind and only first heard of it when looking at portfolio requirements, and as such, very few stories fit well into the given molds. Teams should definitely consider making an even distribution of stories with various scopes to fit into this organizational system.

Lastly, a Kanban Board was used throughout the project. Reflecting on this particular tool, Edison Co. found it to be very useful in the very beginning of the project. The team jumped right in to creating cards and categories for all assignments. Initially, there was a bit of struggle on how to assign cards to particular members. While the member could be assigned directly to the card using the built-in tool, the UI only displayed this information with a low-resolution image of the member's initials, which was a bit hard to read at times. Thus, the group experimented with using tags. The tag could be adjusted to read the given member's name; not only did it list their full name in high-resolution text, but it also came with a very defined color. This process ended up being a hassle, and so Edison Co. just had to get used to Trello's built-in assignment feature. As the project went on, however, the Kanban felt like it lost a fair bit of value. While the group still tried to keep things as up-to-date as possible, tasks became much more ambiguous, such as "complete the prototype" or "test PWM." Still, the Kanban remained as a good way to keep track of requirements and user stories.

During the prototyping phase of the project, the Edison Co. team learned a lot about how to create goals for each version. For the first version the team just wanted to get the basics of being able to turn on a light and have a speaker play at the right time. To do this we went with a really simple design with the light being controlled with a smart switch, and the speaker with a Bluetooth connection. With the short comings of the first prototype, the team switched goals on the second prototype to instead focus on the light dimming feature instead of functionality. To do this, prototype two was all about figuring out how to dim an LED on a breadboard, so in the future we could dim an actual light bulb. On the final prototype the team switched back to functionality, and focused on making the prototype easy to use and aesthetically pleasing.

There was a lot of Science, Technology, Engineering and Math that went into the day break lamp. For science the team had to figure out how sleep cycles worked to figure out how the prototype should lift the user out of sleep at the right time. This would determine how long it would need to take for the light and sound to get to max light and volume. The team also packed a lot of tech into the alarm by using a Raspberry Pi, AC dimmer board, Bluetooth speaker and AC DC converter all in conjunction to make the product work. The team also engineered a housing for the lamp that used the minimal amount of space, while also being strong and clean.

This project is probably one of the most satisfying ones I have worked on in school. In the last couple weeks of the project the final prototype really started coming together and it was really rewarding to see our long and hard work paying off. For the most part I worked on the physical design for the housing and the way we mounted everything in the final alarm. Once we got to the assembly phase of the project I started soldering the electronics and mounting them in the box. I also put the screws and hooks on the alarm so the user could hang it up. The biggest lesson that I learned from this project was that communication in key. Everyone in the group had areas of the project that they dominated, like Jace doing preliminary designs and portfolio, Parker doing software, me doing electronics and assembly, and Ely designing the box. But the most important thing was that between the four of us we could bounce ideas off each other and get constructive feedback.

During the project, I was a bit of a jack of all trades. Even though I dabbled in a bit of everything, my biggest contribution was likely designing the housing for the box. I had to more or less learn CAD, as even though we had done some at the start of the year, I had forgotten much of it and had to spend a couple of days relearning the basics of Inventor. After doing so, however, I designed the box to the specifications decided on by the group. This was an easy task on paper, but we had to find proper measurements for screws, decide on dimensions, methods of mounting, actual dimensions, how to hold the speaker, where to place holes for cables, the size of the cable holes, how to mount the box to the ceiling, what screws to use, what washers and hooks to order, how to pay for it, who we could get to 3D print it, and more. Other than the box, I helped with the portfolio, and also did much of the early research and planning. I also helped a small amount with the electronics and the hardware. Overall, I learned a lot about project management, as well as wiring, soldering, and the power of effective communication. Lastly, the most important part of the project that I learned was how to not micromanage. I can be controlling, and having to take a step back out of a leadership position and let other people decide most of those things was a very good experience for me, and something that I will be taking forward with me into the future.

Throughout the course of the project, I definitely contributed the most in the software department, which was resultantly the area in which I learned the most. I'd never worked with a Raspberry Pi before this project, and I definitely would like to pursue a couple more Pi projects, as it really is such a flexible tools. Even something as simple as managing a Unix system I was pretty inexperienced with, but now I at least have a basic idea of how to do competently. Additionally, I appreciated learning about electronics from David. He taught me some basic soldering techniques, and also principles of wiring. All of these basic electronic/programming equipment were valuable to learn about.

In terms of project management, the lesson that has seemingly stuck with me the best is the importance of paying close attention to directions, and clarifying when they are not well understood. I undervalued this skill early on, which lead to some struggles with user stories, but tried to avoid it for future assignments. Communicating with Ms. Mason when I was a bit confused became the norm, and allowed me to provide exactly the type of work she was looking for.

In the project, I helped create the logo and focused more on the how the product would be marketed if it were to be an actual product and worked on what the team needed at the time. Also helping out with the designs of product and general portfolio work. This was a really good experience for me, it gave me a glimpse of what actually being on a team for a project like this, say for a job. The one thing that I really wanted to do was to CAD our design for our project, however I never spoke up about it as it seemed like something that Ely really wanted to do and that is where his strength had come in the project. This helped me to better reinforce the fact that within a team there are certain roles that people need to fill and keeping up your end also helps everybody else out. The one tool that helped carry me throughout the entire project was almost exclusively a computer.

One thing that I also had done was just to keep up with what the rest of my teammates were doing, especially on the software end with Parker. It was also a learning experience for me, as Parker demonstrated to the team how the procedure was executed for testing each subsequent Prototype, even though I know nothing about coding, just understanding at least what was happening and explaining it to me really taught me a lot. "But the most important thing was that between the four of us we could bounce ideas off each other and get constructive feedback."