Basic Principles
7.1.2 Basic Principles
Fred Brooks, the well-known author of The Mythical Man-Month [BRO95], was once asked how software projects fall behind schedule. His response was as simple as it was profound: "One day at a time."
The reality of a technical project (whether it involves building a hydroelectric plant or developing an operating system) is that hundreds of small tasks must occur to accomplish a larger goal. Some of these tasks lie outside the mainstream and may
be completed without worry about impact on project completion date. Other tasks lie on the "critical” path. 4 If these "critical" tasks fall behind schedule, the completion date of the entire project is put into jeopardy. The tasks required to
The project manager’s objective is to define all project tasks, build a network that achieve the project
depicts their interdependencies, identify the tasks that are critical within the network, manager’s objective
and then track their progress to ensure that delay is recognized "one day at a time." should not be
performed manually. To accomplish this, the manager must have a schedule that has been defined at a There are many
degree of resolution that enables the manager to monitor progress and control the excellent project
project. scheduling tools. Use
Software project scheduling is an activity that distributes estimated effort across the them. planned project duration by allocating the effort to specific software engineering tasks.
3 You might also add that adding more people does not reduce calendar time proportionally. 4 The critical path will be discussed in greater detail later in this chapter.
CHAPTER 7
PROJECT SCHEDULING AND TRACKING
It is important to note, however, that the schedule evolves over time. During early stages of project planning, a macroscopic schedule is developed. This type of sched- ule identifies all major software engineering activities and the product functions to which they are applied. As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule. Here, specific software tasks (required to accomplish an activity) are identified and scheduled.
“Overly optimistic Scheduling for software engineering projects can be viewed from two rather dif- scheduling doesn’t
ferent perspectives. In the first, an end-date for release of a computer-based system result in shorter
has already (and irrevocably) been established. The software organization is con- actual schedules, it
results in longer strained to distribute effort within the prescribed time frame. The second view of soft- ones.”
ware scheduling assumes that rough chronological bounds have been discussed but
Steve McConnell
that the end-date is set by the software engineering organization. Effort is distributed to make best use of resources and an end-date is defined after careful analysis of the software. Unfortunately, the first situation is encountered far more frequently than the second.
Like all other areas of software engineering, a number of basic principles guide software project scheduling:
Compartmentalization. The project must be compartmentalized into a number of manageable activities and tasks. To accomplish compartmental- ization, both the product and the process are decomposed (Chapter 3). Interdependency. The interdependency of each compartmentalized activity or task must be determined. Some tasks must occur in sequence while others
When you develop a can occur in parallel. Some activities cannot commence until the work prod- schedule, compartmen-
uct produced by another is available. Other activities can occur independently. talize the work,
Time allocation. Each task to be scheduled must be allocated some num- represent task inter-
ber of work units (e.g., person-days of effort). In addition, each task must be dependencies, allocate
assigned a start date and a completion date that are a function of the interde- effort and time to each
task, define respon- pendencies and whether work will be conducted on a full-time or part-time sibilities for the work
basis. to be done, and define
Effort validation. Every project has a defined number of staff members. As outcomes and
time allocation occurs, the project manager must ensure that no more than milestones. the allocated number of people have been scheduled at any given time. For
example, consider a project that has three assigned staff members (e.g., 3 person-days are available per day of assigned effort 5 ). On a given day, seven concurrent tasks must be accomplished. Each task requires 0.50 person days of effort. More effort has been allocated than there are people to do the work. Defined responsibilities. Every task that is scheduled should be assigned to a specific team member.
5 In reality, less than three person-days are available because of unrelated meetings, sickness, vacation, and a variety of other reasons. For our purposes, however, we assume 100 percent availability.
Defined outcomes. Every task that is scheduled should have a defined out- come. For software projects, the outcome is normally a work product (e.g., the design of a module) or a part of a work product. Work products are often combined in deliverables. Defined milestones. Every task or group of tasks should be associated with
a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality (Chapter 8) and has been approved.
Each of these principles is applied as the project schedule evolves.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more