1. Concepts of Software Development Chapter 1

2. 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.

3. 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.

4. 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!

5. 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.

6. 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!

7. 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.

8. 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.

9. 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!

10. 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!

11. 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.

12. 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.

13. 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”.

14. 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.

15. 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.