style="font-size:15px;"> Software engineering isn't always the most exciting topic, so in an attempt to keep you awake, I picked some of the examples in this book for interest or humorous effect. (If you keep this book on your nightstand as a last-ditch insomnia remedy, then I've failed.)
I mean no disrespect to any of the many talented software engineers out there who work long weeks (despite the call for sustainable work levels) to produce top-quality applications for their customers. (As for the untalented software engineers out there, their work can speak for them better than I can.)
I also don't mean to discount any of the development models described in this book or the people who worked on or with them. Every one of them represents a huge amount of work and research, and all of them have their places in software engineering, past or present.
Because this book has limited space, I had to leave out many software development methodologies and programming best practices. Even the methodologies that are described are not covered in full detail because there just isn't room.
If you disagree with anything I've said, if you want to provide more detail about a topic, or if you want to describe the techniques and variations that you use to build software, I beg you to join this book's Wrox P2P forum and tell everyone all about it. The people on that forum are trying to improve their development skills, so we'd all love to hear what you have to say. (In fact, learning and improving the development process is a stated requirement for many agile methodologies, so joining the forum is practically mandatory!)
Finally I mean no disrespect to people named Fred, or anyone else for that matter. (Except for one particular Fred, who I'm sure retired from software development long ago.)
So get out your reading glasses, grab your favorite caffeinated beverage, and prepare to enter the world of software engineering. Game on!
PART I
Software Engineering Step-by-Step
Software and cathedrals are much the same. First we build them, then we pray.
In principle, software engineering is a simple two-step process: (1) Write a best-selling program, and then (2) buy expensive toys with the profits. Unfortunately, the first step can be rather difficult. Saying “write a best-selling program” is a bit like telling an author, “Write a best-selling book,” or telling a baseball player “triple to left.” It’s a great idea, but knowing the goal doesn’t actually help you achieve it.
To produce great software, you need to handle a huge number of complicated tasks, any one of which can fail and sink the entire project. Over the years people have developed a multitude of methodologies and techniques to help keep software projects on track. Some of these, such as the waterfall and V-model approaches, use detailed requirement specifications to exactly define the wanted results before development begins. Others, such as Scrum and agile techniques, rely on fast-paced incremental development with frequent feedback to keep a project on track. (Still others techniques, such as cowboy coding and extreme programming, sound more like action adventure films than software development techniques.)
Different development methodologies use different approaches, but they all perform roughly the same tasks. They all determine what the software should do and how it should do it. They generate the software, remove bugs from the code (some of the bugs, at least), make sure the software does more or less what it should, and deploy the finished result.
NOTE I call these basic items “tasks” and not “stages” or “steps” because different software engineering approaches tackle them in different ways and at different times. Calling them “stages” or “steps” would probably be misleading because it would imply that all projects move through the stages in the same predictable order.
The chapters in the first part of this book describe those basic tasks that any successful software project must handle in some way. They explain the main steps in software development and describe some of the myriad ways a project can fail to handle those tasks. (The second part of the book explains how different approaches such as waterfall and agile handle those tasks.)
The first chapter in this part of the book provides an overview of software development from a high level. The subsequent chapters explain the pieces of the development process in greater detail.
CHAPTER 1
Software Engineering from 20,000 Feet
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. The other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
WHAT YOU WILL LEARN IN THIS CHAPTER:
● The basic steps required for successful software engineering
● Ways in which software engineering differs from other kinds of engineering
● How fixing one bug can lead to others
● Why it is important to detect mistakes as early as possible
In many ways, software engineering is a lot like other kinds of engineering. Whether you’re building a bridge, an airplane, a nuclear power plant, or a new and improved version of Sudoku, you need to accomplish certain tasks. For example, you need to make a plan, follow that plan, heroically overcome unexpected obstacles, and hire a great band to play at the ribbon-cutting ceremony.
The following sections describe the steps you need to take to keep a software engineering project on track. These are more or less the same for any large project although there are some important differences. Later chapters in this book provide a lot more detail about these tasks.
REQUIREMENTS GATHERING
No big project can succeed without a plan. Sometimes a project doesn’t follow the plan closely, but every big project must have a plan. The plan tells project members what they should be doing, when and how long they should be doing it, and most important what the project’s goals are. They give the project direction.
One of the first steps in a software project is figuring out the requirements. You need to find out what the customers want and what the customers need. Depending on how well defined the user’s needs are, this can be time-consuming.
WHO’S THE CUSTOMER?
Sometimes, it’s easy to tell who the customer is. If you’re writing software for another part of your own company, it may be obvious who the customers are. In that case, you can sit down with them and talk about what the software should do.
In other cases, you may have only a vague notion of who will use the finished software. For example, if you’re creating a new online card game, it may be hard to identify the customers until after you start marketing the game.
Sometimes, you may even be the customer. I write software for myself all the time. This has a lot of advantages. For example, I know exactly what I want and I know more or less how hard it will be to provide different features. (Unfortunately, I also sometimes have a hard time saying “no” to myself, so projects can drag on for a lot longer than they should.)
In any project, you should try to identify your customers and interact with them as much as possible so
