comp3521 Ch23

Project Planning Overview

• Project planning requires dividing work, assigning tasks, anticipating problems, and preparing solutions.
• A project plan communicates work processes to the team and customers and gauges project progress.

Planning Stages

• Project bidding requires planning to create a software system.
• The project startup phase involves deciding which team members will work the project, how the project will be separated into logical units, and how resources will be allocated.
• Plans are modified periodically utilizing gained experience and progress monitoring.

Proposal Planning

• Planning is sometimes required when only general software specifications are available.
• Planning aims to inform pricing for customers.
• Project pricing considers staff, hardware, and software expenses.

Project Startup Planning

• More detailed system parameters are required, though not design or implementation details.
• The detailed plan allows for decisions on budget and human resources.
• Resource allocation is based on the plan.
• Project monitoring mechanisms should be part of the launch plan.
• Startup plans are also required for agile development to facilitate the allocation of project resources.

Development Planning

• When project develops, the project plan is regularly updated.
• Project schedule, costs, and risks are regularly reviewed.

Software Pricing

• Estimates determine the cost for a software system to the developer.
• Developers should factor in expenses for hardware, software, travel, personnel training and time.
• There is no direct correlation between the cost of development and the price for the consumer.
• Broader organizational, economic, political, and business factors affect the price charged.

Influences on Software Pricing

• Allowing developers to retain source code ownership for use in other projects may lower costs.
• Cost estimate uncertainty can lead to higher prices to cover contingency.
• Developers experiencing financial struggles may accept lower margins to secure contracts, because cash flow becomes more important than profit during economic downturns.
• Accepting a smaller profit on an initial project to gain entry into a new market may potentially result in bigger profit increases in the future.
• High prices may be imposed for requirement changes after a contract is signed in cases of requirements volatility where prices may have been cut for the win.

Pricing Strategies

• Underpricing is used to allow a company to retain staff for future project(s).
• Underpricing can also provide market access to an organization.
• Sellers may increase the price for fixed-price contracts to buffer against unexpected risk.

Pricing Tactics

• Charging software is priced based on what developers think buyers will accept.
• Software features may be reduced, if the development costs are greater, but there is a clear path to including features in a future release.
• If requirements shift, extra costs may be introduced and set at an increased level to offset the price reduction in the project's original price.

Plan-Driven Development

• Plan-driven development is an approach to software engineering where the development process is planned in detail.
• Plan-driven development uses conventional methods to manage very large-scale software development initiatives.
• The project strategy, personnel, timelines, and deliverables are all documented in a project plan.
• Plans assist managers in making judgements and monitoring progress.

Plan-Driven: Pros and Cons

• Planning permits early consideration of organizational issues such as staff allocation or other projects. Potential issues and dependencies are discovered prior to project implementation, which is an argument in favor of plan-driven method.
• Environmental factors change which necessitate revisions to original decisions which is an argument against plan-driven method.

Project Plans

• A structured strategy details available resources, tasks, and timelines in a plan-driven development project.
• The plan contains introduction, project organization, risk assessment, hardware and software requirements, work distribution, schedule and mechanism to monitor and report.

Project Plan Supplements

• Configuration management plan: Configuration management procedures, and framework to be utilized.
• Deployment plan: How software and associated hardware is deployed in the customer's environment, covers data migration strategy.
• Maintenance plan: The predicted maintenance requirements, costs, and labor.
• Quality plan: The quality procedures and standards to be used.
• Validation plan: Methodologies, tools, and timelines used in the system validation.

The Planning Process

• Project plans are developed iteratively starting from the initial project.
• As you find more about the framework and the project team, the plan must be updated to take into account revisions to the requirements, timelines, and risks.
• Changing business targets can significantly impact all projects and require replanning.

Planning Assumptions

• When drafting a project strategy, realistic assumptions should be preferred over optimistic projections.
• Project delays will occur as a result of challenges that arise during a venture.
• Initial assumptions and scheduling should make provision for surprises.
• Ensure you have a strategy in place to limit any major disruptions to delivery timelines in case of disruption.

Risk Mitigation

• When significant development problems that are likely to cause substantial delays occur, risk mitigation actions must be initiated to minimize the risk of project failure.
• It is critical to rearrange the project in a way that supports these initiatives and is completed.
• To implement this, it may be required to redefine project limitations and deliverables to the end customer, and then construct and execute on a revised delivery schedule.

Project Scheduling

• The project scheduling process defines how work in a project will be divided into distinct activities, their timing, and how they will be carried out.
• Estimate calendar time to complete each task, effort required and who is working on the tasks.
• Resources, such as disc space, specialized hardware time, a simulator, and the travel budget are critical to estimate to complete each item.

Project Scheduling Activities

• Each line item is estimated for time and the requisite resources.
• Tasks are arranged concurrently to maximize staff use.
• Task dependencies are kept to a minimum to avoid delays.
• Project managers need experience and intuition.

Project Scheduling Process

