Developing Work Breakdown Structure And Time-Phased Budget For Software Development Project

Creating a Work Breakdown Structure (WBS)

The WBS of the “Work Breakdown Structure” would consist of each and every task that would be accomplished accordingly. The “Work Breakdown Structure” would be developed in a 3-4 level WBS format and would be developed in “Indented format” as well (Budczies et.al, 2012). The WBS that has been developed below is a clear projection of the array of tasks that would be essential for accomplishing the entire task in an effective manner.

Save Time On Research and Writing
Hire a Pro to Write You a 100% Plagiarism-Free Paper.
Get My Paper

                     

This would be a typical Gantt chart consisting of activity estimation, activity duration, dependencies among each activity (Osentoski et.al, 2011, May). This particular step consists of developing the Gantt chart including the tasks and activities undertaken for accomplishing each of the project deliverables in consideration to the time schedule along with the amount of money allotted for each of the task. However in order for developing the Gantt chart, it is necessary to develop the project schedule and include crucial information describing the individual task along with the time frame they are to be achieved within.

Task Name

Duration

Save Time On Research and Writing
Hire a Pro to Write You a 100% Plagiarism-Free Paper.
Get My Paper

Start Date

Finish Date

Percentage Completed

Precedes

Resource Name

Application Development Timetable

125  Days

10-5-17

10-9-17

0%

Scope

3-5 Days

10-5-17

13-5-17

0%

Ascertaining Project Scope

4 Hrs

13-5-17

13-5-17

0%

Management

Securing Sponsorship

1 Day

13-5-17

14-5-17

0%

2

Management

Defining Primary Resources

1 Day

14-5-17

15-5-17

0%

3

Project Manager

Securing Fundamental Resources

1 Day

15-5-17

16-5-17

0%

4

Project Manager

Scope Complete

0 Day

16-5-17

16-5-17

0%

5

Analyzing Software Obligations

28 Days

16-5-17

13-6-17

0%

Carrying Out Need Analysis

10 Days

13-6-17

23-6-17

0%

6

Analyst

Sketching Primary Software Application

3 Days

23-6-17

26-5-17

0%

8

Analyst

Arranging Primary Budget

2 Days

26-5-17

28-5-17

0%

9

Project Manager

Assessing Software Specification Budget

4 Hrs

28-5-17

28-5-17

0%

10

Project Analyst And Manager

Incorporating Feedback On Software Specification

1 Day

28-5-17

29-5-17

0%

11

Analyst

Developing Delivery Timeline

1 Day

29-5-17

30-5-17

0%

12

Project Manager

Gathering Approval For Advancing

4 Hrs

30-5-17

30-5-17

0%

13

Management And Project Manager

Securing Required Resources

10 Days

30-5-17

9-6-17

0%

14

Project Manager

Analysis Complete

0 Days

9-6-17

9-6-17

0%

15

Design

23 Days

9-6-17

2-7-17

0%

Assessing Principal Software Specification

2 Days

2-7-17

4-7-17

0%

16

Analyst

Mounting Functional Specification

21 Days

4-7-17

25-7-17

0%

Analyst

Use Case 1

2 Days

25-7-17

27-7-17

0%

18

Analyst

Use Case 2

3 Days

27-7-17

30-7-17

0%

20

Analyst

Use Case 3

1 Day

30-7-17

31-7-17

0%

21

Analyst

Use Case 4

1 Day

31-7-17

1-8-17

0%

22

Analyst

Use Case 5

1 Day

1-8-17

2-8-17

0%

23

Analyst

Interface Space

8 Days

2-8-17

10-8-17

0%

Interface 1

1 Day

10-8-17

11-8-17

0%

24

Analyst

Interface 2

1 Day

11-8-17

12-8-17

0%

26

Analyst

                         

The time-phased budget would be developed in consideration to the “bottom-up estimating” (Singhal & Shukla, 2012). The budget would typically be based over the resource allocation to each one of the activities. The budget would involve various activities in consideration to the project and activities. This can be described as the calculation of the amount of money that has been distributed among various tasks mentioned in the WBS and the Gantt chart displayed above. The budget for this project would reflect a typical budget that usually is used while developing any project (Subashini & Kavitha, 2011). The fundamental aspects of this particular time phased budget would include the below mentioned aspects:

The amount that has been allotted for carrying out this entire project was approximately 50,000 AUD (Australian Dollar) that is accountable for carrying out each and every task that has been planned under this project.

Training cost of employees 5000 AUD

Training the administrative workers 1000 AUD

Sum of training cost 6000 AUD

Equipment along with material costs including servers and the backup severs did cost around 6000, 5000 and 7000

Labor costs

Average salary 100 AUD

Programmer 5000 AUD

Database manager 3000 AUD

Project analyst 5000 AUD

Operation analyst 5000 AUD

Developing a Gantt Chart

Interface manager 2900 AUD

Network analyst 5000 AUD

Total amount 50,000 AUD

The risk register would entirely be based over the typical and probable risk that might hamper the proceedings of any project (Tipton & Nozaki, 2012).

Risk name

Description

Probability

Schedule risk

Schedule risk refers to the idea of not achieving tasks at the prescribed time schedule, which eventually can hamper the entire pace of the project and might even hamper the final outcome.

