Today was the last official class meeting for my software engineering class, and as a final assignment, we were asked to write a blog post summarizing our thoughts on software engineering and the course in particular.
I started the class not knowing what exactly software engineering was, but being excited about the opportunity to work with others to develop code. In all previous classes, we received very stern warnings that we were not to work with others on homework assignments, so I developed a very strong mentality of programming everything on my own with only minimal conversations between my classmates and I regarding our code. As a result, I took the class wanting to see what it was like to program with others.
Throughout the course, I've learned that software engineering is a complex process, but that there are many tools available for programmers to use to help them do software engineering with the least possible pain. Before the class, I didn't know how complicated it was to share a project with new developers; nor did I anticipate how difficult it would be to have two people working on the same programming project. Among the tools that we learned in class were JUnit, to test the code for constant functionality; Ant, to standardize the development environment; Subversion, to facilitate sharing code; and Google Project Hosting, to provide hosting for the project code and a way to track issues on the project. All of these tools were difficult to learn or get used to at first, but once I got a basic understanding of them, they definitely made group work a lot easier.
I think that one of the most important aspects of the class for me wasn't necessarily the programming experience, but the development of a professional person that I can use to present myself to graduate schools and prospective employers. This includes not only the programming and software engineering skills that I picked up on in the course, but also my professional portfolio and this blog. These are both items that I will be able to continue to update and to use to present my programming skills and my knowledge of software engineering.
This class was a lot of work, and I definitely spent more time working on assignments for this class than for any of my other courses this semester (and possibly any of the other courses in my undergraduate career). However, because of this, I feel that I have a much better understanding of what is involved in the creation, development, and deployment of a programming project. I now know how much time is involved in the process and I know of the tools available for use to facilitate software engineering. It was a tough experience, but it was a good experience to have had.
Wednesday, December 9, 2009
Eco-Depot version 2.0
As the final project for my software engineering class, my group and I worked on improving the design and increasing the functionality of the Eco-Depot web application, as discussed in my last few blog posts. This involved going back to our previous implementation to make it more user friendly while adding additional features to the system.
For those of you who have not read my previous posts, Eco-Depot is a web application that seeks to provide information to users on the state of the Oahu power grid, based on the WattDepot system. This is done by analyzing the ratio of carbon versus energy produced, so that Oahu residents can reduce their carbon footprint on the environtment. Additional features for version 2.0 allow users to easily access information on the amount of energy produced by the grid. The application seeks to provide energy consumers with the information that they need to become smart consumers. As a side note, the WattDepot system currently uses simulated data for the grid.
One of the main problems with our version 1.0 implementation is that it was not designed with an ordinary user in mind. It had very few instructions, no obvious purpose, and had a very bleak look and feel. One of the main things that we tried to do for version 2.0 was to make it easier for an average user to understand and use the site. This was done by adding in a main page with an introduction to the system, as well as providing additional information on pages with functionality. We also included more graphics (all made by Kendyll) and used CSS to provide a standard look and feel for the page.
The second major item that we needed to accomplish for version 2.0 was to convert our table of carbon content data into a stoplight to display only the current analysis, as well as to write a second page that would allow users to see the energy produced by any of the Oahu power sources over a specified period of time. Most of these items were not extremely difficult to do - it was all of the background work that took a long time to understand. In particular, we had to wrestle with understanding and implementing sessions for the pages so that multiple users would be able to use the application without inadvertent sharing of the information between the two. Additionally, we experienced problems with Wicket because of our lack of experience working with the language.
Overall, I learned a lot about Wicket from working with this project. Also, and perhaps more importantly, the entire web application creation process gave me a better understanding of software engineering and the effort that it takes to program something with a team of people rather than alone. One of my group's biggest problems was generally communication - communication about what we were working on, communication about what we needed help on, and communication on what everyone else needed to do so that everything would come together smoothly. Although we used the Issues management feature of Google Code, sometimes we ran into problems where one developer's item relied on things being written by another developer, but the two pieces needed additional work in order to communicate together. As we neared the project due date, I feel that we were a lot better about communication because we had all realized that we needed to constantly keep in touch so that everyone would be able to work on something at the same time with minimal clashes.
Our completed product can be downloaded for use as a Java jar file, and with the complete code in a zipped distribution file on the project's Google Code Downloads page. Additional information on the product and its development are also available on the project's page.
For those of you who have not read my previous posts, Eco-Depot is a web application that seeks to provide information to users on the state of the Oahu power grid, based on the WattDepot system. This is done by analyzing the ratio of carbon versus energy produced, so that Oahu residents can reduce their carbon footprint on the environtment. Additional features for version 2.0 allow users to easily access information on the amount of energy produced by the grid. The application seeks to provide energy consumers with the information that they need to become smart consumers. As a side note, the WattDepot system currently uses simulated data for the grid.
One of the main problems with our version 1.0 implementation is that it was not designed with an ordinary user in mind. It had very few instructions, no obvious purpose, and had a very bleak look and feel. One of the main things that we tried to do for version 2.0 was to make it easier for an average user to understand and use the site. This was done by adding in a main page with an introduction to the system, as well as providing additional information on pages with functionality. We also included more graphics (all made by Kendyll) and used CSS to provide a standard look and feel for the page.
The second major item that we needed to accomplish for version 2.0 was to convert our table of carbon content data into a stoplight to display only the current analysis, as well as to write a second page that would allow users to see the energy produced by any of the Oahu power sources over a specified period of time. Most of these items were not extremely difficult to do - it was all of the background work that took a long time to understand. In particular, we had to wrestle with understanding and implementing sessions for the pages so that multiple users would be able to use the application without inadvertent sharing of the information between the two. Additionally, we experienced problems with Wicket because of our lack of experience working with the language.
Overall, I learned a lot about Wicket from working with this project. Also, and perhaps more importantly, the entire web application creation process gave me a better understanding of software engineering and the effort that it takes to program something with a team of people rather than alone. One of my group's biggest problems was generally communication - communication about what we were working on, communication about what we needed help on, and communication on what everyone else needed to do so that everything would come together smoothly. Although we used the Issues management feature of Google Code, sometimes we ran into problems where one developer's item relied on things being written by another developer, but the two pieces needed additional work in order to communicate together. As we neared the project due date, I feel that we were a lot better about communication because we had all realized that we needed to constantly keep in touch so that everyone would be able to work on something at the same time with minimal clashes.
Our completed product can be downloaded for use as a Java jar file, and with the complete code in a zipped distribution file on the project's Google Code Downloads page. Additional information on the product and its development are also available on the project's page.
Subscribe to:
Posts (Atom)