Week 12 - Project Planning Handout

**Week\#12 - Project Planning** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - Project planning...

**Week\#12 - Project Planning** +-----------------------------------------------------------------------+ | **Topics** | +=======================================================================+ | - Project planning | | | | - Pricing for software and plan-driven development | | | | - Planning in Agile | | | | - Estimation strategies | | | | - Cost modeling with COCOMO | +-----------------------------------------------------------------------+ **Project planning** Project planning is dividing the task into manageable pieces and assigning them to team members. It also involves foreseeing potential issues and creating ad hoc solutions. The project plan, which is developed at the beginning of a project, is used to inform the project team and clients of how the work will be done and to track project progress. **Planning stages** When you are submitting a proposal for a contract to create or deliver a software system. You must decide who will work on the project, how it will be divided into phases, how resources will be distributed among your firm, etc. during the project launch phase. Throughout the course of the project, you will occasionally need to adjust your strategy in light of new knowledge and experience that you have obtained by observing how the job is going. **Proposal planning** Even with simply general software requirements, planning could be important. Planning in this stage aims to give clients information that will be used to determine the system\'s price. In order to price a project, an estimate of the software\'s development costs must be made, taking into consideration expenditures for employees, hardware, software, etc. **Project startup planning** You currently have a better understanding of the system needs but no knowledge of design or implementation. Make a detailed strategy that will allow decision-makers to decide on the project\'s budget and staffing. The allocation of project resources is based on this plan. The project monitoring procedures should also be specified in the beginning plan. Agile development still requires a beginning strategy to assign resources to the project. **Development planning** As the project moves forward and you get more knowledge of the program and its evolution, the project plan should be periodically modified. The project timeline, budget, and risks must all be updated on a regular basis. **Software pricing** For the purpose of calculating the developer\'s expected costs, estimates are made. You factor in the price of the hardware, software, travel, instruction, and labour. The price that the consumer is paying does not directly correlate with the cost of development. The price charged is influenced by broader organizational, economic, political, and business issues. **Influencing variables for software price** ---------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ **Variable** **Description** Price prediction uncertainty A corporation may raise its pricing by a contingency over and above its normal profit if it is uncertain about its cost estimate. Contract conditions The developer may be allowed to use the client\'s source code in other projects if the client agrees to relinquish ownership of it. If the buyer receives the program source code, the price might be lower. Financial stability Developers with financial difficulties could lower their asking price to secure work. Instead of going out of business, it is preferable to generate a smaller profit than usual or to break even. In challenging economic circumstances, cash flow takes precedence above profit. Volatility of requirements A business may reduce its pricing to secure a contract if the requirements are anticipated to change. Expensive fees could be imposed for changes to the requirements after the contract has been approved. Market potential A software development company may offer low prices in order to break into a new market. Accepting a tiny profit on one project can enable the business to make more money later on. The knowledge acquired can also aid in the creation of new products. **Pricing strategies** - **Underpricing**: In order to win a contract that enables them to keep its employees on board for potential future prospects, a business may underprice a system. A business might underprice a system in order to enter a new market. - **Increased pricing**: When a buyer requests a fixed-price contract, the price may be raised by the seller to account for unforeseen risks. **Pricing to win** - The price of the software is determined by the buyer\'s perceived willingness to pay, according to the software creator. - If this is less than the expenses of development, the program functionality may be adjusted in order to provide room for additional capability in a future release. - As the requirements alter, additional costs might be introduced, and they might be priced higher to make up for the initial price\'s shortfall. **Plan-driven development** Plan-driven or plan-based development, a method of software engineering, entails thorough planning for the development procedure. Plan-driven development, which is based on engineering project management approaches, is considered to be the \"conventional\" approach to managing major software development projects. A project plan lists the work that has to be done, along with who will do it, when it will be done, and the work outcomes. Managers utilize the plan to aid in project decision-making and as a way to monitor progress. **Plan-driven development\'s benefits and drawbacks** - The benefits of a plan-driven approach include the ability to closely consider organizational issues (staff availability, other projects, etc.) early in the planning process and the discovery of potential issues and dependencies before the project begins rather than after it has already begun. - The primary criticism of plan-driven development is that it requires frequent revisions since the context in which software is to be built and used changes. **Project plans** A project plan includes the resources available to the project, the breakdown of the work, and a timeline for completing the work in a plan-driven development project. - Project Organization - Hardware and Software Requirements - Risk Analysis - Project Organization - Project timeline - Breakdown of the work - Mechanisms for monitoring and reporting **Project plan clarifications** ----------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- **Plan** **Description** Plan for configuration management Explains the structures and processes that will be used for configuration management. Plan of deployment Describes how the software will be installed in the customer\'s environment, together with any necessary accompanying hardware. This should incorporate a strategy for transferring data from current systems. Plan for maintenance Calculates the cost, time, and effort of maintenance. Quality plan Outlines the standards and practices for quality that will be applied to a project. **The process of planning** Iterative project planning begins with the creation of an initial project plan during the project launch phase. Plans will inevitably alter. - Project plans alter as a result of shifting corporate objectives. Any initiatives that are affected by shifting corporate objectives may need to be rescheduled. - You should frequently adjust the plan to account for requirements, schedule, and risk changes as additional details about the system and the project team come to light throughout the course of the project. Figure 12.1. The process of project planning **Conceptions for planning** - When designing a project plan, you should use realistic rather than optimistic assumptions. - Every project encounters issues of some description, and these cause project delays. - This means that your initial planning and assumptions should cater to unforeseen issues. - In order to prevent a significant disruption of your delivery schedule in the event that something goes wrong, you should incorporate contingency in your strategy. **Risk reduction** - You must start risk mitigation steps if there are substantial issues with the development work that are expected to cause considerable delays. This will lower the likelihood that the project will fail. - In addition to these steps, the project needs to be re-planned. - Renegotiating the project\'s restrictions and deliverables with the client may be necessary for this. Additionally, a new timeline for when the job should be finished must be devised and approved by the client. **Project scheduling** The process of deciding how the work in a project will be done is called project scheduling. The main atcivity will be divided into individual tasks and when and how these tasks will be carried out. You make an estimate of the effort required, the amount of time needed on the calendar, and the people who will work on the identified activities. Each task\'s resource requirements, including the server\'s disk space needs, the time needed on specialist hardware like a simulator, and the travel expenses, must also be estimated. - **Activities for scheduling projects** - Break the project up into tasks and determine the resources and time needed to fulfill each task. - Concurrently arrange tasks to best utilize the personnel. - Reduce task dependencies as much as possible to prevent delays brought on by one job waiting for another to finish. - Reliant on the project manager\'s experience and judgment.  Figure 12.2. The process of project scheduling - **Scheduling issues** - It is challenging to predict how complex a problem will be and how much it will cost to build a solution. - The quantity of workers on a task does not affect productivity. - Due to communication costs, expanding a project that is already behind schedule makes it take longer. - Unexpected events always occur. Always account for uncertainty when planning. - **Arrange the presentation** - **On a calendar**: The most typical visual representation of a project timetable is a bar chart. They display the schedule as. - **Networks of activity:** Reveal task dependencies. - **The project\'s activities** - A deadline by which the activity must be finished. - An effort estimate that indicates the number of person-days or person-months needed to accomplish the job. - A stated end-point, such as the completion of all tests successfully. - **Deliverables and milestones** Figure 12.3. Durations, tasks and dependencies  Figure 12.4. The project Gantt chart Figure 12.5. Chart for staffing allocation **Planning in Agile** Software is produced iteratively using agile methodologies, which give small, incremental updates to clients. Contrary to plan-driven techniques, these increments\' functionality is decided while they are being developed. The choice of what to include in each increment is based on both progress and the priorities of the client. It makes sense to create a flexible plan that can adapt to these changes because the customer\'s priorities and needs fluctuate. - **Iterative planning phases** - Release planning, which considers features that should be incorporated in a system release over a period of several months. - Iteration planning, which has a shorter time horizon and concentrates on planning the following system increase. The team normally spends 2-4 weeks working on this. - **Methods for agile planning** - **Scrum planning**: It is based on keeping track of a project\'s backlog of tasks and conducting daily reviews of problems and progress - **The strategy game**: It was created as a component of Extreme Programming (XP). reliant on user stories as a gauge of project progress - **Story-based planning** - The planning game is built on user tales that represent the system\'s necessary functionality. - After reading and debating the stories, the project team ranked them according to how long they believed it would take to implement each one. - Stories are given \"effort points\" based on their size and degree of implementation difficulty. Calculated daily effort points are used to determine the team\'s \"velocity.\" This makes it possible to calculate the total amount of work required to construct the system.  Figure 12.6. The strategy game - **Planning for releases and iterations** - Release planning includes choosing and enhancing the tales that will reflect the features to be implemented in a system release as well as figuring out the sequence in which the stories should be implemented. - The number of stories chosen for implementation in each iteration reflects the length of time required to complete an iteration (often 2 or 3 weeks). - The selection of tales is influenced by the team\'s velocity so that they can be completed within an iteration. - **Assignment of tasks** The developers divide tales into development tasks during the task planning phase. - A development task ought to take between 4 and 16 hours. - There is a list of every action item that needs to be taken in order to accomplish every story in that iteration. - Then, each developer registers separately for the tasks they will complete. - The team as a whole receives a summary of the tasks to be done during an iteration. - Developers are likely to be motivated to complete the assignment since they feel ownership over it. - **Software distribution** - **Applying agile planning** **Estimation strategies** Estimates of software work and cost must be made by organizations. There are two different methods that can be utilized to accomplish this:- - **Techniques based on experience**: The manager\'s knowledge of previous projects and the application domain is used to forecast future effort requirements. In essence, the manager produces a well-informed assessment of what the expected effort requirements are. - **Algorithmic cost modeling**: In this method, the project effort is calculated using a formula based on estimates of the product\'s features, such size, and the process\'s characteristics, like the expertise of the people engaged. - **Techniques based on experience** **Problem with techniques based on experience** - The problem with experience-based methodologies is that there may not be many similarities between new software projects and older projects. - A project will frequently employ foreign approaches like web services, application system configuration, or HTML5 because the field of software development is evolving so swiftly. - It may be difficult to estimate the effort necessary if you haven\'t used these procedures, which will make it more challenging to get precise cost and schedule estimates. - **Algorithmic cost modeling** Effort = *X* ´ Size^*Y*^ ´ *Z* **COCOMO Model** The model provides a software cost estimate in terms of magnitude. The article examines three categories of software projects: - **Organic Mode Projects**: Small teams work on organic mode projects in comfortable settings with minimal communication overhead. - **Semi-detached Mode Projects**: Projects in the semi-detached mode are ones with a mix of experienced and inexperienced workers. - **Embedded Mode Projects**: Complex hardware and software systems are developed in embedded mode projects. Due to the fact that most projects are unique, experience level is minimal. Effort = *X* (*K*) *^Y^* Where *K* is thousands of delivered source instructions **Organic Mode**: *P* = 2.4 (*K*) ^1.05^\ **Semi-detached Mode**: *P* = 3(*K*)^1.12^\ **Embedded Mode**: *P* = 3.6(*K*)^1.20^\ where *P* is person months **Organic Mode**: *T* = 2.5 (*P*) ^0.38^\ **Semi-detached Mode**: *T* = 2.5 (*P*) ^0.35^\ **Embedded Mode**: *T* = 2.5 (*P*) ^0.32^\ where *T* is the period of development As a relatively small and straightforward software project, we will adhere to the Organic BASIC COCOMO Model. With regard to the Organic Basic COCOMO model, an estimated 8000 lines of code make up the LOC. KLOC therefore equals 8. BASIC COCOMO Model calculates the person months (*P*) as :- - *P* = 2.4 \* (8) ^1.05^ = 18.3 - \~ **18 person-month** The period of development is calculated as:- - *T* = 2.5 \* (18) ^0.38^ = 6.46 - \~ **6 months** The project\'s personnel requirements (*N*) are calculated as-: - N = *P* / *T* = 18/6 = **3 persons** - **Cost modeling with COCOMO** Different techniques to software creation, reuse, etc. are considered by COCOMO 2. - **COCOMO 2 models** - Application composition model: Used for building software from pre-existing components. - Early design prototype: Used when design has not yet begun but requirements are available. - Reuse the model: Used to calculate the integration effort of reusable components. - A model of post-architecture: When further details about the system are available and the system architecture has been designed. **Summary** - A system\'s price is not just determined by the expected costs of its development and the profit the development business has to make. Organizational factors could result in a price increase to offset an increase in risk or a price decrease to obtain a competitive edge. - Software is frequently priced to win a contract, and then the system\'s functionality is changed to match the predicted cost. - Plan-driven development centers on a detailed project plan that lists all of the project\'s tasks, the effort that will be put forth, the timing of those activities, and who will be in charge of each one. - Various graphical representations of the project plan are created as part of the scheduling process. The most popular schedule representations are bar charts, which display activity duration and staffing timelines. - A project milestone is an expected result of a task or series of tasks. At each milestone, management should get a formal report on the status of the project. A deliverable is a piece of work that is given to the project\'s client. - The entire team participates in project planning through the agile planning game. When issues arise, the plan is altered so that software functionality is decreased rather than postponing the delivery of an increment. - Software estimation methods can be algorithmic or experience-based, with managers determining the amount of work necessary based on other projected project characteristics. - The COCOMO 2 costing model is an advanced algorithmic cost model that creates cost estimates by taking into consideration project, product, hardware, and employee factors.