|
|||||||
|
|
|
|||||
|
|
|||||||
OOD and the development lifecycle are used in software development but if you are able to get your head around this it can be used to organize your thoughts in many many other areas in a powerful way.
PART ONE:- Introduction to Object Oriented Design Theory
1.1 Introduction
Object-oriented design has evolved as a means of managing the complexity inherent in many different kinds of systems. The future development of systems to deal with complex problems will require object-oriented technology as part of its fundemental design. Object-oriented design is built upon a sound engineering foundation, whose elements we collectively call the object model. The object model encompasses the principles of:
1. abstraction 2. encapsulation 3. modularity 4. hierarchy 5. concurrency 6. persistence
The following appendix will provide the reader with an understanding of the fundemental concepts of the object model.
1.2 Complexity
"The more complex the system, the more open it is to total breakdown."
The failure to master the complexity of systems will result in their implementation being late, over budget and deficient in their stated requirements. This will lead to a crisis condition.
eg. A car is a device of moderate complexity. It is composed of an outer shell, windows, wheels and an engine. Some of these components are complex in themselves and can be sub-divided into other objects.
1.3 The Five Attributes of Complexity:
1. Frequently, complexity takes the form of a hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until some lowest level of elementary componenets is reached.
2. The choice of what components in a system are primitive is relatively arbitrary and is largely up to the discretion of the observer of the system.
3. Intracomponent linkages(modularity) between objects are generally stronger than internal component linkages.
4. Hierarchic systems are usually composed of only a few different kinds of subsystems in various combinations and arrangements.
5. A complex system that works is invariably found to have evolved from a simple system that worked.
3.4 The Meaning of Encapsulation
"Encapsulation is the process of hiding all of the details of an object that do not contribute to its essential characteristics."
Abstraction focuses upon the outside view of an object and encapsulation(also known as information hiding) prevents clients from seeing its inside view, where the behaviour of the abstraction is implemented. In this manner, encapsulation provides explicit barriers among different abstractions. For abstraction to work, implementations must be encapsulated. In practice, this means that each class must have two parts: an interface and an implementation.
3.5 Object-Oriented Decomposition
"When designing complex system, it is essentaial to divide it into smaller and smaller objects each of which may be refined independantly."
Each object in a solution embodies its own unique behaviour, and each one models some object in the real world. From this perspective, an object is simply a tangible entry which exhibits some well-defined behaviour. Objects do things, and we ask them to perform what they do by sending them messages. because our decomposition is based upon objects, we call this object-oriented decomposition.
3.6 What is an Object Oriented Design?
"An Object-Oriented system is a method of implementation in which parts of the system are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierachy of classes united via inheritance relationships."
There are three important parts to his defnition of object-orientation.
1. It uses objects as its fundemental logical building blocks.
2. each object is an instance of some class
3. classes are related to one another via inheritance relationships.
When the architecture of a system has been succesfully implemented using Object Oriented Design then the whole architecture can undergo an object-oriented decomposition. Different notations are used to express the different models of the logical (class and object structure) and physical (module and process architecture) design of a system.
The support for object-oriented decomposition is what makes object-oriented design quite different from structured design: the former uses class and object abstractions to logically structure systems, and the latter uses algorithmic abstractions. The term object-oriented design is used to refer to what leads to an object-oriented decomposition.
3.7 Object-Oriented Analysis
"Object-oriented analysis is a method of analysis that examines requirements from the perspective of classes and objects."
How are OOA and OOD related? Basically, the products of object-oriented analysis can serve as the models from which we may start an object oriented design; the products of object-oriented design can be used as blueprints for completely implementing a system using object-oriented methods.
3.8 Abstraction
"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer."
Deciding upon the right set of abstractions for a given domain is the central problem in object-oriented design. It has been suggested that there is a spectrum of abstraction from which objects which closely model problem domain entities to objects which have really no reason for existence. From the most to the least useful, these kinds of abstractions include the following:
1. Entity Abstraction An object that represents a useful model of a problem domain entity.
2. Action Abstraction An object that provides a generalized set of operations, all of which perform the same kind of function.
3. Virtual Machine Abstraction An object that groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations.
4. Coincidental Abstraction An object that packages a set of operations that have no relation to each other.
All abstractions have static as well as dynamic properties. For example, a certain type of NHS operation takes up a certain amount of money of the Government's Treasury. This is a static property. The value of each object is dynamic, relative to the lifetime of the object: an operation may cost or more or cost less, its procedure may change, its name may change.
3.9 What is and What is not a Class?
"Whereas an object is a concrete entity that exists in time and space, a class represents only an abstraction"
An abstraction is the "essence" of the object. Thus, we may speak of the class of mammal and flower etc.
In everyday terms, we may define class as a group, set, or kind, marked by common attributes, a group division, distinction, or rating based on quality, degree of competence, or condition.
In the context of OOD, we define a class as follows:
"A class is a set of objects that share a common structure and a common behaviour."
A single object is simply an instance of a class.
3.10 Relationships Among Classes
Consider the differences among the following classes of objects: flowers, daises, red roses, yellow roses, and petals.
We can make the following observations:
1. A daisy is a kind of flower
2. A red rose is a kind of flower
3. Red roses and yellow roses are both kinds of roses
4. A petal is a part of both kinds of flowers
It can be concluded that classes, like objects, do not exist in isolation. Rather, for a particular domain, the key abstractions are usually related in a variety of interesting ways, forming the class structure of our design.
We assert relationships between two classes for one of two reasons. First, a class relationship might indicate some sort of sharing. For example, daises and roses are both kinds of flowers, meaning that both have brightly coloured petals both emit frangrance, and so on. Second, a class relationship might indicate some kind of semantic connection. Thus, we say that red roses and yellow roses are more alike than are daises and roses, and daises and roses are more closely related than are petals and flowers.
There are three basic kinds of class relationships. The first of these is generalization, denoting a "kind of" relationship. For instance, a rose is a kind of flower, meaning that a rose is a specialized subclass of the more general class, flower. The second is aggregation, which denotes a "part of" relationship. Thus, a petal is not a kind of flower; it is a part of a flower. The third is association. Briefly, association denotes some semantic connection among otherwise unrelated classes. As an example, roses and candles are largely independant classes, but they both represent things that we might use to decorate a dinner table.
Several common approaches have evolved to express generalization, aggregation, and association. Specifically, most object based ideas support combinations of the following relationships among classes:
1. Inheritance relationships
2. Using realtionships
3. Instantion Relationships
4. Metaclass Relationships
Inheritance is perhaps the most powerful of these relationships and may be used to express both generalization and association.
We also need relationships which support aggregation. Furthermore we need instantiation relationships, which like inheritance, support both generalization and association, although in an entirely different way.
Metaclass relationships are quite different still and are not explicitly supported by every object-based or object-oriented programming language. Basically, a metaclass is the class of a class; thus it allows us to treat classes as objects.
Inheritance relationships will be looked at more closely,
3.11 Inheritance Relationships Among Classes
A given class typically has two kinds of clients:
1. Instances
2. Subclasses
It is often useful to define different interfaces for these two kinds of clients. This is precisely the motivation for the public, protected, and private parts of a class definition; at the moment the designer can chose what members are visible to instances, to subclasses, and to both clients.
Inheritance means that subclasses inherit the structure of their superclass.
There is some tension between inheritance and encapsulation. The use of inheritance exposes some of the secrets of an inherited class. Practically, this means that to understand the meaning of a particular class, you must often study all of its superclasses, sometimes including all their inside views.
Subclasses also inherit the behaviour of their superclasses. Most, object oriented methods permit a superclass to be inherited as well as excluded and also permit methods to be added and refined in a sub-class. Any superclass method may be refined in a subclass.
3.12 Relationships between Classes and Objects
Classes and objects are seperate yet intimately related concepts. Specifically, every object is the instance of some class, and every class has zero or more instances. For practically all applications, classes are static; therefore their existence, semantics and relationships are fixed prior to the execution of the system. Similarly, the class of most objects is static, meaning that once an object is created, its class is fixed. In sharp contrast, however, objects are typically created and destropyed at a furious rate during the development on an application.
Consider the classes and objects in the implementations of an air traffic control system. Some of the more important abstractions include planes, flight plans, runways, and air spaces. By their very definition the meanings of these classes and objects are relatively static. They must be static, for otherwise one could not build an application that embodied knowledge of such commonsense facts as that planes can take off, fly, and then land, and that two should not occupy the same space at the same time. Conversely, the instances of these classes are dynamic. At a fairly slow rate, new runways are built, and old ones are deactivated. Faster yet, new flight plans are filed, and old ones are filed away. With great frequency, new planes enter a particular air space, and old ones leave.
3.13 The Role of Classes and Objects in Design
During analysis and the early stages of design, the developer has two primary tasks:
1. Identify the classes and objects that form the vocabularly of the problem domain.
2. Invent the structures whereby sets of objects work together to provide the behaviours that satisfy the requirements of the problem.
Collectively, we call such classes and objects the key abstractions of the problem, and we call these cooperative structures the mechanisms of the implementation.
During this phase of development, the focus of the developer must be upon the outside view of these key abstractions and mechanisms. This view represents the logical framework of the system, and therefore encompasses the class structure and object structure of the system. In the later stages of the design and then moving into implementation, the task of the developer changes: the focus is on the inside view of these key abstractions and mechanisms, involving their physical representations. We may express these design decisions as part of the systems module architecture and process architecture.
3.14 Measuring the Quality of Abstraction
"A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework. With object-oriented design, these parts are the classes and objects that make up the key abstractions of the system, and the framework is provided by its mechanisms.
PART 2:- The Development Lifecycle
4.1 Introduction
The goal of the architect of any system, whether it be running a shop, a bank, designing aircraft or managing the economy is to meet the requirements of the user with the given resources. The effective misunderstanding of complex problems by both system user and architect can lead to ineffectual solutions which lead to breakdown. The "waterfall" model of the Development Lifecycle is a modern ethos to solving complex problems. The model has a solid engineering foundation which helps in dealing with the implementation of problems, reliably, predictably and efficiently as possible. It recognises that the development process has a life cycle that spans from its initial conception to its retirement and that the life cycle must be anticipated and controlled to achieve the desired qualities in the result.
The choice of the waterfall model may be based on the criticality and complexity of the application. Simple and well understood applications are less demanding in terms of the formal structure of the process by which they are produced; larger and more critical applications may require decomposition of the process into finer units in order to achieve better control and ensure rigorous development.
The Waterfall model is made up of five sections:
1) Feasability Study To examine the costs and benefits of the proposed application. To understand the problem; identify solutions; their costs and their potential benefits to the user.
2) Requirements analysis and specifiaction The systems services, constraints and goals are established by consultation with system users. They are then defined in a manner which is understable by both users and development staff.
3) Design and Specification The systems design process partitions the requirements and establishes an overall systems architecture. Systems architecture is usually done by Object Oriented Design.
3) Implementation and Testing The design is realized as a set of units. Unit testing involves verifying that each unit meets its specification.
4) Integration and system testing The individual units are integrated and tested as a complete system to ensure that the requirements have been met.
5) Operation and Maintenance The system is put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system's services as new requirements are discovered.
The premature termination of any section may mean that the system will not do what the user wants. This does not mean the system is a linear flow. It may become necessary at a point to return to a particular stage if it is discovered that something is missing from it. Refinements and additions can be thought of at the final stage and thus the whole process 1-5 could be carried out again.
4.2 Feasability Study
At this stage, we have a basic definition of our problem. We then proceed to identify alternative solutions analyzing the avaliable resources, the costs and delivery dates. The stage tries to anticipate the future development of the process and to try to derive information that may help to decide whether the development is worthwhile. We may incur the risk of constraining the future development process too early when the avaliable information is too fuzzy. We may have to return to this stage in the future if the information gained later requires alterations or examination of the alternatives.
Its result is a document that should conatin at least the following items:
1. a defintion of the problem
2. alternative solutions and their expected benefits
3. required resources, costs, and delivery dates in each proposed alternative solution.
4.3 Requirements Analysis and Definition
There are two purposes to this document. The first is that is must be analyzed and be confirmed by the user in order to verify whether it captures all of the users expectations. Also, it must define the functionality of the system without precisely detailed module structures or algorithms. The reason is that the requirements should not unduly constrain in the design and the implementation activity. The result is a requirements specification document, which documents what the analysis has produced. The document must be understandable, precise, complete, consistent and unambiguous. Also, it must be easily modifiable, since we know that it must evolve in order to accomodate the evolutionary nature of large systems.
The application must be understood and then described at different levels of abstraction, from its overall aspects down to any necessary details. The application must be partitioned into parts that are separetly analyzable. It should be possible to view, understand, and describe the application from different view points.
Since our understanding of a particular problem may be constantly changing it can be difficult to be definitive. Systems are usually designed to improve upon the status quo where either no system or an inadequate system is in place. It can be difficult to anticipate what effects the 'improved' system is likely to have.
4.31 Viewpoint Analysis
This type of analysis can help us in our requirements specification. Viewpoint analysis takes the form of a brainstorming session during which the architects and users suggest possible viewpoints. At this stage of the analysis, no attempt should be made to impose a structure on the diagram and any possible way of looking at the system should be written down. Sources of information which may be used in creating this initial view of the system may be documents setting out the high level goals of the system.
There is no such thing as a correct viewpoint. Different architects will construct seemingly quite different diagrams. After analysis and refinement these should converge to comparable views of the system. At this stage, functional and non-functional viewpoints should be identified. Non-functional viewpoints are concerned with constraints such as cost, security and safety imposed on the system. Functional viewpoints fall into two classes:
1) Bounding viewpoints are functional viewpoints outside the system but which affect or are affected by the system. An obvious example of this type of viewpoint is the viewpoint of the user.
2) Defining viewpoints are part of the system being modelled and are used to define local system functionality.
The next stage after viewpoint analysis would be to impose a structure on the identified viewpoint clusters and represent this in a viewpoint structure diagram. As, a general rule no viewpoint should have more than five sub-viewpoints.
The viewpoint analysis should help us with the requirements specification document which should be in three parts:
1. Functional Requirements. These decide what the product does by using informal, semiformal, formal notations, or a suitable mixture.
2. Non-Functional Requirements. These may be classified into the following categories:reliablity (avaliablity, integrity, security, safety, etc), accuracy of results, performance, operating constraints, physical constraints.
3. Requirements on the development and maintenance process. These include quality control procedures- in particular, system test procedure-priorities of the required functions, likely changes to the system maintenance procedures, and other requirements.
Large systems usually have a diverse user community who have different, and sometimes conflicting requirements and priorities. The final system requirements are inevitably a compromise. The people who pay for the system and users of the system are rarely the same people. System producers impose requirements because of budgetary constraints. These are likely to conflict with user requirements.
The Requirements Document should be made up of four seperate parts.
1) The Feasability Study An estimate is made of whether the identified user needs can be satisfied with the current system and technologies, and whether the proposed system is within budget.
2) Requirements Capture and Analysis This is the process of deriving the system requirements through observation of existing systems, discussing with potential users and architects, task analysis and so on.
3) Requirements Definition A basic system model is formulated and used as an abstract description of the system requirements. This document describes the system from an end-users point of view.
4) Requirements Specification A detailed and precise description of the system requirements is set out to act as a basis for a contract between client and architect. The creation of this document might be carried out in parallel with some high-level design and the design and requirements activities influence each other as they develop. During the creation of this document, errors in the requirements defintion are inevitably discovered and it must be modified accordingly. Data flow diagrams or simple block diagrams should be used to make the system more undestandable to the user.
4.4 System Design and Specification
Design involves decomposing the system into modules. The result is a design specification document, which contains a description of the software architecture: what each module is intended to do and the relationships among modules. The decomposition process may proceed iteratively and/or may be described through levels of abstraction. Each component identified at some step may be decomposed into subcomponents.
In Object-Oriented design, the system is viewed as a collection of objects rather than as functions. The system state is decentralized and each object manages its own state information. Objects have a set of attributes defining their state and operations which act on these attributes. Objects are usally members of an object class whose defninition defines attributes and operations of class members. These may be inherited from one or more super-classes so that a class definition need merely set out the differences between that class and the super-class. Conceptually, objects communicate by exchanging messages; in practice, most object communication is achieved by an object called a procedure associated with another object.
4.41 Data Flow Diagrams
Data flow diagrams (DFD's) are a well-known and widely used notation for specifying the functions of an information system. They describe systems as collections of data that are manipulated by functions. Data can be organized in several ways: they can be stored in data repositories, they can flow in data flows, and they can be transferred to or from the external environment.
One of the reasons for the success of DFDs is that they can be expressed by means of an attractive graphical notation that makes them easy to use.
The basic elements of a DFD are:
1) Bubbles, used to represent functions.
2) Arrows, used to represent data flows. Arrows going to bubbles represent input values that belong to the domain of the function represented by the bubble. Outgoing arrows represent the results of the function ie. values that belong to the range of the function.
3) Open boxes, used to represent data stores. Arrows entering (exiting) open boxes represent data that are inserted in (extracted from) the data store.
4) I/O boxes, used to represent data acquistion and production during human-computer interaction.
The following figure describes a simplified information system for a public library. The data and functions shown are not necessarily computer data and computer functions. The DFD describes physical objects, such as books and shelves, together with data stores that are likely to be, but are not necessarily, realized as computer files. Getting a book from the shelf can be done automatically. In both cases, the action of getting a book is represented by a function depicted by a bubble. The figure could even represent the organization of a library with no computerized procedures.
The figure also describes the fact that, in order to obtain a book, the following are necessary: an explicit user request consisting of the title and the name of the author of the book and the user's name; access to the shelves that contain the books; a list of authors; and a list of titles. These provide the information necessary to find the book.
The way the book is usually obtained, however, is not all mentioned in the figure. If we did not use our previous experience about the way one borrows a book from a library, there would be no way to deduce this information from the figure. Thus, we should consider this DFD as a first approximation of the description of a library information system.
diagram of library system 4.42 Deriving Structure charts
The notion of the 'best' solution is subjective and the designer's aim should be to derive a design where program units exhibit a high degree of cohesion and a low degree of coupling.
The indentification of loosely coupled, highly cohesive units is simplified if units are considered to be principally responsible for dealing with one of four types of data flow:
1) Input The unit is responsible for accepting data from a unit at a lower level in the structure chart and passing the data on to a higher level unit in some modified form.
2) Output The unit is responsible for accpeting data from a higher level unit and paasing it to a lower level unit.
3) Transform A unit accepts data from a higher level unit, transfowms that data and passes it back to that unit.
4) Co-ordinate A unit is responsible for controlling and managing other units.
The first step in converting a data flow diagram to a structure chart is to identify the highest level input and output units. These units are those concerned with passing data up and down the hierarchy but are furthest removed from physical input and output. This step does not usually include all transforms and the remaining transforms are termed central transforms.
Identifying the highest level input and output transforms depends on the skill and experience of the system designer. One possible way to approach this task is to trace the inputs until a transform is found whose output is such that its input cannot be deduced from output examination. The previous bubble then represents the highest level input unit. Processes which validate inputs or add information to them are not central transforms; processes which sort input or filter data from it are. A similarcriterion is used to establish the highest level output transform.
The first level of the structure chart is produced by representing the input and output units as single boxes and each central transform as a single box. The box at the root of the structure chart is a coordinate unit. This factoring process may then be repeated for the first level units in the structure chart until allbubbles in the data flow diagram are represented in the structure.
In the design report generator data flow diagrams the output are those transforms which are concerned with producing reports for link and node type, report integration and printing. These are all concerned with the formatting and organization of design entity descriptions.
Deciding on which transforms are input transformations is more difficult. Recall the rule of thumb is to examine the transformation and when it is not possible to determine the input from the output, a central transform has been discovered. The sorting of entity names is therefore a central transform. This results in the first level structure shown in the following figure. Applying the same process to the sort unit to derive the second level structure results in the following figure. Each node in a structure chart of a well-structured design should have between two and seven subordinates. If a node has only a single subordinate, this implies that the unit represented by that node may have a low degree of cohesion. It suggests that the unit is not a single function as the existence of a single subordinate means that a function has been factored out. If a node has many subordinates, this implies that the design has been devveloped to too low a level at this stage. Design quality metrics based on structure charts is covered in later chapters.
An initial design report generator structure The information avaliable in data flow diagrams is useful in deriving structure charts but other components may be included in a structure chart which are not directly concerned with data transformations and which do not therefore appear on the data flow diagram. For example, components which are concerned with logging-in and logging-out a user, system initialization and any other components concerned with system control rather than data processing may be identified.
Structure chart derivation is therefore a two-stage process. From the data flow design, an initial structure may be derived and this may be used in the construction of a design description which includes control information and which may identify firther control functions. Following the design description, the structure chart may be modified to include additional control componenets.
Data flow diagram of design report generator
Structure chart of design report generator
4.5 Implementation and Unit Testing
Module testing is the main quality control activity that is carried out in this phase. Other such activities include inspections to check adherence to standards and, more generally, to check for a disciplined implementation style, as well as checking of required qualities other than functional correctness (eg. performance), although this is often better done at a later stage.
At the testing phase(Verification & Validation phase), the system architect must convince the system buyer that the system meets its requirements. During testing activities, information is fed back to earlier life cycle phases. Verification checks if the product which is under construction meets the requirements definition. Validation checks if the product's functions are what the customer really wants.
4.6 Integration and Systems Testing
Integration testing involves testing collections of modules as they are integrated, with each individual module having been tested separately previously. Often, this is done not in a single shot, but incrementally on progressively larger sets of modules, from small subsystems until the entire system is built.
At the final stage, the development organization performs system testing on the running application. Once the application has undergone system testing, it may be put through actual use within the devlopment organization. The purpose of this step is to test the system under realistic conditions, but with understanding and forgiving users. This kind of testing is called alpha testing.
Internal standards may be adpoted on the way integration is to be performed, such as top down or bottom up, and on how to design test data and document the testing activity.
4.61 Top Down Testing
Examination of Functionality starting at the highest system level gradually descending through the system to verify that each part is contributing to the overall systems design architecture and requirements specification. Flaws in the structure can then be identified and sorted quickly. If a fault is corrected at a higher level then it may correct lower level faults.
If the various documents were stored on an internet system. The monitoring of the whole structure of the system could be done quickly and efficiently to identify flaws in a particular module of the systems architecture.
4.7 Operation and Maintenance
During the final life cycle phase (operation and maintenance), information is fed back to previous development phases. Errors and omissions in the original requirements come to light and the need for new functionality can be indentified. We define maintenance as the set of activities that are performed after the system is delivered to the customer. Basically, maintenance consists of correcting any remaining errors in the system (corrective maintenance), adapting the application to changes in the environment (adaptive maintenance), and improving, changing, or adding features and qualities to the application (perfective maintenance). Many errors are not removed until after the system is delivered. This is a serious problem because the later the errors are found, the more expensive it is to remove them. It is certainly preferable and cheaper to remove a requirements error during analysis than after the system is delivered.
4.8 Management
The project manager has many tasks. Good documentation of goals, the development of schedules, budget estimations and costs, resource requirements, risk analysis. The human resource requirement involves recruiting, hiring, training, rewarding, retraining of project members. The manager then is required in putting the plan into action. Then monitoring to ensure that progress of the project and taking necessary actions to handle both forseen and unforseen deviations from the plan.
Project Planning
A project needs a clear statement of goals to guide their daily decision making. Many people on typical projects spend many hours discussing alternatives that are known clearly to the project manager, but have not been documented properly. The goal of the project planning stage is to identify all the external requirements for and constraints on the project.
Another part is how best to meet the requirements given finite constraints. This includes resource and cost estimation. The clearer and more complete the requirements are, the easier it is to determine the resources required. The best approach is to develop the resource requirement incrementally, revising current estimates as more information becomes avaliable.
Project Control
The purpose of controlling a project is to monitor the progress of the activities against the plans to ensure that the goals are being approached and eventually achieved. It is important to plan rigorously to prevent the need for corrective action.
Work Breakdown Structures
Most project control techniques are based on breaking down the goal of the project into several intermediate goals. Each intermediate goal can in turn be broken down further. Thsi process can be repeated until each control is small enough to be well understood. We can then plan for each goal individually-its resource requirements, assignment of responsibility, scheduling, etc.
A semiformal way of breaking down the goal is called the work breakdown structure(WBS). In this technique, one builds a tree whose root is labelled by the major activity of the project such as "create an email system". Each node of the tree can be broken down into smaller components that are designated the children of the node. This "work breakdown" can be repeated until each leaf node in the tree is small enough to allow the manager to estimate its size, difficulty, and resource requirements.
The goal of a work breakdown structure is to identify all the activities that a project must undertake. The tasks can be broken down into as fine a level of detail as is desired or necessary. The structure can be used as a basis for estimating the amount of resources necessary for the project as a whole by estimating the resources requires for each leaf node.
The work breakdown structure is a simple tool that gives the manager a framework for breaking down large tasks into more manageable pieces. Once these manageable pieces have been identified, they can be used as units of work assignment. The structure can then be refined and extended easily by labelling the nodes with appropriate information, such as the planned length of the activity, the name of the person responsible for the activity, and the starting and ending date of the activity. In this way, the structure can summarize the project plans.
The work breakdown structure can also be an input into the scheduling process, as we will see in the following subsections. In breaking down the work, we are trying to decide which tasks need to be done. In scheduling, we decide the order in which to do these tasks. Each work item in the work breakdown structure is associated with an activity to perform that item. A shedule tries to order the activities to ensure their timely completion.
Two general scheduling techniques are Gantt charts and PERT charts.
Gantt Charts
Gantt charts are a project control technique that can be used for several purposes, including scheduling, budgeting, and resource planning. A Gantt chart is a bar chart, with each bar representing and activity. The bars are drawn against a time line. The length of each bar is proportional to the length of time planned for the activity.
We estimate the numbers of days required for each of the tasks as follows: initial design, 45; implementation of sort routines, 60; implementation of interface , 180; integration and testing, 90; and writing the manual 90. Using these estimates, we can draw the Gantt chart for the project. If the work breakdown structure produced sixteen different tasks. Then the tables and the Gantt chart may look like the following:
diagram of Gantt chart1 Gantt 2 Table Table
The white part of the bar shows the length of time each task is estimated to take. The gray part shows the "slack" time, that is, the latest time by which a task must be finished. One way to view the slack time is that, if necessary, we can slide the white area over the grey area without forcing the start of the next activity to be delayed. For example, we have the freedom to delay task 5 by fifteen weekd and still have it finished to avoid delaying the integration and testing activity. The chart shows clearly that task 3 can only begin after the completion of task 2. A bar that is all white, such as that representing the code generator task, has no slack and must be started and completed on the schedule dates if the schedule is to be maintained. it is these three tasks that determine the total length of time the project is to take.
PERT Charts
These charts are a network of boxes (or circles) and arrows. There are different variations of PERT charts. Some use the boxes to represent activities, and some use the arrows to do so. Each box thus represents an activity. The arrows are used to show the dependancies of activities on one another. The activity at the head of an arrow cannot start until the activity at the tail of the arrow is finished. Just as with the nodes in the work breakdown structure, the boxes in a PERT chart can be decorated with starting and ending dates for the activties; the arrows help in computing the earliest possible starting dates and ending dates for the activties; the arrows help in computing the earliest possible starting dates for the boxes at their heads. Some boxes can be designated as milestones. A milestone is an activity whose completion signals an important accomplishment in the life of the project. On the other hand, failure to make a milestone signals trouble to the manager and requires an explicit action to deal with deviation from the schedule.
Some of the advantages of PERT are as follows:
1) It forces the manager to plan.
2) It shows the interrelationships among the tasks in the project and, in particular, clearly identifies the critical path of the project, thus helping to focus on it. The critical path is shown by a double line. We may decide to build a separate subproject for this activity alone, or put our best people on the project, or monitor the critical activity very closely. The fact that the PERT chart has exposed the critical path allows us the opportunity to consider alternative approaches to cope with a potential problem.
3) It exposes all possible parallelism in the activties and thus helps in allocating resources.
4) It allows scheduling and simulation of alternative schedules.
5) It enables the manager to monitor and control the project.
Gantt charts can be derived automatically from PERT charts. Each kind of chart has its own place in the manager's toolbox of control techniques. The Gantt chart helps in planning the utilization of resources, while the PERT chart is better for monitoring the timely progress of activities.
Decentralized-Control Team Organization
In a decentralized-control team organization, decisions are made by consensus and all work is considered group work. Team members review each other's work and are responsible as a group for what every member produces.
Such a "democratic" organization leads to a higher morale and job satisfaction and, therefore, to higher productivity. The engineers feel more ownership of the project and responsibility for the problem, leading to a higher quality in their work. A decentralized-control organization is more suited for long-term projects because the amount of intragroup communcation that it encourages leads to a longer development time, presumably accomplied by lower life cycle costs. The proponents of this kind of team organization claim that it is more appropriate for less understood and more complicated problems because agroup can invent better solutions than a single individual. Such an organization is based on a technique referred as the "egoless" system.
On the negative side, decentralized-control team organization is not appropriate for large teams, where the communication overhead can overwhelm all staff.
Risk Management
Any project, however, runs the risk of not producing the desired product, over-spending its allotted resource budget, or overwhelming its allotted time. Risk accompanies any human activity.
Risk analysis and control is a topic management theory. Several standard techniques exist for identifying project risks, assesing their impact, and monitoring and controlling them. Knowledge of these techniques allows a project manager to apply to them when necessary to increase the chances of success of a project.
'Heaven and Earth cannot achieve everything;
The sage is not capable of everything;
None of the myriad things can be used for everything.
For this reason
It is the office of heaven to beget and to shelter,
The office of earth to shape and to support,
The office of the sage to teach and reform.
The office of each thing to perform its function.'
{Lieh Tzu, Chapter 1}
The reward of good and evil is like the shadow accompanying a body, and so it is apparent that heaven and earth are possessed of crime recording spirits. . . .
The right way leads forward; the wrong way backwards.
Do not proceed on an evil path.
Do not sin in secret.
Accumulate virtue, increase merit.'
{Lao Tzu}