Inside the Class: Software Engineering

Lately I have not been able to get school out of my head. As my last post indicated, my current schedule is pretty rough. However when I mention some of my class names, I often forget that most of the readers of this site are not computer science majors. With that in mind, I am going to explain a little bit about some of the technical classes I am involved in right now. I will start with Software Engineering.

Software Engineering

The title of this course gives you a good idea of what it encompasses. Software Engineering is about the software design process. There are various phases that go into created and releasing a computer software product. In my class we are creating a calendar program. The timeline goes something like this:

Requirements: A developer is given a set of requirements from a customer which cover what the customer wants the product to be. Of course if a developer is coding an original application, he creates his own requirements. This is really the foundation for everything that is to follow. For example if you were creating a calendar program, there might be requirements such as “Three Different Views: Day, Week, and Month” or “Ability to Have Recurring Appointments.” Once a list of the software’s abilities (and its inabilities) it is time to proceed to the next stage.

Design: With a list of requirements in place the next step is to decide how to achieve those requirements. The design process is in my opinion the most important. The difficulty comes in designing a system that is going to meet the specified requirements while also leaving room for adding new functionality later. It is critical to create something that is moldable should requirements change.

In the design phase a team will meet and make decisions on things such as the graphical user interface (GUI), basically how the user will interact with the program. The GUI is everything that the user sees and is able to use. In Microsoft Word for example, there is a file menu and a toolbar with various settings such as font size and color. There is also the view of the actual page where text is placed. All of these things are part of the GUI.

The design also encompasses the things that the user does not see. What exactly happens when you look at the month of February? The program has to find out how many days there are and then create them (This example uses a new code feature that you may have to refresh a few times to see. Should be a gray box.):

    int j = 28;
    if(leap == true){
        j = 29;
    }
    for(int i=0; i < j; i++){
        days[i] = new Day();
    }

That code does not really do much, it is just an example of code going on behind the scenes that the user never sees. Both the front end (GUI) and the back end (what the user does not see, framework) are planned during the design phase. Roles for each team member are assigned here also.

Implementation: Not much to this part. The team now creates what was designed during the previous phase. There could be any number of teams, in our case it is one assigned to the front end, and one assigned to the back end. Because of this common strategy, it is important to have coordination and communication between the two teams. It is pointless for each team to build something that cannot interact with its counterpart. This is where I contribute to my SE team. I am the Project Manager, so I have to coordinate the development as well as document its progress.

Testing: I am going to be real here. Testing is the most boring and tedious phase of software development. This is where every single piece of code is tested to make sure there are no unexpected results. If you ever encounter a bug in software, it is typically because someone missed something during testing.

Release: Now that the program is built and tested, it is ready to be released. This could be an internal release within the group to make sure it is up to standards, or even a commercial release once the product is ready. Unfortunately sometimes a company’s timeline forces a product to debut before it is prepared, which results in software with tons of problems. My team is hoping to avoid that because since it is a class we do have fixed “release” dates.

Repeat: The development process is really a cycle. Once a product is released the entire list of phases must be run through again to maintain the software. Of course each step is much smaller than the first run-through, but nevertheless needs to be completed for release 2 and subsequent releases.

The development cycle has been brought into reality by my team. We are learning a lot about the process that takes place in the industry. Having talked to a few computer scientists and software engineers, this stuff is very similar to the real-world environment.

Of course in this post I have barely covered one day’s material, this is just a small taste that I thought could give a general idea of the course. Heavy importance is placed on process throughout software engineering. Detailed design and documentation are the most important pieces to the philosophy.

Why This Discussion?

I apologize if this post was boring. Believe me, a lot of it is even if it is often necessary. I thought it would be a good idea to give everyone insight into classes a computer science student must take, and being in the midst of this class it seemed like a good place to start. Software engineering has taught me a lot about the actual programming industry.

The point here is that the software engineer is more career-focused so to speak. The reason everything is documented is so that if another employee has to work with your unfinished code, they know what you have done so far and how you did it. The course showed me what working in a job environment could be like. RIT does do a great job of giving practical career experience.

If you have any questions about the course I would be glad to answer them. Obviously I have not completed it yet so some things could change. Even if you do not have any question, I would like to hear your thoughts on future class insights. My thinking is that it is a way to talk about what I am learning and maybe educate people about computer science a bit. I am planning to do another post on Computer Organization, but I will depend on feedback to decide on doing any after that. If the coursework of a computer science student is lacking interest I will gladly write about other things. Let me know in the comments…and Happy Groundhog’s Day.