What Is Software Engineering?

Software Engineering

It's a big topic but I'll try to give some meaning to the term. Wikipedia, in all it's glory, didn't help me much when trying to define software engineering in the context that we'll be looking at it. In our context software engineering is the act or process of designing and developing software. In other words we'll be engineering software.

What does that even mean?! It means we will go through the process professionals go through when developing software solutions. These can be used internally to be more productive or to cut costs or the solution may be a new product like Windows 8 or Angry Birds Space which will be sold or released to the public.

The Waterfall Method

The waterfall method is probably the oldest method in the book. According to Wikipedia this is because it's what other industries used to develop things. It's called the waterfall method because as you progress through the stages of development you can't (or aren't supposed to) go back to a previous step. This isn't as difficult in software but if you're designing a bridge you can't really go back to the drawing board after you start poring the foundation. As computer's have matured though, different development methods have formalized to take advantage of the nature of the flexibility software.

Where Does This Fit Into the Blog?

The waterfall method is where we will start our adventure into software engineering. In the next post we'll begin a project and go through most of the necessarily steps in the SDLC (Software Development Life Cycle). There are four stages of the SDLC, planning, analysis, design, and implementation. The steps cover in order the questions why, what, and how. The last step doesn't answer a question, it's the stage you build.

In this blog we will learn more about software engineering by going through the process. The first project or two we will explain some of the why's and how's of the steps and the documents that will be made. As we progress though, I'm going to focus more on presenting examples with explanations of design decisions instead of explaining why we create the document. I'll try to mix up styles too when I can and as I study them deeper. Not all businesses use the same development method. Even within a company different methods may be used depending on the nature of the project.

Our study won't include the first or last steps of the SDLC. Since this whole blog is an experiment in programming (hence the name) I'm not too concerned with the business application of our projects. They will start trivially and may grow in complexity as we figure this stuff out. As stated in the last post I will be doing a personal implementation to see how well our documents turned out and I encourage any of you to do our own implementation but this isn't going to be a programming tutorial blog where I show you code and explain why it works. What I'm trying to say is you're on you own for step four. I will post links to my implementation and any implementations readers share just for completeness.

In the last post I said it didn't matter for the most part what language these projects are implemented. The only constraint I'd place is the language should be object oriented because that's how we are going to design the project.

Our first project will be a game of hang man. It's simple enough to develop and implement quickly but still covers most of what we want to learn. Future projects will be larger or require more work.

Get ready for some fun!