Project Scheduling and Tracking in Software Engineering.pptx
- 1. Project Scheduling and Tracking
- 2. Software Metrics A software metric is a measure of software characteristics which are measurable or countable. Software metrics are valuable for many reasons, including measuring software performance, planning work items, measuring productivity, and many other uses.Software metrics can be classified into two types as follows: 1. Product Metrics: These are the measures of various characteristics of the software product. The two important software characteristics are: ● Size and complexity of software. ● Quality and reliability of software. These metrics can be computed for different stages of SDLC.
- 3. 2. Process Metrics: These are the measures of various characteristics of the software development process. For example, the efficiency of fault detection. They are used to measure the characteristics of methods, techniques, and tools that are used for developing software. Types of Metrics Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of greater importance to a software developer. For example, Lines of Code (LOC) measure. External metrics: External metrics are the metrics used for measuring properties that are viewed to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc. Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For example, cost per FP where FP stands for Function Point Metric. 3.Project metrics: Project metrics enable a software project manager to (1) assess the status of an ongoing project, (2) track potential risks, (3) uncover problem areas before they go “critical,” (4) adjust work flow or tasks, and (5) evaluate the project team’s ability to control quality of software work products.
- 4. Advantage of Software Metrics ● Comparative study of various design methodology of software systems. ● For analysis, comparison, and critical study of different programming language concerning their characteristics. ● In comparing and evaluating the capabilities and productivity of people involved in software development. ● In the preparation of software quality specifications. ● In the verification of compliance of software systems requirements and specifications. ● In making inference about the effort to be put in the design and development of the software systems. ● In getting an idea about the complexity of the code.
- 5. Disadvantage of Software Metrics ● The application of software metrics is not always easy, and in some cases, it is difficult and costly. ● The verification and justification of software metrics are based on historical/empirical data whose validity is difficult to verify. ● These are useful for managing software products but not for evaluating the performance of the technical staff. ● The definition and derivation of Software metrics are usually based on assuming which are not standardized and may depend upon tools available and working environment. ● Most of the predictive models rely on estimates of certain variables which are often not known precisely.
- 6. Software Project Estimation For any new software project, it is necessary to know how much it will cost to develop and how much development time will it take. These estimates are needed before development is initiated, but how is this done? Several estimation procedures have been developed and are having the following attributes in common. ● Project scope must be established in advanced. ● Software metrics are used as a support from which evaluation is made. ● The project is broken into small PCs which are estimated individually. ● To achieve true cost & schedule estimate, several option arise. ● Delay estimation ● Used symbol decomposition techniques to generate project cost and schedule estimates. ● Acquire one or more automated estimation tools.
- 7. Size Metrics: ● LOC ● FP
- 8. LOC Error Rate = (Number of Errors or Bugs) / (Number of Lines of Code) Defect Density = (Number of Defects) / (Number of Lines of Code) Documentation Density = (Size of Documentation) / (Size of Code) Cost per LOC = Cost of Development / Number of Lines of Code
- 9. Advantages of using LOC: Easy to Measure: LOC can be easily counted using automated tools, making it a convenient metric for software size estimation. Widely Accepted: LOC is a widely understood metric and is commonly used in industry and academia for measuring software size. Direct Correlation with Effort: There is often a direct correlation between the number of lines of code and the effort required to develop and maintain a software system. Disadvantages of using LOC: Language Dependency: LOC can vary significantly depending on the programming language and coding style used, making it less suitable for comparing software across different languages or teams. Doesn't Account for Complexity: LOC does not take into account the complexity of the code or the functionality implemented, leading to inaccuracies in estimating effort and productivity. Subject to Manipulation: Developers may be incentivized to write more lines of code to inflate productivity metrics, leading to poor coding practices and unnecessary complexity.
- 14. The Fi (i 1 to 14) are value adjustment factors (VAF) based on responses to the following questions 1. Does the system require reliable backup and recovery? 2. Are specialized data communications required to transfer information to or from the application? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilized operational environment? 6. Does the system require online data entry? 7. Does the online data entry require the input transaction to be built over multiple screens or operations? 8. Are the ILFs updated online? 9. Are the inputs, outputs, files, or inquiries complex? 10. Is the internal processing complex? 11. Is the code designed to be reusable? 12. Are conversion and installation included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease of use by the user? Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential).
- 15. Compute the function point for the following data: 1. Number of user inputs = 24 2. Number of user outputs = 46 3. Number of inquiries = 8 4. Number of files = 4 5. Number of external interfaces = 2 Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5. Consider Average weighing factor of all Measurement parameter. 6. Effort = 36.9 p-m 7. Technical documents = 265 pages 8. User documents = 122 pages 9. Cost = $7744/ month
- 16. Advantages of using FP: Language Independence: FP is independent of programming languages and implementation details, making it suitable for comparing software systems developed using different technologies. Focuses on User Requirements: FP measures the functionality delivered by the software system, providing a more holistic view of its size and complexity. Considers Complexity: FP takes into account the complexity of functional requirements, providing a more nuanced measure of software size compared to LOC. Disadvantages of using FP: Subjectivity: Assigning weights to functional components and assessing their complexity can be subjective, leading to variability in FP counts among different estimators. Complexity of Measurement: Calculating FP requires detailed analysis of functional requirements, which can be time-consuming and may require domain expertise. Limited Scope: FP focuses primarily on functional requirements and may not capture non-functional aspects such as performance, scalability, and usability, which are important considerations in software development.
- 17. COCOMO Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.COCOMO is one of the most generally used software estimation models in the world. COCOMO predicts the efforts and schedule of a software product based on the size of the software. The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single variable models, using KDLOC as the measure of the size. To determine the initial effort Ei in person-months the equation used is of the type is shown below Ei=a*(KDLOC)b The Cocomo Model is a procedural cost estimate model for software projects and is often used as a process of reliably predicting the various parameters associated with making a project such as size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981 and is based on the study of 63 projects, which makes it one of the best-documented models. The key parameters that define the quality of any software products, which are also an outcome of the Cocomo are primarily Effort and schedule: 1. Effort: Amount of labor that will be required to complete a task. It is measured in person-months units. 2. Schedule: This simply means the amount of time required for the completion of the job, which is, of course, proportional to the effort put in. It is measured in the units of time such as weeks, and months.
- 18. In COCOMO, projects are categorized into three types: 1. Organic 2. Semidetached 3. Embedded 1.Organic: A development project can be treated of the organic type, if the project deals with developing a well-understood application program, the size of the development team is reasonably small, and the team members are experienced in developing similar methods of projects. Examples of this type of projects are simple business systems, simple inventory management systems, and data processing systems. 2. Semidetached: A development project can be treated with semidetached type if the development consists of a mixture of experienced and inexperienced staff. Team members may have finite experience in related systems but may be unfamiliar with some aspects of the order being developed. Example of Semidetached system includes developing a new operating system (OS), a Database Management System (DBMS), and complex inventory management system. 3. Embedded: A development project is treated to be of an embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational method exist. For Example: ATM, Air Traffic control.
- 19. According to Boehm, software cost estimation should be done through three stages: 1. Basic Model 2. Intermediate Model 3. Detailed Model
- 20. 1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters. The basic COCOMO estimation model is given by the following expressions: E = ax (KLOC)b D = c x (Effort)d P = effort/time Where, E is effort applied in person-months. D is development time in months. P is the total no. of persons required to accomplish the project. The constant values a,b,c, and d for the Basic Model for the different categories of the system
- 22. Strengths of COCOMO: ● Structured Approach: COCOMO provides a systematic and structured approach to software cost estimation, making it easier for project managers to understand and apply. ● Flexible: COCOMO can be tailored to different project sizes and complexities by using different versions of the model (Basic, Intermediate, and Detailed). ● Historical Data: COCOMO incorporates historical data from previous projects, which can improve the accuracy of estimates by leveraging past experiences. ● Comprehensive: COCOMO II takes into account a wide range of factors that can influence software development effort, resulting in more accurate estimates.
- 23. Limitations of COCOMO: ● Dependency on Size Metrics: COCOMO heavily relies on size metrics such as lines of code (LOC), which may not always be accurate predictors of software development effort, especially in modern development paradigms like Agile or when using different programming languages with varying levels of expressiveness. ● Complexity: COCOMO II, while comprehensive, can be complex to apply and requires detailed input data for accurate estimation, which may not always be available or easy to obtain. ● Assumption of Stable Requirements: Like many estimation models, COCOMO assumes stable and well-defined requirements, which may not always be the case in real-world projects, leading to inaccurate estimates. ● Limited Consideration of Human Factors: While COCOMO considers some personnel attributes, it may not fully account for the impact of team dynamics, motivation, and skill levels on software development effort.
- 24. Project Scheduling & Tracking Although there are many reasons why software is delivered late, most can be traced to one or more of the following root causes: • An unrealistic deadline established by someone outside the software team and forced on managers and practitioners. • Changing customer requirements that are not reflected in schedule changes. • An honest underestimate of the amount of effort and/or the number of resources that will be required to do the job. • Predictable and/or unpredictable risks that were not considered when the project commenced. • Technical difficulties that could not have been foreseen in advance. • Human difficulties that could not have been foreseen in advance. • Miscommunication among project staff that results in delays. • A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem.
- 25. Software project scheduling is an action that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. It is important to note, however, that the schedule evolves over time. During early stages of project planning, a macroscopic schedule is developed. This type of schedule identifies all major process framework activities and the product functions to which they are applied. As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule. Here, specific software actions and tasks (required to accomplish an activity) are identified and scheduled.
- 26. Timeline charts A timeline chart, also known as a timeline diagram or a linear timeline, represents events or activities chronologically along a single axis, typically from left to right. Each event or activity is represented by a point or a line segment on the timeline, with its position indicating its occurrence in time. Timeline charts are often used to visualize historical events, project milestones, or sequential processes.
- 27. Key characteristics of a timeline chart: ● Linear Representation: Timeline charts have a linear representation of time, with events or activities plotted along a single axis. ● Chronological Order: Events or activities are arranged in chronological order from left to right, reflecting their occurrence in time. ● Limited Detail: Timeline charts typically provide limited detail about each event or activity, focusing more on their relative timing and sequence. ● Simple Visualization: Timeline charts are simple and easy to understand, making them useful for providing an overview of temporal relationships.
- 31. Gantt charts A Gantt chart is a horizontal bar chart that visually represents project schedules, tasks, and their dependencies over time. Each task or activity is represented by a horizontal bar, with its length indicating its duration, and its position along the timeline representing its start and end dates. Gantt charts are widely used in project management to plan, schedule, and track project progress.
- 32. Key characteristics of a Gantt chart: ● Bar Representation: Gantt charts use bars to represent tasks or activities, with the length of each bar indicating its duration. ● Time Scale: Gantt charts include a time scale along the horizontal axis, typically divided into days, weeks, or months, to show the project timeline. ● Task Dependencies: Gantt charts can depict dependencies between tasks, showing which tasks must be completed before others can start. ● Resource Allocation: Gantt charts often include information about resource allocation, such as assigning specific tasks to team members.
- 34. Kanban Boards A kanban board is an agile project management tool designed to help visualize work, limit work-in- progress, and maximize efficiency (or flow). It can help both agile and DevOps teams establish order in their daily work. Benefits ● Helps teams visualize their work and workflow ● Helps teams identify and reduce bottlenecks ● Helps teams minimize task-switching ● Helps teams allocate effort more effectively ● Helps teams clarify task ownership and facilitate collaboration
- 36. Using Kanban for remote project teams comes with several challenges, but solutions exist to ensure smooth collaboration and efficiency. Here’s a breakdown: Challenges & Solutions in Using Kanban for Remote Teams 1. Lack of Real-time Visibility Challenge: Unlike co-located teams, remote teams may struggle with staying updated on task status and progress. Solution: Use cloud-based Kanban tools like Trello, Jira, or Monday.com that offer real-time updates, notifications, and automated workflows. 2. Communication Gaps Challenge: Asynchronous communication in remote teams can lead to misunderstandings and delays. Solution: Establish clear guidelines for updates and discussions. Utilize messaging tools like Slack, Microsoft Teams, or Discord alongside Kanban boards. 3. Difficulty in Prioritization Challenge: Without direct discussions, remote teams may struggle with prioritizing tasks effectively. Solution: Implement WIP (Work In Progress) limits and regular check-ins (daily stand-ups or weekly syncs) to ensure proper prioritization. 4. Lack of Accountability & Ownership Challenge: Without physical presence, some tasks may fall through the cracks, leading to delays. Solution: Assign tasks explicitly to team members, set deadlines, and use automation features in Kanban tools to send reminders and track progress. 5. Time Zone Differences Challenge: Distributed teams across different time zones may face difficulties in coordination and decision-making. Solution: Use overlapping working hours for crucial meetings, document decisions thoroughly, and utilize asynchronous collaboration tools. 6. Resistance to Change Challenge: Team members unfamiliar with Kanban may resist adapting to the new workflow. Solution: Provide proper training, start with a simple board setup, and gradually introduce advanced features like automation and analytics. 7. Difficulty in Measuring Productivity Challenge: Tracking remote team productivity can be challenging without micromanaging. Solution: Use Kanban analytics like cycle time, lead time, and cumulative flow diagrams to measure progress instead of focusing on hours worked.
- 37. Burndown charts A burndown chart is a graphical representation of work left to do versus time. It is often used in agile software development methodologies such as Scrum. However, burn down charts can be applied to any project containing measurable progress over time. Typically, in a burndown chart, the outstanding work is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed. In the Daily Scrum the Development Team updates the Sprint Burn Down and plots the remaining work of the day. A burndown chart is almost a “must” have tool for a Scrum team for the following main reasons: ● Monitoring the project scope creep ● Keeping the team running on schedule ● Comparing the planned work against the team progression
- 38. Example Duration: 5 days Sprint Backlog: 8 tasks Velocity: 80 available hours Step 1 – Create Estimate Effort Suppose your ideal baseline for using the available hours over the sprint. So in the simplest for this is the available hours divided by number of days. In this example, 80 hours over 5 days equating to 16 hours a day. In order to create the project burn-down chart, the data needs to be captured as a daily running total starting with 80 hours than 64 hours left 1 (80 – 16) at end of day, 48 hours left at end of day 2, etc. Burndown - Estimate effort
- 39. Velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. It is an indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team. Thus, to calculate velocity of your agile team, simply add up the estimates of the features, user stories, requirements or backlog items successfully delivered in an iteration. It should the team: ● Predicting how much scope can be delivered by a specific date. ● Predicting a date for a fixed amount of scope to be delivered. ● Understanding our limits while defining the amount of scope we will commit for a sprint.
- 40. Step 2 – Track Daily Process The daily progress is then captured in the table against each task. It is important to remember that the value captured for each day is the estimated effort to complete the task, not the actual effort.
- 41. Step 3 – Compute the Actual Effort The total remaining effort needs to be captured at the end of each day. This is the total (sum) of all of the estimated time remaining at the end of each day. Step 4 – Obtain the Final Dataset When the data is available, the project burn-down chart can be created. This is relatively simple using the line chart option available within Excel.
- 42. Step 5 – Plot the Burndown using the Dataset It is very simple to create a project burn-down chart as following, as long as you know what data you are tracking.