You are on page 1of 50

Practical No.

1 :

SYSTEM REQUIREMENT STUDY (SRS) FOR A PROJECT

OBJECTIVE AND SCOPE OF THE PROJECT

India's blood banking system has serious shortcomings. The gap between demand
and supply of blood is continuously widening. India has an annual requirement of
approximately, 5.0 million units of blood. The actual collection is only
approximately 3.50 million units. A study conducted by the National AIDS Control
Organization (NACO), regarding blood banking services in India has revealed
many shortcomings, including the decentralized nature of blood services, a
shortage of human, technological and financial resources and a deficit in the
availability of blood, especially from voluntary donors. Paradoxically, very few
blood banks are operating to their full capacity. Inappropriate use of blood and
wastage is not an uncommon occurrence. Even during an emergency, the onus is
on the patient's relatives to arrange for replacement of blood.

Blood Bank Management System, the portal bridges the gap between the demand
and supply of blood. This portal aims to bring blood donors and recipients under a
common on-line platform. Donors can register themselves on the system after
going through the basic requirements for donating blood. This portal also has
useful information regarding blood donation.

Chapter 2 THEORETICAL BACKGROUND AND PROBLEM

DEFINATION

Understanding the problem in the existing system & finding requested
solution is the most important activity while planning the project. Hence the

developing a new system we must get through problem associated with the current
system.

 Donors do not have any record of their donations or information related to
their blood diseases.
 For the number of Donors, recipients it should be difficult to maintain the
data in no. of registers and handling the process of blood donation and sales
manually.
 Also the calculations part that is for selling and buying the Blood is also
handled manually in previous system.

The manpower required for this kind of transaction and maintenance of data is
higher than the actual requirement.

Chapter 3 SYSTEM ANALYSIS

3.1 REQUIREMENT ANALYSIS

3.1.1 FUNCTIONAL REQUIREMENTS

a) Strong Data Validation:

There is possibility that user might enter wrong data and wrong data may

cause inconsistency to the database and hence to the system. To avoid this,

data should be validated whenever entered.

b) Automatic updating of the database:

After any transaction is performed, it is necessary that the updating should

be reflected in the database without any inconsistency.

c) Provide efficiency querying based on user requests:

The major purpose is to generate efficient reports on any user request. This

will be done by our query processing system, which should be able to

process any combination of queries will be done dynamically at run time

depending on the user

3.1.2 EXTERNAL INTERFACE REQUIREMENTS

a) User friendly interface:

The interface should be developed in such a manner that it is very user

friendly, this not only improve interaction but also saves data entry time.

b) Making well designed forms for capturing data:

3. The forms for capturing the data should be well-designed using pop-down menus and drag & drop facilities.1 PROCESS MODEL – SOFTWARE ENGINEERING . Delete. which reduce the data entry effort on the part of the user. There are 2 main types of users who will be using the software They are:- 1) Admin 2) User Each user is given the specific rights to access the data in Read only.5.3 PERFORMANCE REQUIREMENTS a) Security: All users are not allowed to access the database.1. Username and Password validation helps to deny unauthorized access to the system. 3. Hence there is a need to check authority of every user. Read Write.

In the verifications. I have tried to find out if there is any misinterpretation of specified any requirements. In this we tried to focus on some distinct attributes of a program like data structure. I have tried to ensure that the design is satisfying the requirements and is of good quality. interface representations and algorithmic detail. the linear sequential mode. In this we tried to translate requirements into representation of the software which can be assessed for quality before coding begins.In the development of software we have used Waterfall Model. . This model encompasses the following activities: a) Analysis Phase: System Analysis:- This refers to the gathering of system requirements. b) System Design Phase: This is actually a multistep process. software architecture. with the goal of determining how these requirements will be accommodated in the system.

design and requirement faults also appear in the code. We have executed program on some test data and output of the program examined to determine if there are any error present. In this we tried to produce simple program which are clear to understanding and modify.2 TOOLS/ENVIRONMENT USED SOFTWARE / HARDWARE REQUIREMENTS SPECIFICATION PLATFORM: Windows XP Professional . Testing is used to detect these errors. I have read the code carefully to detect any discrepancies between the design specification and the actual implementation. in addition to the errors introduced during the coding phase. 3. we translated design of a system into code which can be compiled and executed.c) Code Generation Phase: In this phase. Due to limitations of the verification methods for the previous phase.5. We have used dynamic method to verify the code. In this phase we have done actual coding for all forms. d) Testing: Testing plays a critical role in quality assurance for software.

