Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing software project, software engineering


Published on

Software Metrics (Process, Product and Project Metrics), Software Project Estimations, Software Project Planning (MS Project Tool), Project Scheduling & Tracking, Risk Analysis &Management (Risk Identification, Risk Projection, Risk Refinement , Risk Mitigation).

Published in: Engineering
  • Be the first to comment

Managing software project, software engineering

  1. 1. Unit-3 Managing Software Project
  2. 2. Terminology • Measure: Quantitative indication of the extent, amount, dimension, or size of some attribute of a product or process. • Metrics: The degree to which a system, component, or process possesses a given attribute. Relates several measures (e.g. average number of errors found per person hour) • Indicators: A combination of metrics that provides insight into the software process, project or product • Direct Metrics: Immediately measurable attributes (e.g. line of code, execution speed, defects reported) • Indirect Metrics: Aspects that are not immediately quantifiable (e.g. functionality, quantity, reliability) • Faults: − Errors: Faults found by the practitioners during software development − Defects: Faults found by the customers after release
  3. 3. Why Measure Software? • Determine quality of the current product or process • Predict qualities of a product/process • Improve quality of a product/process
  4. 4. Example Metrics • Defects rates • Errors rates • Measured by: – individual – module – during development • Errors should be categorized by origin, type, cost
  5. 5. Metric Classification • Products – Explicit results of software development activities. – Deliverables, documentation, by products • Processes – Activities related to production of software • Project – Inputs into the software development activities – hardware, knowledge, people
  6. 6. Product vs. Process • Process Metrics- – Insights of process paradigm, software engineering tasks, work product, or milestones. – Lead to long term process improvement. • Product Metrics- – Assesses the state of the project – Track potential risks – Uncover problem areas – Adjust workflow or tasks – Evaluate teams ability to control quality
  7. 7. Process Metrics • Focus on quality achieved as a consequence of a repeatable or managed process. Strategic and Long Term. • Statistical Software Process Improvement (SSPI). Error Categorization and Analysis: All errors and defects are categorized by origin The cost to correct each error and defect is recorded The number of errors and defects in each category is computed Data is analyzed to find categories that result in the highest cost to the organization Plans are developed to modify the process • Defect Removal Efficiency (DRE). Relationship between errors (E) and defects (D). The ideal is a DRE of 1: )/( DEEDRE +=
  8. 8. Project Metrics • Used by a project manager and software team to adapt project work flow and technical activities. Tactical and Short Term. • Purpose: − Minimize the development schedule by making the necessary adjustments to avoid delays and mitigate problems − Assess product quality on an ongoing basis • Metrics: − Effort or time per SE task − Errors uncovered per review hour − Scheduled vs. actual milestone dates − Number of changes and their characteristics − Distribution of effort on SE tasks
  9. 9. Product Metrics • Focus on the quality of deliverables • Product metrics are combined across several projects to produce process metrics • Metrics for the product: − Measures of the Analysis Model − Complexity of the Design Model 1. Internal algorithmic complexity 2. Architectural complexity 3. Data flow complexity − Code metrics
  10. 10. Types of Measures • Direct Measures (internal attributes) – Cost, effort, LOC, speed, memory • Indirect Measures (external attributes) – Functionality, quality, complexity, efficiency, reliability, maintainability
  11. 11. Size Oriented Metrics • Size of the software produced • Lines Of Code (LOC) • 1000 Lines Of Code KLOC • Effort measured in person months • Errors/KLOC • Defects/KLOC • Cost/LOC • Documentation Pages/KLOC • LOC is programmer & language dependent
  12. 12. LOC Metrics • Easy to use • Easy to compute • Can compute LOC of existing systems but •cost and requirements traceability may be lost • Language & programmer dependent
  13. 13. Function Point Metrics • Function point metrics provide a standardized method for measuring the various functions of a software application. • Function point metrics, measure functionality from the users point of view, that is, on the basis of what the user requests and receives in return
  14. 14. Function Point Metrics • Number of user inputs – Distinct input from user • Number of user outputs – Reports, screens, error messages, etc • Number of user inquiries – On line input that generates some result • Number of files – Logical file (database) • Number of external interfaces – Data files/connections as interface to other systems
  15. 15. Compute Function Points • FP = Total Count * [0.65 + 0.01*∑(Fi)] • Total count is all the counts times a weighting factor that is determined for each organization via empirical data • Fi (i=1 to 14) are complexity adjustment values
  16. 16. Compute Function Points
  17. 17. Function Point Analysis A simple example: inputs 3 simple X 3 = 6 4 average X 4 = 16 1 complex X 6 = 6 outputs 6 average X 5 = 30 2 complex X 7 = 14 files 5 complex X 15 = 75 inquiries 8 average X 4 = 32 interfaces 3 average X 7 = 21 4 complex X 10 = 40 Unadjusted function points 240
  18. 18. Value Adjustment Factors F1. Data Communication F2. Distributed Data Processing F3. Performance F4. Heavily Used Configuration F5. Transaction Role F6. Online Data Entry F7. End-User Efficiency F8. Online Update F9. Complex Processing F10. Reusability F11. Installation Ease F12. Operational Ease F13. Multiple Sites F14. Facilitate Change
  19. 19. Function Point Analysis Continuing our example . . . Complex internal processing = 3 Code to be reusable = 2 High performance = 4 Multiple sites = 3 Distributed processing = 5 Project adjustment factor = 17 Adjustment calculation: Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)] = 240 X [0.65 + ( 17 X 0.01)] = 240 X [0.82] = 197 Adjusted function points
  20. 20. Compute Function Points Example-1 Study of requirement specification for a project has produced following results: Need for 7 inputs, 10 outputs, 6 inquiries, 17 files and 4 external interfaces. Input and external interface function point attributes are of average complexity and all other function points attributes are of low complexity Determine adjusted function points assuming complexity adjustment value is 32. •Total count = 233 •Fp = 226.01
  21. 21. Compute Function Points Example-2 GTU- May, Dec 2013 Compute the function points for the given data set Inputs = 8 Outputs = 12 Inquiries= 4 Logical files = 41 Interfaces = 1 Value adjustment factor ∑Fi= 41 •Total count = 525 •Fp = 556.5
  22. 22. Compute Function Points Example-3 A system has 12 external inputs, 24 external outputs, fields 30 different external queries, manages 4 internal logical files, and interfaces with 6 different legacy systems (6 EIFs). All of these data are of average complexity and assume that all complexity adjustment values are average. Compute FP for the system.
  23. 23. Compute Function Points Example-4 Compute the function points for the given data set Inputs = 32 Outputs = 60 Inquiries= 24 Logical files = 8 Interfaces = 2 Assume that all complexity adjustment values are average
  24. 24. Software Project Estimation Decomposing • Software project estimation is a form of problem solving, and in most cases, the problem to be solved is too complex to be considered in one piece. • For this reason, decomposing the problem, re- characterizing it as a set of smaller problems. • Before an estimate can be made, the project planner must understand the scope of the software to be built and generate an estimate of its "size."
  25. 25. Software Project Estimation • Software Sizing • Problem based Estimation – LOC based – FP based • Process based Estimation • Estimation with Use-cases
  26. 26. Introduction • Before an estimate can be made and decomposition techniques applied, the planner must – Understand the scope of the software to be built – Generate an estimate of the software’s size • Then one of two approaches are used – Problem-based estimation • Based on either source lines of code or function point estimates – Process-based estimation • Based on the effort required to accomplish each task
  27. 27. Approaches to Software Sizing • Function point sizing – Develop estimates of the information domain characteristics (Ch. 15 – Product Metrics for Software) • Standard component sizing – Estimate the number of occurrences of each standard component – Use historical project data to determine the delivered LOC size per standard component • Change sizing – Used when changes are being made to existing software – Estimate the number and type of modifications that must be accomplished – Types of modifications include reuse, adding code, changing code, and deleting code – An effort ratio is then used to estimate each type of change and the size of the change
  28. 28. Problem-Based Estimation 1) Start with a bounded statement of scope 2) Decompose the software into problem functions that can each be estimated individually 3) Compute an LOC or FP value for each function 4) Derive cost or effort estimates by applying the LOC or FP values to your baseline productivity metrics (e.g., LOC/person- month or FP/person-month) 5) Combine function estimates to produce an overall estimate for the entire project
  29. 29. Problem-Based Estimation (continued) • In general, the LOC/pm and FP/pm metrics should be computed by project domain – Important factors are team size, application area, and complexity • LOC and FP estimation differ in the level of detail required for decomposition with each value – For LOC, decomposition of functions is essential and should go into considerable detail (the more detail, the more accurate the estimate) – For FP, decomposition occurs for the five information domain characteristics and the 14 adjustment factors • External inputs, external outputs, external inquiries, internal logical files, external interface files pm = person month
  30. 30. Problem-Based Estimation (continued) • For both approaches, the planner uses lessons learned to estimate an optimistic, most likely, and pessimistic size value for each function or count (for each information domain value) • Then the expected size value S is computed as follows: S = (Sopt + 4Sm + Spess)/6 • Historical LOC or FP data is then compared to S in order to cross-check it
  31. 31. Process-Based Estimation Obtained from “process framework”Obtained from “process framework” application functions framework activitiesframework activities Effort required to accomplish each framework activity for each application function
  32. 32. Process-Based Estimation 1) Identify the set of functions that the software needs to perform as obtained from the project scope 2) Identify the series of framework activities that need to be performed for each function 3) Estimate the effort (in person months) that will be required to accomplish each software process activity for each function
  33. 33. Process-Based Estimation (continued) 4) Apply average labor rates (i.e., cost/unit effort) to the effort estimated for each process activity 5) Compute the total cost and effort for each function and each framework activity 6) Compare the resulting values to those obtained by way of the LOC and FP estimates • If both sets of estimates agree, then your numbers are highly reliable • Otherwise, conduct further investigation and analysis concerning the function and activity breakdown This is the most commonly used of the two estimation techniques (problem and process)
  34. 34. Empirical Estimation
  35. 35. Techniques a) Source lines of Code (SLOC) b) Function Point (FP) c) Constructive Cost Model (COCOMO)
  36. 36. SOLC • The project size helps determine the resources, effort, and duration of the project. • SOLC is defined as the source lines of code that are delivered as part of the product. • The effort spent on creating the source lines of code is expressed in relation to thousand lines of code (KLOC). • This technique includes the calculation of lines of code, documentation of pages, inputs, outputs, and components of a software program. • The SLOC technique is language-dependent. The effort required to calculate
  37. 37. COCOMO • Stands for COnstructive COst MOdel • Introduced by Barry Boehm in 1981 • Became one of the well-known and widely-used estimation models in the industry • It has evolved into a more comprehensive estimation model called COCOMO II • COCOMO II is actually a hierarchy of three estimation models • As with all estimation models, it requires sizing information and accepts it in three forms: object points, function points, and lines of source code
  38. 38. COCOMO Models • Application composition model - Used during the early stages of software engineering when the following are important – Prototyping of user interfaces – Consideration of software and system interaction – Assessment of performance – Evaluation of technology maturity • Early design stage model – Used once requirements have been stabilized and basic software architecture has been established • Post-architecture stage model – Used during the construction of the software
  39. 39. Organic, Semidetached and Embedded software projects • Organic: A development project can be considered of 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 types of projects. • Semidetached: A development project can be considered of semidetached type, if the development consists of a mixture of experienced and inexperienced staff. Team members may have limited experience on related systems but may be unfamiliar with some aspects of the system being developed. • Embedded: A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware, or if the stringent regulations on the operational procedures exist.
  40. 40. Basic CoCoMo Model
  41. 41. Project Scheduling & Tracking • Software project scheduling is an action that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks.
  42. 42. Scheduling Principles - 1 • Compartmentalization – the product and process must be decomposed into a manageable number of activities and tasks • Interdependency – tasks that can be completed in parallel must be separated from those that must completed serially • Time allocation – every task has start and completion dates that take the task interdependencies into account
  43. 43. Scheduling Principles - 2 • Effort validation – project manager must ensure that on any given day there are enough staff members assigned to completed the tasks within the time estimated in the project plan • Defined Responsibilities – every scheduled task needs to be assigned to a specific team member
  44. 44. Scheduling Principles - 3 • Defined outcomes – every task in the schedule needs to have a defined outcome (usually a work product or deliverable) • Defined milestones – a milestone is accomplished when one or more work products from an engineering task have passed quality review
  45. 45. Effort Distribution • general guideline - 40-20-40 rule • 40% or more of all effort allocated to analysis and design tasks • 40% of effort allocated to testing • 20% of effort allocated to programming • characteristics of each project dictate the distribution of effort
  46. 46. 48 Project Effort Distribution Generally accepted guidelines are: 02-03 % planning 10-25 % requirements analysis 20-25 % design 15-20 % coding 30-40 % testing and debugging
  47. 47. Project types: • concept development projects – initiated to explore some new business concept or application of new technology • new application development – undertaken due to specific customer request • application enhancement • application maintenance • reengineering – rebuild existing legacy system
  48. 48. Software Project Types - 1 • Concept development – initiated to explore new business concept or new application of technology • New application development – new product requested by customer • Application enhancement – major modifications to function, performance, or interfaces (observable to user)
  49. 49. Software Project Types - 2 • Application maintenance – correcting, adapting, or extending existing software (not immediately obvious to user) • Reengineering – rebuilding all (or part) of a legacy system
  50. 50. Task network
  51. 51. Scheduling Scheduling of a software project does not differ greatly from scheduling of any multitask engineering effort. Two project scheduling methods: - Program Evaluation and Review Technique (PERT) - Critical Path Method (CPM) Both methods are driven by information developed in earlier project planning activities: - Estimates of effort - A decomposition of product function - The selection of the appropriate process model - The selection of project type and task set Both methods allow a planer to do: - determine the critical path - time estimation - calculate boundary times for each task Boundary times: - the earliest time and latest time to begin a task - the earliest time and latest time to complete a task - the total float.
  52. 52. Tracking the Schedule he project schedule provides a road map for a software project manager. defines the tasks and milestones. everal ways to track a project schedule: - conducting periodic project status meeting - evaluating the review results in the software process - determine if formal project milestones have been accomplished - compare actual start date to planned start date for each task - informal meeting with practitioners roject manager takes the control of the schedule in the aspects of: - project staffing - project problems - project resources - reviews - project budget
  53. 53. Risk Management
  54. 54. Definition of Risk • A risk is a potential problem – it might happen and it might not • Conceptual definition of risk – Risk concerns future happenings – Risk involves change in mind, opinion, actions, places, etc. – Risk involves choice and the uncertainty that choice entails • Two characteristics of risk – Uncertainty – the risk may or may not happen, that is, there are no 100% risks (those, instead, are called constraints) – Loss – the risk becomes a reality and unwanted consequences or losses occur
  55. 55. Risk Categorization – Approach #1 • Project risks – They threaten the project plan – If they become real, it is likely that the project schedule will slip and that costs will increase • Technical risks – They threaten the quality and timeliness of the software to be produced – If they become real, implementation may become difficult or impossible • Business risks – They threaten the feasibility of the software to be built – If they become real, they threaten the project or the product
  56. 56. Risk Categorization – Approach #1 • Sub-categories of Business risks – Market risk – building an excellent product or system that no one really wants – Strategic risk – building a product that no longer fits into the overall business strategy for the company – Sales risk – building a product that the sales force doesn't understand how to sell – Management risk – losing the support of senior management due to a change in focus or a change in people – Budget risk – losing budgetary or personnel commitment
  57. 57. Risk Categorization – Approach #2 • Known risks – Those risks that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date) • Predictable risks – Those risks that are deduced from past project experience (e.g., past turnover) • Unpredictable risks – Those risks that can and do occur, but are extremely difficult to identify in advance
  58. 58. Reactive vs. Proactive Risk Strategies • Reactive risk strategies – "Don't worry, I'll think of something" – The majority of software teams and managers rely on this approach – Nothing is done about risks until something goes wrong • The team then flies into action in an attempt to correct the problem rapidly (fire fighting) – Crisis management is the choice of management techniques • Proactive risk strategies – Steps for risk management are followed – Primary objective is to avoid risk and to have a emergency plan in place to handle unavoidable risks in a controlled and effective manner
  59. 59. Steps for Risk Management 1) Identify possible risks; recognize what can go wrong 2) Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that it will do if it does occur 3) Rank the risks by probability and impact - Impact may be negligible, marginal, critical, and catastrophic 4) Develop a contingency plan to manage those risks having high probability and high impact
  60. 60. Risk Identification
  61. 61. Background • Risk identification is a systematic attempt to specify threats to the project plan • By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary • Generic risks – Risks that are a potential threat to every software project • Product-specific risks – Risks that can be identified only by those a with a clear understanding of the technology, the people, and the environment that is specific to the software that is to be built – This requires examination of the project plan and the statement of scope – "What special characteristics of this product may threaten our project plan?"
  62. 62. Known and Predictable Risk Categories • Product size – risks associated with overall size of the software to be built • Business impact – risks associated with constraints imposed by management or the marketplace • Customer characteristics – risks associated with sophistication of the customer and the developer's ability to communicate with the customer in a timely manner • Process definition – risks associated with the degree to which the software process has been defined and is followed • Development environment – risks associated with availability and quality of the tools to be used to build the project • Technology to be built – risks associated with complexity of the system to be built and the "newness" of the technology in the system • Staff size and experience – risks associated with overall technical and project experience of the software engineers who will do the work
  63. 63. Risk Projection (Estimation)
  64. 64. Background • Risk projection (or estimation) attempts to rate each risk in two ways – The probability that the risk is real – The consequence of the problems associated with the risk, should it occur
  65. 65. Risk Projection/Estimation Steps 1) Establish a scale that reflects the perceived likelihood of a risk (e.g., 1-low, 10-high) 2) Explain the consequences of the risk 3) Estimate the impact of the risk on the project and product 4) Note the overall accuracy of the risk projection so that there will be no misunderstandings
  66. 66. Risk Mitigation, Monitoring, and Management
  67. 67. Background • An effective strategy for dealing with risk must consider three issues (Note: these are not mutually exclusive) – Risk mitigation (i.e., avoidance) – Risk monitoring – Risk management and contingency planning • Risk mitigation (avoidance) is the primary strategy and is achieved through a plan – Example: Risk of high staff turnover
  68. 68. Seven Principles of Risk Management• Maintain a global perspective – View software risks within the context of a system and the business problem that is is intended to solve • Take a forward-looking view – Think about risks that may arise in the future; establish contingency plans • Encourage open communication – Encourage all stakeholders and users to point out risks at any time • Integrate risk management – Integrate the consideration of risk into the software process • Emphasize a continuous process of risk management – Modify identified risks as more becomes known and add new risks as better insight is achieved • Develop a shared product vision – A shared vision by all stakeholders facilitates better risk identification and assessment • Encourage teamwork when managing risk – Pool the skills and experience of all stakeholders when conducting risk management activities