• Identify Activities and Software requirements then design information.
• Dependencies and resources must be identified and estimated.
• Allocate people to tasks then create charts describing the schedule.

Scheduling Problems

• It is difficult to determine the cost of resolving issues since problem difficulty is hard to measure.
• The idea that productivity rises in proportion with the workforce population is not true.
• Increased communication overhead causes late projects to be delayed even more by the assignment of more staff.
• There should always be a contingency plan to prepare for the unexpected.

Schedule Presentation

• Project schedules typically utilize graphical depictions.
• These explain how a initiative functions across activities.
• Tasks that need to be done should take at least one week or two.
• Representations in calendars.

Calendar-Based

• The use of Bar charts is most prevalent in these types of project schedules. They show activities and resources against time.

Activity Networks

• Task dependencies are displayed.

Project Activities

• The foundation of each project is its defined tasks.
• Each activity requires duration, resources, and a deadline.
• Each requires a clear end-point and defined measurement including a report of findings.

Milestones and Deliverables

• Schedule points for reviewing progress such as system handover for testing.
• Deliverables are work given to the customer (requirements document for project).

Tasks, Durations, and Dependencies

• Task T1 has a 10-day duration and requires 15 person-days of effort.
• Task T2 has a 15-day duration and needs 8 person-days of effort.
• Task T3 has a 15-day duration, 20 person-days of effort and relies on milestone M1 within Task T1.
• Task T4 needs 5 person-days of effort and spans for 10 days.
• Task T5 spans 10 days requesting needs 5 person-days of effort relying on milestone M3 comprising Task T2 and Task T4.
• Task T6 has a 5-day duration needing 10 person-days of effort relying on milestone M4 comprising Task T1 and Task T2.
• Task T7 spans 20 days requiring 25 person-days of effort relying on milestone M1 within Task T1.
• Task T8 duration is 25 days, 75 person-days of effort and relies on milestone M2 within Task T4.
• Task T9 has 10 person-days of effort, spans for 15 days and depends on milestone M5 containing Task T3 and Task T6.
• Task T10 lasts 15 days needed 20 person-days of effort needing comprising Task T7 and Task T8 at milestone M6.
• To complete Task T11 has 10 person-days of effort lasting 10 days relying on Task T9 and its comprising milestone M7.
• Task T12 spans 10 days, needs 20 person-days needing comprising Task T10 and Task T11 under milestone M8.

Agile Planning

• Agile methods are iterative approaches for software development where deliverables are delivered to the clients in stages.
• The characteristics of these increments, unlike planned projects, are determined by the development work in progress.
• What goes into the increment is based on development progress and the customer demands.
• To maintain alignment with shifting customer needs and demands, agile plans provide a flexible strategy,

Agile Planning Stages

• Release planning seeks months ahead for including the intended features in a system release.
• The focus of Iteration planning is on developing the following phase of execution with 2-4 weeks for the entire workstream.

Approaches to Agile Planning

• Scrum focuses on backlog management with ongoing status updates and issue logs in relation to progress and problems.
• The planning game involves user stories to measure project progress.

Story-Based Planning

• The cornerstone of the planning game is user stories that translate to core system attributes.
• The project staff analyzes and evaluates the articles, classifying them by their expected execution effort.
• Assigning effort to tasks and how difficult tasks are.
• Daily measures of completed user items estimates the velocity of the project.
• Total required effort for system rollout can be calculated.

Release and Iteration Planning

• Selecting and improving the stories for integration in a framework is part of release planning and defining the arrangement they will go in.
• The number of stories used in each phase reflects 2 or 3 weeks to deliver said phase.
• If time is of the essence, the team's velocity then guides story selection.

Task Allocation

• Tasks are delegated into defined sprints in development.
• Development tasks last 4-16 hours.
• All responsibilities for the iterations are then stated.
• Staff are then assigned to tasks.

Allocation Benefits

• Every member has insight into every part of the current task as it is underway.
• Members have a sense of ownership for their assigned responsibilities, which improves their motivation.

Software Delivery

• Each software increment is released at the end of a project iteration.
• Scope is reduced, where features should be added in an increment yet, cannot be finished over the expected time period.
• The delivery schedule is inflexible and never adjusted.

Agile Planning- Challenges

• Success centers on customer involvement.
• Due to other priorities or the planning game's unavailability, arranging scheduling can be challenging.
• Furthermore, some customers may be unfamiliar with conventional project plans and may struggle to use agile plan techniques.

Agile planning- Applicability

• Where the team is small, and collaborative, agile planning functions well.
• When squads are geographically separated and/or change frequently, collaboration is practically impossible.

Estimation Techinques

• Organizations should evaluate the software costs required to develop. They should then measure, and estimate project costs and team skills.
• There are two methods for completing this: experience-based and algorithmic estimating.

Experience-Based

• These methods evaluate the past experiences from comparable projects.

Algorithmic cost modeling

• Estimates are calculated using product traits through established processes based on team skills.

