1 / 14

Task Analysis is Part of Planning

Task Analysis is Part of Planning. Once we have completed our plan on what to deliver and the contents of deliverables (via requirements), we need to: plan out how to accomplish the deliverables. Task Analysis.

brody-thornton
Download Presentation

Task Analysis is Part of Planning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Task Analysisis Part of Planning Once we have completed our plan on what to deliver and the contents of deliverables (via requirements), we need to: plan out how to accomplish the deliverables

  2. Task Analysis • Task analysis is domain dependent– thus you need domain experts to help: (if you want to do well) • build a desk • plant a tree • write computer program • build a road • make a spaghetti dinner • Software project task analysis is no different • you need domain knowledge to do this well • computer science • software engineering • information technology • math/science/arts task analysis:–the definition and sequencing of tasks needed to accomplish the result.

  3. From the Requirements to Work Breakdown Structure (WBS) • We get 2 main sets of information from Requirements: • 1) list of deliverables to the customers • 2) descriptions (functional & non-functional) about those deliverables • The first “high level” task of sequencing the required customer deliverables may seem simple, but --- consider the example list: • code • user guide • support plan • development process document Note: date or schedule requirement is purposely not included, yet WBS: is thelistingand sequencingof the work activities needed to produce the required deliverables. (Note that there may be concurrent activities.)

  4. Assume these external deliverables code user guide product support plan How are these related ? dev. process doc.

  5. A ‘Sample’ Sequence of External Deliverables code dev. process doc product support plan End user guide - Do you all agree ? Discuss - what do you need to decide here. - Also decide if the sequence of deliverables “equal” sequence of activities (tasks) to produce the material

  6. Representing in “Schedule” form Deliverables became Tasks ! Note: added new parameter Resp. month1 month2 month3 Tasks Proc. doc Gw All the same length and no overlap Code Gx User Guide Gy S.Plan Gz

  7. Effort Analysis • Estimation of “Effort” for each deliverable • need to understand the subtasks required to produce the deliverable and any “intermediate deliverables” that may be required. • need to break it (deliverable or task) down more • by sub-components • to the level where : • one person can do the task • skill & productivity of the person can be described • actual task can be described and size estimate has some comparable “past history” or “algorithm” How important are these?

  8. A Deeper Work Breakdown Structure (WBS)of “Developing” Product Support Plan Interview Customer for input Analysis and Develop Outline Develop the whole Support Plan Review with Customer Not O.K. O.K. 1 cycle only Final Review End

  9. Effort Analysis & A Deeper Work Breakdown Structure (WBS)of “Developing” Support Plan Interview Customer for input Analysis and Develop an Outline ** Effort is Based on the assumptions: 1. How much (size of) work is estimated. 2. Productivity of the assigned person ** 2 p-days 1/2 p-day Develop the whole Plan Review with Customer O.K. 1/2 p-day 5 p-days 1/2 p-day ** - Do not forget about wait time - how many people are required ? - what kind of skill & background ? Final Review End 1 p-day

  10. 2 Major “Information/Assumption” Needs forEffort Analysis & Deeper WBS &Schedule • An estimate of the “size” of the work: • pages of document • lines of code • number of people to visit • length of meeting • Productivity of the “individual” assigned • 5 pages a day (for document) • 30 loc/day (for source code) • 2 people/hour (for interview or visits) • 3hrs/meeting (for meetings)

  11. Assuming WBS is Performed for Each Deliverable code develop. Process doc Support plan P-25 days P-7 days End user guide P-10 days P-10 days Assume you agree with the sequence For each of the major deliverables, estimate the required effort in “p-days” via WBS (*** these are person-days ---- want to get to individuals)

  12. Improving on Task “Schedule” Having chosen specific resources Resp. May June July Tasks Proc Qais Overlapping, different length Code Justin User Guide Gabe S.Plan Marshon

  13. Adding Milestones in “Schedule” Resp. May June July Tasks Proc Qais Code Justin User Guide Gabe S.Plan Marshon Minor Minor Major Major (project end)

  14. General flow of WBS to Timeline Schedule Identify the deliverables For each deliverable: identify the tasks for completing the deliverable Sequence the tasks • For each task: • Estimate the productivity • of the assigned resource • for effort analysis • For each task: • Estimate the size • for effort analysis For each task: compute the effort/timeline for that task by dividing sise by productivity After all the timelines for all the tasks for all the deliverables are computed do following step Lay out the timeline for all the ordered tasks needed for each of the deliverables. (task timeline may overlap)

More Related