Chapter 4: Software-Development Fundamentals

One path to success in software is paying attention to fundamentals.

If you don’t master fundamentals, you’ll do OK on the easy projects, but your hard projects will fall apart.

1. Management Fundamentals
Organizations that attempt to put software-engineering discipline in place before putting project-management discipline in place are
doomed to fail.
Management fundamentals consist of (1) determining the size of the product (which includes functionality, complexity, and other
product characteristics), (2) allocating resources appropriate for a product of that size, (3) creating a plan for applying the resources,
and then (4) monitoring and directing the resources.

A. Estimating and Scheduling

Three basic steps to create a software schedule (1) estimate the size of the project, then (2) estimate the effort needed to build a
product of that size and then (3) estimate a schedule based on the effort estimate.
An inaccurate estimate reduces development efficiency. Accurate estimation is essential input for effective planning, which is
essential for efficient development.

B. Planning
Best projects are characterized by strong up-front planning to define tasks and schedules.
Planning included these activities:
1. Estimation and scheduling
2. Determining how many people to have on the project team, what technical skills are needed, when to add people, and who
the people will be.
3. Deciding how to organize the team
4. Choosing which lifecycle model to use
5. Managing risk
6. Making strategic decisions such as how to control the product’s feature set and whether to buy or build pieces of the product.

C. Tracking
On a typical project, project management is almost a black-box function. You rarely know what’s going on during the project and you
just have to take whatever comes out at the end. On an ideal project you have 100 percent visibility at all times. On an efficient
project, you always have at least some visibility and you have good visibility more often than not. See p. 57 for graphs.

If you don’t track a project, you can’t manage it. You have no way of knowing whether your plans are being carried out and no way of
knowing what you should do next. You have no way of monitoring risk to you project. Effective tracking enables you to detect
schedule problems early, while there’s still time to do something about them.

D. Measurement
One key to long-term progress in a software organization is collecting metric data to analyze software quality and productivity.

II. Technical Fundamentals

1. Requirements Management
Is the process of gathering requirements, recording them in some form, tracking the design and code against them, and then managing
changes to them for the rest of the project.
Top three reasons that projects were delivered late, over budget, and with less functionality than desired (1) lack of user input (2)
incomplete requirements, and (3) changing requirements.
Success at requirements management depends on knowing enough different practices to be able to choose the ones that are appropriate
for a specific project.

Fundamentals of requirements management:

1. Requirements analysis methodologies including structured analysis, data structured analysis, and object-oriented
analysis.
2. System-modeling practices such as class diagrams, DFD, ERD, data-dictionaries, and state-transition diagrams.
3. Communication practices such as JAD, user-interface prototyping, and general interview practices.
4. The relationships between requirements management and the different lifecycle models.

2. Design
Fundamental topics
1. Major design style—such as object design, structured design, and data structure design
2. Foundational design concepts—such as information hiding, modularity, abstraction, encapsulation, cohesion, coupling,
hierarchy, inheritance, polymorphism, basic algorithms, and basic data structures
 3. Stand design approaches to typically challenging areas—including exception handling, internationalization and
localization, portability, string storage, input/output, memory management, data storage, floating-point arithmetic,
database design, performance, and reuse
4. Design considerations unique to the application domain—such as financial, scientific, embedded systems, real-time
systems, and safety-critical software.
5. Architectural schemes—such as subsystem organization, layering
6. Use of design tools.

Design serves as the foundation for construction, project scheduling, project tracking, and project control.

3. Construction
Fundamentals
1. Coding practices—including variable and function naming, layout, and documentation
2. Data-related concepts --such as scope, persistence, and binding
3. Guidelines for using specific types of data—such as integer, floating-point, arrays …
4. Control-related concepts—including organizing strait-line code, using conditionals, controlling loops …
5. Assertions and other code-centered error-detection practices
6. Rules for packaging code into routines, modules, classes, and likes
7. Unit-testing and debugging practices
8. Integration strategies—such as incremental integration, big-bang integration, and evolutionary development
9. Code-tuning strategies and practices
10. The ins and outs of the particular programming language you’re using
11. Use of constructions tools—including environments, group work support, and code generators

4. Software Configuration Management

Is the practice of managing project artifacts so that the project stays in a consistent state over time.
Includes practices for evaluating proposed changes, tracking changes, and handling multiple versions.
Without configuration management, your teammates can change part of the design and forget to tell you.

III. Quality-Assurance Fundamentals

When a software product has too many defects, developers spend more time fixing the software than they spend writing it.
Some projects try to save time by reducing the time spent on quality assurance practices such as design and code reviews. Other
projects—running late—try to make up for lost time by compressing the testing schedule, which is vulnerable to reduction because it’s
usually the critical path item at the end of the project.
Poor quality is one of the most common reasons for schedule overruns.
Up to four times the normal number of defects are reported for released products that were developed under excessive schedule
pressure.
Rule of thumb, every hour you spend on defect prevention will reduce your repair time 3 to 10 hours. The further from its origin that a
defect is detected, the more it will cost to fix.

A. Error Prone Modules

About 20% of the modules in a program are typically responsible for about 80 % of the errors.
Error prone modules tend to be more complex than other modules in the system, less structured, and unusually large.
If development speed is important, make identification and redesign of error-prone modules a priority.

B. Testing
The two basic kinds of execution testing are (1) units tests, in which the developer checks his or her own code to verify that it works
correctly, and (2) system tests, in which an independent tester checks to see whether the system operates as expected.

C. Technical Reviews

Used to detect defects in requirements, design, code, test cases, or other project artifacts.

1. Walkthroughs—refers to any meeting at which two or more developers review technical work with the purpose of
improving its quality. They are useful to rapid development because you can use them to detect defects well before
testing.
2. Code reading—the author of the code hands out source listing to two or more reviewers. The reviewers read the code and
report any errors to the author.
3. Inspections—are a kind of formal technical review that has been shown be extremely effective in detecting defects
throughout a project. Developers receive special training in inspections and play specific roles during the inspection:
moderator, reviewers, author, and scribe. May be up to 20 times more efficient than testing.
Technical reviews tend to find different kinds of errors than testing does. They find defects earlier than testing and are more cost
effective.

IV. Following the Instructions (i.e. software-development fundamentals)

If you don’t master the fundamentals first, you’ll lack the project control needed to develop rapidly. You often won’t even know
whether you’re succeeding or failing until late in the project.