FRONT END: Visual Studio 2008. . BACK END: SQL Server 2005 HARDWARE REQUIREMENTS: Intel Pentium III 733 MHz or Higher. 256 MB RAM or Higher.

Waterfall model: This model is called as the waterfall model. 2 : Aim: Waterfall Model as the conventional process model to prepare the flow and Gantt Chart. . establishment of the baseline is done which freezes the development products at such point. then the process of formal change is followed in order make the change. If the current requirement is identified in order to change these products.WATERFALL MODEL Practical No. To be done as per Software Engineering approach for any project preferably the student’s project using waterfall model as the process model and to prepare the scheduling chart using Gantt chart. because in this model the more emphasizes is on the complete phase development before proceeding with the next phase of the development. With the combination with some kinds phase completions. Such kind of phases graphic representation during the software development resembling the waterfall model downward flow.

In comparison with the other software development models. This is like top down development approach. as the name indicating waterfall model is made up of sequentially of phases one after the next phase. The phases below the detailed design phase include software as part of their output. At critical points on the waterfall model. the last of which is the product baseline. This is consisting of phases which are independent and needs to be completed sequentially. baselines are established. .As we discussed the basic working this model in above section. Transition from phase to phase is accomplished by holding a formal review that is attended by the contractor and appropriate government agencies. These reviews provide the government insight into the contractor's progress. As showing in above figure 1. following are some of the salient attributes of this model: This is the formal method. The documentation included the documentation from each phase. in this section we will take the overview of basic steps of the model in the software development: Following figure shows the different phase in the development of the software.

This model is used in different ways: Phases are combined. The starting as well as ending points are different. Grantt chart: CONTEXT LEVEL DIAGRAM .

• It is also useful in comparing and highlighting opportunities for productivity improvements in software development. Recipient Practical No. . of developing new software applications and maintaining existing software applications. 3 : Cost Estimation of the project Using Function Point Analysis (FPA) Function Point Analysis (FPA) • It is designed to estimate and measure the time. and thereby the cost.

• The main other approach used for measuring the size.• It was developed by A. and therefore the time required. Working from the project design specifications. of software project is lines of code (LOC) – which has a number of inherent problems. the following system functions are measured (counted): • Inputs-10 Login Homepage Donor details Receptionist detail Donation Product Update product Blood bag sales Product sales Search reports • Outputs-7 Donor details1 Receptionist detail1 Product 1 Update product 1 Blood bag sales 1 Product sales 1 Searchop . Albrecht of the IBM Corporation in the early 1980s.J.

• Files-17 • Inquires-2 • Interfaces-4 Connecton class Purchase Blood bank management system bill Simple Average Complex Inputs 2 4 6 Outputs 3 5 7 .

Files 5 10 15 Inquires 2 4 6 Interfaces 4 7 10 A simple example: Inputs:- 4 simple X 2 = 8 5 average X 4 = 20 2 complex X 6 = 12 Outputs:- 2 simple X 3=6 3 average X 5 = 15 2 complex X 7 = 14 Files:- 12 simple X 5=60 17 average X 10=170 5 complex X 15 = 75 .

Inquiries:- 1 simple X 2=1 2 average X 4 = 8 1 complex X6=6 Interfaces:- 4 average X 7 = 28 Unadjusted function points =423 .

• There are 14 more “Degree of Influences” ( 0 to 5 scale) : DEGREE OF INFLUENCES VALUE • data communications 3 • distributed data processing 4 • performance criteria 4 • heavy hardware utilization 2 • high transaction rate 5 • online data entry 0 • end user efficiency 4 • on-line update 0 • complex computation 3 • reusability 4 • ease of installation 4 • ease of operation 5 • portability 4 • maintainability 4 TOTAL 46 .

