Timeline Charts
7.7.1 Timeline Charts
When creating a software project schedule, the planner begins with a set of tasks (the work breakdown structure). If automated tools are used, the work breakdown is input as a task network or task outline. Effort, duration, and start date are then input for each task. In addition, tasks may be assigned to specific individuals.
As a consequence of this input, a timeline chart, also called a Gantt chart, is gen-
A timeline chart erated. A timeline chart can be developed for the entire project. Alternatively, sepa- enables you to
rate charts can be developed for each project function or for each individual working determine what tasks
will be conducted at a on the project. given point in time.
Figure 7.4 illustrates the format of a timeline chart. It depicts a part of a software project schedule that emphasizes the concept scoping task (Section 7.5) for a new word-processing (WP) software product. All project tasks (for concept scoping) are listed in the left-hand column. The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task concurrency is implied. The diamonds indicate milestones.
Once the information necessary for the generation of a timeline chart has been input, the majority of software project scheduling tools produce project tables—a tab- ular listing of all project tasks, their planned and actual start- and end-dates, and a variety of related information (Figure 7.5). Used in conjunction with the timeline chart, project tables enable the project manager to track progress.
Work tasks
Week 1
Week 2
Week 3
Week 4 Week 5
I.1.1 Identify needs and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: Product statement defined
I.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnosis Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required Milestone: OCI defined
I.1.3 Define the function/behavior Define keyboard functions Define voice input functions Describe modes of interaction Describe spell/grammar check Describe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI definition complete
I.1.4 Isolation software elements Milestone: Software elements defined
I.1.5 Research availability of existing software Research text editing components Research voice input components Research file management components Research spell/grammar check components Milestone: Reusable components identified
I.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed
I.1.7 Make quick estimate of size
I.1.8 Create a scope definition Review scope document with customer Revise document as required Milestone: Scope document complete
F I G U R E 7.4 An example timeline chart
Planned Actual Planned Actual Assigned Effort
Work tasks
start
start complete complete person allocated Notes
I.1.1 Identify needs and benefits Scoping will Meet with customers
2 p-d require more Identify needs and project constraints
wk1, d1
wk1, d1
wk1, d2
wk1, d2
BLS
1 p-d effort/time Establish product statement
wk1, d2
wk1, d2
wk1, d2
wk1, d2
JPP
1 p-d Milestone: Product statement defined
wk1, d3
wk1, d3
wk1, d3
wk1, d3
BLS/JPP
wk1, d3
wk1, d3
wk1, d3
wk1, d3
I.1.2 Define desired output/control/input (OCI) Scope keyboard functions
1.5 p-d Scope voice input functions
wk1, d4
wk1, d4
wk2, d2
BLS
2 p-d Scope modes of interaction
wk1, d3
wk1, d3
wk2, d2
JPP
1 p-d Scope document diagnostics
wk2, d1
wk2, d3
MLL
1.5 p-d Scope other WP functions
wk2, d1
wk2, d2
BLS
2 p-d Document OCI
wk1, d4
wk1, d4
wk2, d3
JPP
3 p-d FTR: Review OCI with customer
wk2, d1
wk2, d3
MLL
3 p-d Revise OCI as required
wk2, d3
wk2, d3
all
3 p-d Milestone: OCI defined
wk2, d4
wk2, d4
all
wk2, d5
wk2, d5
I.1.3 Define the function/behavior
F I G U R E 7.5 An example project table
CHAPTER 7
PROJECT SCHEDULING AND TRACKING
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