Estimate Uncertainty

• Estimates become more accurate through feasibility, requirements, design, and code until the fully delivered project.

Experience-Based Approaches

• Evaluations depend on past initiatives and tasks to achieve current success.
• Distinguish deliverables in product functions and software features that may need to be developed.
• You should document these inputs to estimate the total effort.
• It is advantageous to have multiple staff to explain the estimate.

Problem: Experience-Based Approaches

• Many prior initiatives are incomparable to recent projects.
• Software development changes rapidly and projects use web services including new language and code.
• Past work history may not enable someone to complete an evaluation.

Algorithmic Cost Modeling

• Cost is calculated by a mathematical function and estimated by the project manager.
• Effort = A ´ SizeB ´ M
• A is the cost to operate from the team, B displays work for large projects and M is the measurement.
• The most used estimation tool is code size.
• Most estimates are the same, but A, B, and M differ from each other.

Estimation Accuracy

• When the software has been completed its size may be accurate.
• Many measures influence its size : systems used, programming tools, and distribution of the software.
• Estimates of B and M are different among estimators.

Algiorithmic Models Effectiveness

• Estimate effort is systematic using algorithmic cost models, however they can be difficult.
• Estimating values create uncertainty.
• It can be more challenging to apply to small operations.

COCOMO- Cost Modeling

• The empirical framework is based on project experience.
• It is well documented not tied to any vendor.
• Developed in 1981, and new versions such as COCOMO-81 through iterative 2nd versions.
• The model is designed to incorporate different practices.

COCOMO 2 Models

• It has a variety of sub-models.
• Models consist of application composition, early design, reuse, or post-architecture implementation.

COCOMO 2 Submodels

• Application composition model for new systems developed with dynamic languages and database programming.
• The Initial effort estimation uses system and design requirements under an Early design model.
• Reuse model estimates the effort to integrate reusable parts or automatically generate code.
• Post-architecture models estimate the development effort based on system design and setup.

Application Composition

• Used for objects and prototyping.
• Measures standards of developer application productivity in points per month.
• Formula is: PM = ( NAP ´ (1 - %reuse/100 ) ) / PROD where PM is effort, NAP is app points, and PROD is measure.

Multipliers

• The developers need non-functional standards with tools.
• In doing this, the system will factor in product quality and complexity, potential re-use, platform , personnel capabilities, planning, or resources.

Reuse Model

• It takes pre-existing black box code , and adapts it so there is new coding.
• Two types include.
• Code which has no adjustments (black-box) with an effort estimate.
• Or adjusted coding needing code that is newly constructed (white box model).

Reuse Models-Estimate 1

• If code should be constructed: PM = (ASLOC * AT/100)/ATPROD - ASLOC calculates code count - AT is percentage of code automatically generated.
• ATPROD is the measurement used to determine engineer productivity.

Reuse Models-Estimate 2

• When the code has been extracted for knowledge and support: ESLOC = ASLOC * (1-AT/100) * AAM where ASLOC calculates code AT is percentage of code constructed and AAM is the adaptation adjustment multiplier which calculates system change to support cost.

Post-Architecture Level

• With 17 multipliers uses the same formula as the early model.
• The codes size measures numbers to be developed, estimated to be equivalent to new code or adapted code.

The Exponent Term

• There are likely 5 scaling factors.
• As such, a team has created a new domain, with limited schedule, minimal planning, and CMM level 2.
• Some of these factors Precedent,Flexibility, or Risk/A and even Staff may factor at 1.17.

Multipliers

• Attributes involve software development and required coding with associated restraints.
  • Personnel Attributes, such as staff skills are accounted for at all stages.

Estimating the Effect of Cost Drivers

• Exponent numbers may range at different values
• DSI may be measured upward of 128,000.
• There is a set of drivers to manage including reliability/complexity.

COCOMO - Staff Drivers

• Reliability measures very low Multiplier estimates (0.75).
• Low complexity measures (.75), while the memory shows nullified effects. (1)
• A high use of devices can show an estimate of (.72) while the schedule remains normal (1).

Project Staff and Duration

• Managers measure the time to staff a project.
• Calendar time can be calculated - PM= (AP)(0.33+ 0.2). The time necessary is free of who operates.

Staffing Estimates

• An efficient project is measured by the needed development duration.
• It is very likely that many may quickly be in line to slide and staff could cause issues with projects.

Key Points Summary

• Pricing depends on development estimates which influence the price by profit gain or competition.
• There, too, is adjusting of software to meet needs.
• Planning aims to achieve activities that are organized, and where people are scheduled, and who will manage.
• Graphical representations can be constructed on parts used at all stages.
• Milestones are critical to presenting management for next action to be delivered to customers.
• Incremental agile planning includes the team while there are problems the solution to delivery is reduced to functions of the plan.
• Evaluating skill against parameters achieves estimates for costs models as well.
• COCOMO II is used for hardware and personnel as an algorithmic estimation.