Project Management

---

Three Software Development Roles

You will find yourself assuming the duties and responsibilities of three software development roles: Analyst, Architect, and Programmer.

Analyst

When you are handed a class programming project you may or may not understand what the instructor is actually asking you to program. Hey, it happens! Whatever the case may be, you, as the student, must read the assignment and design and implement a solution.

You can think of a project assignment as a requirements specification. They will come in several flavors. Some instructors go into painful detail about how they want the student to execute the project. Others prefer to generally describe the type of program they want thus leaving the details, and the creativity, up to you. There is no one correct method of writing a project assignment; each has its benefits and limitations.

A detailed assignment takes a lot of the guesswork out of what outcome the instructor expects. On the other hand, having every design decision made for you may prevent you from solving the problem in a unique, creative way.

A general project assignment delegates a lot of decision making to the student while also adding the responsibility of determining what project features will satisfy the assignment.

Both types of assignments model the real world to some extent. Sometimes requirements are well defined and there is little doubt what shape the final product will take and how it must perform. However, more often than not requirements are ill or vaguely defined. As an analyst you must clarify what is being asked of you. In an academic setting, do this by talking to the instructor and have them clarify the assignment. A clear understanding of the assignment will yield valuable insight into possible approaches to a solution.

Architect

Once you understand the assignment you must design a solution. If your project is extremely small you could perhaps skip this step with no problem. However, if your project contains several objects that interact with each other, then your design, and the foundation it sets, could make the difference between success and failure. A well-designed project reflects a subliminal quality that poorly designed projects do not.

Two objectives of good design are the ability to accommodate change and tame complexity. Change in this context means the ability to incrementally add features to your project as it grows without breaking the code you have already written. Several important object-oriented principles have been formulated to help tame complexity and will be discussed later in the book. For starters though, begin by imposing a good organization upon your source code files. You can use the source code file formats presented below to help in this endeavor.

Programmer

As programmer you will execute your design. The important thing to note here is that if you do a poor job as an architect your life as a programmer will be miserable. That doesn’t mean the design has to be perfect. I will show you how to incrementally develop and make improvements to your design as you code.

Now that you know what roles you will play as a student let us discuss how you might approach a project.

A Project Approach Strategy

Most students have difficulty implementing their first significant programming assignment, not because they lack brains or talent, but because they lack experience. If you are a novice and feel overwhelmed by your first programming project rest assured you are not alone. The good news is that with practice, and some small victories, you will quickly gain proficiency at formulating approach strategies to your programming projects.

Even experienced programmers may not immediately know how to solve a problem or write a particular piece of code when tasked to do so. What they do know, however, is how to formulate a strategy to solve the problem.

You Have Been Handed A Project — Now What?

Until you gain experience and confidence in your programming abilities the biggest problem you will face when given a large programming assignment is where to begin. What you need to help you in this situation is a project approach strategy. The strategy is presented below and discussed in detail. I have also summarized the strategy in a checklist located in appendix A. Feel free to reproduce the checklist and use as required.

The project approach strategy is a collection of areas of concern to take into consideration when you begin a programming project. It is not a hard, fast list of steps you must take. It is intended to put you in control, to point you in the right direction, and give you food for thought. It is flexible. You will not have to consider every area of concern for every project. After you have used it a few times to get you started you may not ever use it explicitly again. As your programming experience grows feel free to tailor the project approach strategy to suit your needs.

Strategy Areas of Concern

The project approach strategy is formulated around areas of concern. These include requirements, problem domain, language features, and design. When you use the strategy to help you solve a programming problem your efforts become focused and organized rather than ad hoc and confused. You will feel like you are making real progress rather than drowning in a sea of confusion.

Requirements

A requirement is an assertion that specifies a particular aspect of expected behavior. A project’s requirements are contained in a project specification or programming assignment. Ensure you completely understand the project specification. Seek clarification if you do not know, or if you are not sure, what problem the project specification is asking you to solve. In my academic career I have seen projects so badly written that I thought I had a comprehension problem. I’d read the thing over and over again until struck by a sudden flash of inspiration. But more often than not I would reinforce what I believed an instructor required by discussing the project with them.

Problem Domain

The problem domain is the specific problem you are tasked to solve. I would say that it is that body of knowledge necessary to implement a software solution apart and distinct from the knowledge of programming itself. For instance, “Write a program to simulate elevator usage in a skyscraper.” You may understand what is being asked of you (requirements understanding) but not know anything about elevators, skyscrapers, or simulations (problem domain). You need to become enough of an expert in the problem domain you are solving so that you understand the issues involved.

Programming Language Features

The source of greatest frustration to novice students at this stage of the project is knowing what to design but not knowing enough of the language features to begin the design. This is when panic sets in and students begin to buy extra books in hopes of discovering the Holy Grail of project wisdom.

To save yourself from panic make a list of the language features you need to understand and study each one, marking them off as you go. This provides focus and a sense of progress. As you read about each feature, keep notes on their usage so you can refer to them when you sit down to formulate your program design.

Design

When you are ready to design a solution you will usually be forced to think along two completely different lines of thought: procedural vs. object-oriented.

Procedural Design

A procedural design approach is one in which you identify and implement program data structures separate from the functions that manipulate those data structures. When taking a procedural approach to a solution you will break the problem into small, easily solvable pieces, implement the solution to each of the pieces, and combine the solved pieces into a complete problem solution. The solvable pieces I refer to here are functions. This methodology is also known as functional decomposition.

Object-Oriented Design

Object-oriented design refers to designing with objects and their interfaces. Whereas a procedural design treats data structures separately from the functions that manipulate them, object-oriented design uses encapsulation to hide an object’s implementation data structures behind a public interface. Data structures and the functions that manipulate them combine to form classes from which objects can then be created.

A problem solved with an object-oriented approach is decomposed into a set of objects and their behavior. Design tools such as the Unified Modeling Language (UML) can be used to help with this task. Once the objects in a system are identified, a set of interface functions is then identified for each object. Classes are declared and defined to implement the interface functions. Once all the program classes have been designed and written, they are combined and used together to form the final program. Note that when using the object-oriented approach you are still breaking a problem into solvable pieces, only now the solvable pieces are objects that represent the interrelated parts of a system.

Once you get the hang of object-oriented design you will never return to functional decomposition again. However, after having identified the objects in your program and the interfaces they should have, you will have to implement your design. This means writing class member functions one line of code at a time.

Think Abstractly

One mistake students often make is to think too literally. It is very important to remember that the act of solving a real world problem with a computer requires abstraction.

The Strategy In A Nutshell

Identify the problem, understand the problem, make a list of language features you need to study and check them off as you go. Once you formulate a solution to the problem, break the problem into manageable pieces, solve each piece of the problem, and then combine the solved pieces to form a total solution.

Applicability To The Real World

The programming problem solution strategy presented above is not intended to replace a formal course on software engineering, but it will help you when you enter the real world as a commercial programmer. In that world you will soon discover that all companies and projects are not created equal. Different companies have different design philosophies. Some companies have no software design philosophy. If you find yourself working for such a company you will probably be the software engineering expert!

---