Concepts of Software Development

Chapter 1

Separation of Concerns• Break the system down into less

complicated parts, and concentrate on each one in turn.

• Decomposition should “separate concerns”• Decomposing the problem of developing

software: – Management vs. technical– Teamwork vs. individual effort– Different development phases.

Management vs. technical

• It’s our contention that managers play a very important role in software engineering. What managers do contrasts with what engineers do…engineers are “individual contributors”

• In a nutshell, technical employees (such as engineers) are paid to deliver a product, and managers are paid to see that all employees (and resources) are properly orchestrated.

Know how the other half lives

• Since engineers deliver a product (in this case, software), to a client (their employer), it is useful to know how to keep their client satisfied.

• In this case, their client’s representative is their manager, so it’s important for engineers to know what managers do, and what their manager’s interests are!

You don't have to love 'em

• Management is the subject of a lot of antagonism from the engineering community; some is deserved, perhaps, but most isn’t.

• Good managers can handle a lot of issues engineers can’t (or won’t), such as workplace politics, and issues with team members.

Teamwork vs. individual effort

• This course focuses primarily on the individual engineer, but engineers rarely work alone.

• Engineers who become professional developers are well advised to acquire team skills, and to learn a bit about psychology and human relations!

Different tasks-development phases

• The software “lifecycle” is broken down into different activities. Each activity has a descriptive name that hints at the main objective of that activity, called a “phase”.

• The primary “product” of each phase will vary, but the products are (in most cases) documents.

Phases of the Software Lifecycle

• The names of the phases given to the software lifecycle differs according to which lifecycle model that is used.

• The model chosen for the software development effort may depend upon factors such as team size and organization, or project size and organization.

Information exchange between developer and end user

• Almost every software model will have an activity defined where information is exchanged between the end-user and the developer.

• The “end users” aren’t always the just “cash customer”, they typically include a marketing representative (they have to sell it), technical support (they have to support it), manuals (they have to tell people how to use it), and others.

• When end-user’s interests conflict, the most important is usually the cash customer, of course!

Complete problem description (developer only)

• The developer has the biggest interest in getting a complete and usable problem description, so this effort I usually driven by the developer.

• A problem description needs to describe what the problem is, but not how the problem is to be solved. The “how” effort is really a design activity!

Breakdown into detailed assignments for programming

• Ultimately, we need to progress to a point where well-defined, individual programming assignments can be given to the programmers.

• Somehow, we need to derive the programming assignment descriptions from the problem statement. This activity is usually called “design” in most lifecycle models.

Programming

• This is the activity all software engineers know and (hopefully) love.

• If this activity is to be fast and effective, the programming assignment needs to be written so that it is complete and easy to follow.

Testing

• When the program has been written, compiled and is ready to execute, the important questions arise:– “Did we build what we said we would?”

– “Is this what the customers need?”

– “Is this what the customers expected?”

• How do we find out the answers to these questions? Hopefully, these questions were answered earlier in the project, and there is a “test plan”.

Changing the program

• Once testing has begun, inconsistencies, programming defects (“bugs”) and “needed enhancements” will arise. Simply put, these issues will mean that the program will have to be changed.

• When the program is changed, it will need to be checked again.

Naming the development phases

• Requirements: The process of defining the problem.

• Specification: Recording the problem in a notation that lends itself to analysis and design.

• Design: Analyzing the problem, and defining a solution.

• Coding: Implementing the solution.• Testing: Checking the implementation against the

problem definition and the end-user’s needs.