At the beginning of the course, I described the software development cycle as a process that involves repeating a set of steps that can basically be described as edit - compile & execute - observe. I also explained that the first version of the cycle was overly simplistic (the following compares the two cycles).
Notice that the software development cycle is closely related to the problem solving process. The process of modeling a solution to a problem requires a strategy for attacking the problem and the attack takes on a cyclical nature. In other words, the software development cycle described here includes the problem solving process as part of the cycle.
The basic cyclic process of modeling involves the following steps:
The design phase of solving a problem is one of the primary concerns of software engineering -- for large-scale projects, choosing a good design is often very hard to do. Software engineers usually break down the design phase into multiple stages which are beyond the scope of this course (but which are also cyclic in nature).
The implementation phase is another word for the stage where you are coding the solution. Our first version of the software development cycle is best associated with the cycle of the implementation (coding) phase. The difference is that implementation that is not progressing may be put on hold in order to reassess the design.
The testing phase is supposed to "guarantee" that your solution is correct.This is a very important component of large-scale projects. For large projects, this is also hard to organize. In 15-100, we won't truly learn why testing is hard (or important). However, as you solve your current and future programming projects, you'll probably understand how more sophisticated testing is necessary.
To understand the difference between the old simple development cycle and the new development cycle, you have to understand that, with a weak design, you can reach a point where you realize that no amount of code modification is going to produce a correct solution. In such cases, you have to cycle back to the design phase and modify your overall design. If, for some reason, your design corrections still don't help, you may have to cycle back to the analysis phase (because you didn't really understand the initial problem afterall).SIDEBAR: "THINK FIRST, CODE LATER"
Invest time to plan out how to solve a problem.You plan all the time even if you don't think of it as a separate process. For example, if you want to summer in Europe, you will definitely have thought about the idea and have packed before you actually set foot on an airplane. Even if you only want to wander aimlessly through the foothills of Tuscany, that wandering is still a plan. A common misconception among students is that a programming assignment begins when they set foot on the airplane (i.e., starting CodeWarrior).
Although a European summer is not exactly a "problem", you generally have goals in mind for the vacation. Accomplishing these goals amounts to your "problem" and an itinerary is a design for accomplishing your goals. Similarly, packing your suitcases can be thought of as a related problem in the pursuit of these goals -- e.g., "if I visit England, should I pack an umbrella?".
For vacations, many people definitely "overplan" their itinerary. On the other hand, of the hundreds of students that I've had the pleasure of teaching, I've not met a single one who overplanned all of their programming assignments.
The planning (i.e.,, forethought) of analysis and design simplifies the process of solving a problem (and hence the amount of time it takes to complete the work). Actually, when you've completely planned out how to solve a problem, you've already "solved" the problem. Writing the program to model your solution is just the grunt work. This is the real reason why it is easier to learn a new programming language if you already have learned to solve problems in some other programming language.
The decision to go up a level in the full development cycle is a hard one to make. Although it means that you're walking away from a lot of time already spent (which may be expensive), you're making a decision not to waste more time in a pursuit that won't pan out. However, in large-scale projects, design errors can slow down a program's completion by weeks or months. Not fully understanding the problem could mean a requre a complete redesign but, more likely, would mean the forfeiture (by the customer) of the contract to write the program.
As a personal experience, I worked on a 3 year programming project for the Air Force that took an additional 15 months to complete because certain documents that were needed to complete the work arrived two years after the date they were first promised by the military. We had large holes in the design of certain components of our project because we were not given enough information to completely understand the problem. Since we were aware that the information was missing when we created our original design, we made use of advanced SE design concepts (think fancy "stubs") to isolate these problem areas. Because our design was solid, we were able to progress with the development of other components while waiting for the information we needed. Because the holes were large, we needed a lot of time to complete this work. Because our design was strong, 90% of the work was totally associated within the new regions. The connections to other work previously done at most required minimal modifications.Although I've expressed the importance of these issues in terms of large-scale programs, they are relevent for introductory students.
How DESIGN relates to 15-100 students:
In the first two projects , you may have ended up solving your problem without a lot of forethought about analysis and design. However, even if you created a trial-and-error approach to solving the problem, you will have had to understand the problem (att worst, on the day that is it due). You may implicitly be designing solutions without ever realizing that you're doing something more than coding. The changes in the code you make will often be closer to design changes. In thinking about how to fix your code, you are going through the design/code phase on a regular basis.
When you write a program without preparation, you still create a design. It is just that the design only becomes evident because you've addressed the "forethought" phases after the implementation/testing phase. The problem is that this approach requires much more time on larger projects.Since I will expect students to incorporate the ideas expressed here and in class, I will not be totally sympathetic to student complaints about the "extraordinary time" they spent doing a project .Often, when I ask such students about their "plan" for solving the project, they are clueless -- this is an indication that the student hasn't organized their thinking about solving the project.
Starting with project 3, I expect students to have a design/outline for a project. If you don't have a design, you'll need to create one. Some students may need help with the design process -- I'm willing to help you with this early on. However, dealing with these issues a few days before a project is due is a matter of your procrastinatio. If you don't have an idea at such a late date, I'm only willing to tell you to "get"a clue".
In the second half of the course, a project that
takes most students 4 hours to complete has taken some students 15 hours.
When students have talked to me about the "extraordinary time drain"
that the course imposes, I almost always find out that they continue to
solve problems by trial-and-error. The key to successfully getting
through this course (and be able to take other courses while still having
some free time) is to realize that your programming assignments involve
time away from the computer.