65 + [(.46 • TCF = 1.6 Function Point = 67 TIME TAKEN BY THE PROJECT TO BE COMPLETED:- • the programmers in our organization average 21 function points per month and .11 • where DI = Σ ( influence factor value) Function Point = Initial FP X TCF.01) x (46)] • TCF = .01) x (14 DIs )] • TCF = .65 + [(.11 Function Point = 66.65 + 0.• Define Technical Complexity Factor (TCF): • TCF = . Function Point = 60 X 1.

000 . 3 man-months X $3. .the Function Point is 67 67 FP divided by 21 = 3.000 per month (including benefits). . then the [labor] cost of the project will be .000 The total cost for far estimated is $9. =3 man months • the average programmer is paid $3.19 man-months.000=$9.

Software cost estimation is important for making good management decisions. The primary cost driver is the number of delivered source instructions ( DSI ) developed by the project. Declarations are . o INSTRUCTIONS are defined as lines of code or card images. Therefore test drivers and other support software are excluded. It is also connected to determining how much effort and time a software project requires. compilers. 4 : Cost Estimation of the project Using COCOMO Model. and assemblers. o SOURCE codes. The COnstructive COst MOdel ( COCOMO) is an example of regression models used for estimatingsoftware cost and effort. These methods use a basic formula with parameters that aredetermined via a historical database and current project characteristics. The Basic COCOMO Model: The Basic Model makes its estimates of required effort ( measured in Staff-Months SM ) based primarily on your estimate of the software project's size ( as measured in thousands of Delivered Source Instructions KDSI ): SM = a * ( KDSI )b The Basic model also presents an equation for estimating the development schedule ( Time of Develop TDEV ) of the project in months: TDEV= c * ( SM )d Definitions and Assumptions while estimating COCOMO model I 1. DSI is defined such that: o Only source lines that are DELIVERED as part of the product are included. Practical No. Code created by applications generators is excluded. created by project staff and processed into machine code by some combination of pre-processors.

Costs and schedules of other phases ( like requirement phase) are estimated separately. The Development Mode: There are several modes of software development . COCOMO assumes that the requirement specification is not substantially changed after the plans and requirement phase. The detailed COCOMO model assumes that the influence of the software cost drivers is phase dependent. to account for inflation and the difference in salary level of the people required for each phase. code and test phases) Therefore the average SM is higher for early phases. A COCOMO Staff-Month ( SM ) consists of 152 hours of working time.counted as instructions but Comments are excluded. 5. COCOMO avoids estimating labour costs in dollars because of the large variations between organizations in what is included in labour costs and because SM is a more stable unit than dollars. After estimating the effort in SM we convert it into dollar estimate by applying different average dollar per Staff-Month figure for each major phase. vacation and sick leaves. 2. 4. Basic COCOMO and Intermediate COCOMO do not. The COCOMO cost estimates only cover the period between beginning of the design phase and end of the integration and test phase. the senior staff (with high salary )are heavily involved in the requirement and early design phases while junior staff ( less salary ) are more involved in later phases ( detailed design.These different software development modes have cost-estimating relationships which are similar in form. but which yield significantly different . except for distinguishing between development and maintenance. This has to be found to be consistent with practical experience with the average monthly time due to holidays.For example. 3.Any significant modification should be covered by a revised cost estimate.

In the COCOMO Model. one of the most important factors contributing to a project's duration and cost is the Development mode.cost estimates for software products of the same size. COCOMO use the same equations but with different coefficients ( a. stable environment and the product is similar to previously developed products. without generating a great deal of project communication overhead. b. c.38 .4 * ( KDSI )1. If a situation arises where an exact correspondence of the software product to the original requirements would cause an extensive rework.50 * ( SM )0. 1. The Basic COCOMO Effort and schedule equations for organic mode software projects are: SM = 2. Most people connected with the project have extensive experience in working with related systems within the organization and therefore can usefully contribute to the project in its early stages. An organic mode project is relatively relaxed about the way the software meets its requirements and interface specifications. • Semidetached Mode • Embedded Mode To estimate the effort and development time. the project team can generally negotiate a modification of the specifications that can be developed more easily. Every project is considered to be developed in one of three modes: • Organic Mode. d in the effort and schedule equations ) for each development mode. The product is relatively small. Organic Mode: In the organic mode the project is developed in a familiar.05 TDEV= 2. and require little innovation. Therefore before using the COCOMO model we must be able to recognise the development mode of our project.

coding and unit testing in parallel. 2. The size of a Semidetached mode product generally extends up to 300 KDSI. "Intermediate" may mean either of two things: 1. o The team has a wide mixture of experienced and inexperienced people. A mixture of the organic and embedded mode characteristics. but not others. regulations.The project therefore need more effort to accommodate changes and fixes. and operational procedures. Semidetached Mode: In this mode project's characteristics are intermediate between Organic and Embedded. . The product must operate within a strongly coupled complex of hardware. The embedded mode project is generally charting its way through unknown territory to a greater extent than the organic mode project.2. Once the embedded mode project has completed its product design. inflexible constraints and interface requirements. as a large number of people would get swamped in communication overhead. The Basic COCOMO Effort and schedule equations for organic mode software projects are: SM = 3.35 Embedded Mode: In this development mode Project is characterized by tight . An intermediate level of project characteristics. The embedded-mode project does not generally have the option of negotiating easier software changes and fixes by modifying the requirements and interface specifications. it is possible that: o The team members all have an intermediate level of experience with related systems. its best strategy is to bring on a very large team of programmers to perform detailed design. This lead the project to use a much smaller team of analyst in the early stages. o The team members have experience related to some aspects of the system under development. software.0 * ( KDSI )1.12 TDEV= 2. Therefore in an Semidetached mode project.50 * ( SM )0.

50 * ( SM )0.Otherwise the project would take much longer to complete.6 1.05 2.0 1.12 2. Using the Basic COCOMO equations for this development mode we have: TABLE:- Modes A B C D Organic 2.32 Problem : An initial study has determined that the size of the program will be roughly 52.20 2.50 0.20 TDEV= 2.6 * ( KDSI )1. and to the greater amount of effort consumed compared to an organic mode project working to the same total development schedule.4 1.32 Effort : . The Basic COCOMO Effort and schedule equations for organic mode software projects are: SM = 3. This strategy as we will see leads to the higher peaks in the personnel curves of embedded-mode projects.38 Semi-detached 3.000 delivered source instructions for ABC Inventory. This project is a good example of an organic-mode software project.50 0.35 Embedded 3.50 0.

This will ultimately determine the calendar duration of the project. It is very important to note that more staff does not mean proportionately less calendar time.05 = 152 Staff-Months Productivity: 52000DSI / 152 SM = 342 DSI / SM Duration and Staffing: Once an estimate is obtained for effort ( Staff-Month ).4*(52)1. For the example above with estimated effort of 152 SM we have: Schedule: TDEM = 2. More staff complicate communications and this complexity translates into a project slowdown.SM = 2.This distribution varies as a function of the size of the product.38 = 16 months 8 days( 17 months) After estimating the duration of the project the manager can easily determine how many persons in the average must be put on the project: Average Staffing: 152 staff-months / 17 months = 9 FSP ( Full Time Equivalent Software Personnel ) Phase Distribution of Effort and Schedule for Organic Mode: After estimating the effort an schedule of a project we need to determine how to distribute them among different phases of the project. The second equation of the COCOMO model use the estimated effort of the project ( SM ) to suggest the optimum calendar duration of the project.Larger software projects require relatively more time and effort to perform integration and . The project manager must determine how many persons to put on the job.5 * ( 152 )0.

Table 1 and Table 2 present the percentage distribution of the basic software effort and schedule within the development phases of an organic mode product: Table 3 . and are able to compress the programming portion of the program by having larger number of peoples programming components in parallel.test activities. Smaller software projects have a more uniform. flat distribution of labour throughout the development cycle.Phase Distribution of Effort: Semidetached Mode Phase Small ( 2 Intermediate(8 Medium( 32 Large( 128 KDSI) KDSI) KDSI ) KDSI ) Plans & 6% 6% 6% 6% Requirements Product 16 16 16 16 . and have relatively more resources devoted to the phases other than integration and test.

Phase Distribution of Schedule: Oraganic Mode Phase Small ( 2 Intermediate(8 Medium( 32 Large( 128 KDSI) KDSI) KDSI ) KDSI ) Plans & 10% 11% 12% 13% Requirements Product 19 19 19 19 Design Detailed Design & Code & Unit 55 Test 63 59 51 Integration & 18 22 26 30 Test Total 100 100 100 100 Using table 1 and table 2 we can calculate the number of staff needed for programming ( Detailed .design Detailed 26 25 24 23 Design Code & Unit 42 40 38 36 Test Integration & 16 19 22 25 Test Total 100 100 100 100 Table 2 .

Phase Distribution of Effort: Semidetached Mode Phase Small ( 2 Intermediate(8 Medium( 32 Large( 128 KDSI) KDSI) KDSI ) KDSI ) Plans & 7% 7% 7% 7% Requirements Product 17 17 17 17 Design Detailed 27 26 25 24 Design Code & Unit 37 35 33 31 Test Integration & 19 22 25 28 Test .Design & Code and Unit Test ) phase of the previous example: Programming Effort : ( 0.62 ) ( 152 SM )= 94 Staff-Months Programming Schedule: ( 0.55 ) ( 17 )= 9 months Average Staffing: 94 staff-months / 9 months = 10.4 FSP ( Full Time Equivalent Software Personnel ) Phase Distribution of Effort and Schedule for Other Modes: Table 3 and Table 4 present the percentage distribution of the basic software effort and schedule within the development phases of an semidetached mode product: Table 3 .

Total 100 100 100 100 Table 4 .Phase Distribution of Schedule: Semidetached Mode Table 5 and Table 6 present the percentage distribution of the basic software effort and schedule within the development phases of an embedded mode product: Table 3 .Phase Distribution of Effort: Embedded Mode .

Table 4 .Phase Distribution of Schedule: Embedded Mode .

This results from the need to follow and verify software requirements and interface specifications more carefully in the embedded and semidetached mode. The embedded-mode project consumes proportionally less effort in the code and unit test phase. The main differences are: The embedded-mode project consumes considerably more effort in the integration and test phase. The embedded-mode project consumes considerably more schedule in both the plans and requirement phase and the product design phase.By comparing tables 1 through 6 we can see some differences between the effort and schedule distribution of the products developed in different modes. This results from the proportionally higher effort required for the other development phases. This is because of the project's need for more .

" low".If a project is judged normal in some characteristic the adjustment factor will be 1 for that characteristic ( Nominal column in Table 7 ). these added cost drivers help to estimate effort and cost with more accuracy. experience with the implementation language. Intermediate COCOMO Model: The Intermediate COCOMO is an extension of the basic COCOMO model. " Nominal". The embedded-mode project consumes considerably less schedule in the programming phase. The effort equation for the intermediate model has the form of: SM = EAF * a * ( KDSI )b If we assume that the project is "Nominal" in every aspect then all adjustment factors would be 1.. in order to reduce the project's overall schedule. "High". "Very High" and "High" the project falls. experience of the programmers on the team. But coefficients are slightly different for the effort equation. execution speed constraints. which means that that factor has no effect on overall EAF. etc. but . in addition to the EAF the model parameter "a" is slightly different in Intermediate COCOMO. An estimator looks closely at many factors of a project such as amount of external storage required.Also in addition to the size as the basic cost driver we use 15 more predictor variables. and the greater need to perform these phases with a relatively small number of people. the estimator decide where on the scale of "very low" . Here we use the same basic equation for the model. use of software tools. which results in EAF=1. validated requirements and design specifications. This results from the strategy of employing a great many people programming in parallel. for each characteristic. Each characteristic gives an adjustment factor( from the table 7 ) and all factors are multiplied together to to give an Effort Adjustment Factor ( EAF). and the effort equation would have the same form as the Basic mode.thorough.

and defines the Effort Multiplier associated with each rating ( Table 7 ).Project Characteristic Table . Table 7 .the "b" parameter is the same.The effort equation for different modes of Intermediate COCOMO is given in the following table: Bohem in Software Engineering Economics defines each of the cost drivers.

these .10). and all of the other cost drivers are rated to be Nominal.30).Example: If your project is rated Very High for Complexity (Effort Multiplier of 1. and Low for Tools Use (Effort Multiplier of 1.

.5 * 14. and duration of each of the components--allowing you to experiment with different development strategies. DSI value and Cost Drivers can be chosen for individual components.38 = 6. in the Intermediate mode the system can be divided into "components".5 SM TDEV = 2. to find the plan that best suits your needs and resources. which is used in the effort equation: EAF = 1. instead of for the system as a whole.05 = 14.Effort Multipliers are used to calculate the Effort Adjustment Factor. cost.2 * 31.10 = 1.30 * 1. First.43 Effort = EAF * 3.COCOMO can estimate the staffing.50. It considers the effect of more cost drivers.9 = 2.5 / 6.1 people There are two reasons why Intermediate model produces better results than the Basic Model.9 Months Average staffing: 14. Second.

5 Aim: Class diagram using StarUML. Class diagram is not only used for visualizing.e. Practical No. operations. describing and documenting different aspects of a system but also for constructing executable code of the software application.  Forward and reverse engineering.. Description: The class diagram is a static diagram. A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them. The class diagrams are widely used in the modelling of object oriented systems because they are the only UML diagrams which can be mapped directly with object oriented languages.i. It represents the static view of an application.A graphical representation of a static view on declarative static elements. relationships and behavior. A class is the description of a set of objects having similar attributes. So the purpose of the class diagram can be summarized as:  Analysis and design of the static view of an application.  Base for component and deployment diagrams. Class Notation: .  Describe responsibilities of a system.

 The second one is used to show the attributes of the class. The diagram is divided into four parts. .  The top section is used to name the class.  The third section is used to describe the operations performed by the class.  The fourth section is optional to show any additional components.UML class is represented by the diagram shown below.

Practical No. 6 : Use Case diagram using StarUML .

 Show the interacting among the requirements are actors. They model the dynamic aspects of the system. The System is something that performs a function.1.  Identify external and internal factors influencing the system.2. Use case: Use case is a particular activity a user can do on the system. Use Case diagrams show the various activities the users can perform on the system. In UML there are five diagrams available to model dynamic nature and use case diagram is one of them. Relationship: . The purposes of use case diagrams can be as follows:  Used to gather requirements of a system. It provides a user’s perspective of the system. 3. Use case Diagram To model a system the most important aspect is to capture the dynamic behaviour.  Used to get an outside view of a system.Aim: To Analyse the below text and then draw a use case diagram using an UML modelling tool such as StarUML. Actor: An actor is a user of the system playing a particular role.

The list is visible to the user.Then admin login in to the page and add items selected by the customer to the purchase list. Relationships are simply illustrated with a line connecting actors to use cases. In this use case diagram very first customer login to the page. .. After that customer gets items lists with the select item or purchase item option.

Activity is a particular operation of the system. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. The actions coordinated by activity models can be initiated because other actions finish executing. because objects and data become available. Activity diagram is another important diagram in UML to describe dynamic aspects of the system. Activity diagram is UML behavior diagram which shows flow of control or object flow with emphasis on the sequence and conditions of the flow. Activity diagrams are not only used for visualizing dynamic nature of a system but they are also used to construct the executable system by using forward and reverse engineering techniques. Activity diagram is basically a flow chart to represent the flow from one activity to another activity. or because some events external to the flow occur. 7 : Acitvity description for the project Activity Diagram for the prepared Usecase Modelling Aim : Derive an activity diagram from the narrative text by following the steps outlined below.Practical No. Eg: Order System .

. 8 : Work Breakdown Structure for the given Project Aim : Create a Work Breakdown Structure A work breakdown structure (WBS) is a key project deliverable that organizes the team's work into manageable sections. These sub-deliverables are further decomposed until a single person can be assigned.Practical No. The Project Management Body of Knowledge (PMBOK) defines the work breakdown structure as a "deliverable oriented hierarchical decomposition of the work to be executed by the project team. The project team creates the project work breakdown structure by identifying the major functional deliverables and subdividing those deliverables into smaller systems and sub-deliverables. as each level of the work breakdown structure provides further definition and detail." The work breakdown structure visually defines the scope into manageable chunks that a project team can understand.

specific sections of the work breakdown structure can be tracked to identify project cost performance and identify issues and problem areas in the project organization. the project manager can also identify communication points and formulate a communication plan across the project organization. As the project executes. A project budget can be allocated to the top levels of the work breakdown structure. If a work breakdown structure has a branch that is not well defined then it represents a scope definition risk. . By allocating time and cost estimates to specific sections of the work breakdown structure. These risks should be tracked in a project log and reviewed as the project executes. Project work breakdown structures can also be used to identify potential risks in a given project. The work breakdown structure has a number of benefits in addition to defining and organizing the project work. and department budgets can be quickly calculated based on the each project's work breakdown structure. a project schedule and budget can be quickly developed. By integrating the work breakdown structure with an organizational breakdown structure.

.

Select the arrow shown below for inserting new task. .Solution: Step 1: Launch WBS chart pro.

.

Step 3: Continue to add the tasks.Step 2: Double click on the task shown above and give the name for the task. Critical view of above WBS. . We can also add subtasks for a given task.

.

Planning view of above WBS. .