Concepts of Software Development

1. Concepts of Software Development Chapter 1

2. Separation of Concerns • In software engineering, it’s important, of course, to know what to do, and when. • It’s just as important to know what not to do and when not to do it! • Information is a big factor in software engineering, so it’s also important to know where information belongs and where it doesn’t belong!

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

16. The Business of Developing Software • There are a wide range of companies that develop software from “garage” operations to industry giants. • In most cases, the software is either a product in itself (such as “applications” software), or supports another product (such as printer “drivers”.)

17. Time to market • Commercial software development lives with business realities. • Good ideas aren’t unique. If they aren’t quickly moved to market, a competitor can move a product to market and “grab market share” becoming the “de facto” application! • The time period for an ideas viability is sometimes called a “market window”.

18. Perceived software quality • Quality is in the eye of the beholder: if a good application is seen as “low quality” by the end users, it won’t be used. • If a lousy application is seen as “grand” by the end users it will be used in spite of the shortcomings and flaws. • Can you think of any best-selling applications that are insufferably bad? How about little-known applications that are really great?

19. The software development team • Software development teams are composed of individuals with different (and often changing) responsibilities. • There are “paradigms” (or models) of how teams should be organized and how the effort distributed. • Each and every team has one or more members in a supervisory (or managerial) role.

20. Managing development • The method for managing development is deceptively simple: Plan, Allocate Resources, Monitor Progress, Remove Obstacles, Assure Quality. • These activities are complicated by the fact that the manager must have the cooperation of (and cooperate with) other groups Sometimes these groups have conflicting interests. The manager must adjust expectations and resources to accommodate other interests (not always easy!)