Although, project managers are there to monitor the time period factor along with various other aspects as well, ignoring this particular factor would draw major lag in the process. The probability of this particular risk is “Moderate”.

Operational risk

As the name suggests, this particular pattern of risk is associated with operations of the project, which means this type of risk would hamper the entire operation ability of the team. For example: failed systems or threats from external events

High; despite of the fact that the project manager would always be there to ensure the flawlessness of the entire operation, such risks are beyond one’s capability

Technical risks

Technical faults often hamper the entire process causing severe consequences

High

Budget risks

As the schedule increases, it affects the budget as well, some factors are beyond organizational control, which can affect the proceedings

High

The quality management plan would be based over how important it is to maintain the quality of the any project that is being undertaken. Software development procedure without the management plan for maintaining quality is not possible (Weinberger et.al, 2011, September). The sole purpose of this particular agenda is to define the quality standard along with the pathway for maintaining the quality. The team members including administrative to developers, each one of the workers are bound to comply with the rules, regulations and the standards of this particular plan. The fundamental of this plan revolves around certain perspectives and purposes, including:

  • Ensuring quality standard has been adhered
  • Defining the way quality is to be managed
  • Defining quality assurance activities
  • Implementing acceptable or reasonable quality standards

This particular document would consist of a checklist regarding if every task and activity has been accomplished or not. This is a document that every software development project manager has to present upon completion of the entire project. It is one of the most important and obvious roles of the project manager to ensure that each and every task that has been included in the WBS (Work Breakdown Structure) and following documents have been achieved and fulfilled successfully (Winesett, 2012). This particular document can also be referred as the evidence showcasing a successful achievement of the complete project. The closure checklist for this project would certainly follow the fundamental or conventional template and would include the following aspects:

  • Handing over total deliverables
  • Each of the deliverables have been signed off and have also been acknowledged by the client or sponsor
  • The final status of the project is complete
  • Every financial process and the report is complete
  • Assessing the project post complete is also complete
  • Assessing staff presentation  is approved and complete
  • Staff unemployment over the termination of the project
  • Every procedure and the contract have been terminated post completion of the project
  • Every site and their operations initiation are shut down
  • Discarding materials and equipments is finished
  • Making announcement regarding conclusion of the final project
  • Storage upon conclusion of the project

References:

Budczies, J., Klauschen, F., Sinn, B. V., Gy?rffy, B., Schmitt, W. D., Darb-Esfahani, S., & Denkert, C. (2012). Cutoff Finder: a comprehensive and straightforward Web application enabling rapid biomarker cutoff optimization. PloS one, 7(12), e51862.

Charland, A., & Leroux, B. (2011). Mobile application development: web vs. native. Communications of the ACM, 54(5), 49-53.

Corral, L., Sillitti, A., & Succi, G. (2012). Mobile multiplatform development: An experiment for performance analysis. Procedia Computer Science, 10, 736-743.

Espie, C. A., Kyle, S. D., Williams, C., Ong, J. C., Douglas, N. J., Hames, P., & Brown, J. S. (2012). A randomized, placebo-controlled trial of online cognitive behavioral therapy for chronic insomnia disorder delivered via an automated media-rich web application. Sleep, 35(6), 769-781.

Felt, A. P., Greenwood, K., & Wagner, D. (2011, June). The effectiveness of application permissions. In Proceedings of the 2nd USENIX conference on Web application development (pp. 7-7).

Finifter, M., & Wagner, D. (2011, June). Exploring the relationship between Web application development tools and security. In USENIX conference on Web application development.

Han, W., Yang, Z., Di, L., & Mueller, R. (2012). CropScape: A Web service based application for exploring and disseminating US conterminous geospatial cropland data products for decision support. Computers and Electronics in Agriculture, 84, 111-123.

Heitkötter, H., Hanschke, S., & Majchrzak, T. A. (2012, April). Evaluating cross-platform development approaches for mobile applications. In International Conference on Web Information Systems and Technologies (pp. 120-138). Springer Berlin Heidelberg.

Horner, J. (2011). RApache: Web application development with R and Apache.

Osentoski, S., Jay, G., Crick, C., Pitzer, B., DuHadway, C., & Jenkins, O. C. (2011, May). Robots as web services: Reproducible experimentation and application development using rosjs. In Robotics and Automation (ICRA), 2011 IEEE International Conference on (pp. 6078-6083). IEEE.

Singhal, M., & Shukla, A. (2012). Implementation of location based services in Android using GPS and Web services. IJCSI International Journal of Computer Science Issues, 9(1), 237-242.

Subashini, S., & Kavitha, V. (2011). A survey on security issues in service delivery models of cloud computing. Journal of network and computer applications, 34(1), 1-11.

Tipton, H. F., & Nozaki, M. K. (2012). Information Security Management Handbook, Volume 6. Auerbach Publications.

Weinberger, J., Saxena, P., Akhawe, D., Finifter, M., Shin, R., & Song, D. (2011, September). A systematic analysis of XSS sanitization in web application frameworks. In European Symposium on Research in Computer Security (pp. 150-171). Springer Berlin Heidelberg.

Winesett, J. (2012). Web Application development with Yii and PHP. Packt Publishing Ltd.