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.
Software Project Planning
1
Introduction
• The overall goal of project planning is to
establish a realistic strategy for controlling,
tracking, and mo...
The Steps in Project Planning
• Scoping—understand the problem and the work
that must be done
• Estimation—how much effort...
Continue…
Project Scope
Estimates
Risks
Schedule
Control strategy
Software
Project
Plan
4
Understanding Scope
• Understand the customers needs
• understand the business context
• understand the project boundaries...
Project Planning Objectives
• The main objective of software project planning is to provide
a framework that enables the m...
Decomposition Techniques
• Software project estimation is a form of problem solving and
in most of the cases, the problem ...
Software Sizing
• The accuracy of a software project estimate is predicated on a
number of things:
– The degree to which t...
Continue…
• Let’s consider software sizing problem.
• A project estimate is only as good as the estimate of the size
of th...
Approaches to the Sizing Problem
• “Fuzzy Logic” sizing:
– This approach uses the appropriate reasoning techniques that ar...
Continue…
• Standard component sizing:
– Software is composed of a number of different standard components
that are generi...
Continue…
• Change sizing:
– This approach is used when a project encompasses the use of existing
software that must be mo...
Problem Based Estimation
• The LOC and FP data are used in two ways during software
project estimation:
• As an estimation...
Continue…
• LOC and FP is then estimated for each functions.
• Baseline productivity metrics ( e.g. LOC/pm or FP/pm9) are
...
15
LOC-Based Estimation
16
LOC-Based Estimation
Functions
UICF
2DGA
3DGA
DSM
CGDF
PCF
DAM
Totals
estimated LOC $/LOC Cost Effort (months)LOC/pm
2340
...
FP-Based Estimation
18
19
number of user inputs
number of user outputs
number of user inquiries
number of files
number of ext.interfaces
algorithms
...
Process Based Estimation
• Here, the process is decomposed into a relatively small set of
tasks and the efforts required t...
DFD and ERD
Quick Review
22
Elements of Analysis Model
• The analysis model must achieve three primary objectives:
– To describe what the customer req...
Why Data Modeling?
• examines data objects independently of processing
• focuses attention on the data domain
• creates a ...
Entity Relation Diagram (ERD)
• The ERD is the notation that is used to conduct the data
modeling activity.
• The objects ...
Cardinality
• It defines as the maximum number of objects that can participate in
a relationship.
• It is the specificatio...
(0, m) (1, 1)
object objectrelationship
1 2
One common form:
(0, m)
(1, 1)
object 1 object 2
relationship
Another common f...
(1,1) (1,m)
placesCustomer
request
for service
generates (1,n)
(1,1)
work
order
work
tasks
materials
consists
of
lists
(1,...
Need of DFD
29
Need of DFD
30
What are DFDs?
31
32
Symbols used in DFD
33
Continue…
34
Rules of Data Flow
35
Data Flow Diagrams
36
Styles in Drawing DFD
37
Describing a System with DFD
38
Context Diagram of Mess Management
System
39
Leveling DFD
40
Why do we level DFD?
41
Expanded DFD for Hostel Mess
Management System
42
Expanded DFD for Hostel Mess
Management System
43
Expanded DFD Billing system
44
Leveling Rules
45
Illegal Construction
46
Illegal Construction in DFD
47
Leveling Examples
Refer PP 321
48
The COCOMO 2 model
• An empirical model based on project experience.
• Well-documented, ‘independent’ model which is not t...
COCOMO 2 models
• COCOMO 2 incorporates a range of sub-models that produce
increasingly detailed software estimates.
• The...
COCOMO estimation models
51
Risk Management
• Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a p...
Examples of common project, product,
and business risks
Risk Affects Description
Staff turnover Project Experienced staff ...
The risk management process
• Risk identification
– Identify project, product and business risks;
• Risk analysis
– Assess...
The risk management process
55
Risk identification
• May be a team activities or based on the individual project
manager’s experience.
• A checklist of c...
Examples of different risk types
Risk type Possible risks
Technology The database used in the system cannot process as man...
Risk planning
• Consider each risk and develop a strategy to manage that risk.
• Avoidance strategies
– The probability th...
Strategies to help manage risk
Risk Strategy
Organizational financial
problems
Prepare a briefing document for senior mana...
Strategies to help manage risk
Risk Strategy
Organizational
restructuring
Prepare a briefing document for senior managemen...
Data Dictionary
• It is a repository that contains description of all data objects
consumed or produced by the software.
61
Building a Data Dictionary
62
Name:
Aliases:
Where used:
How used:
Description:
Format:
the primary name of the composite ...
Data Dictionary Notation
63
Notation
=
+
[ ]
{ }
( ... )
* ... text ...*
n
Meaning
is composed of
and
either-or
n repetiti...
Data Dictionary Example
64
telephone number
integrated
office
phone
system
Name:
Aliases:
Where/How
used:
Description:
For...
Upcoming SlideShare
Loading in …5
×

Software project plannings

SPP

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Software project plannings

  1. 1. Software Project Planning 1
  2. 2. Introduction • The overall goal of project planning is to establish a realistic strategy for controlling, tracking, and monitoring a complex technical project. • Why? • So the end result gets done on time, with quality! 2
  3. 3. The Steps in Project Planning • Scoping—understand the problem and the work that must be done • Estimation—how much effort? how much time? • Risk—what can go wrong? how can we avoid it? what can we do about it? • Schedule—how do we allocate resources along the timeline? what are the milestones? • Control strategy—how do we control quality? how do we control change? 3
  4. 4. Continue… Project Scope Estimates Risks Schedule Control strategy Software Project Plan 4
  5. 5. Understanding Scope • Understand the customers needs • understand the business context • understand the project boundaries • understand the customer’s motivation • understand the likely paths for change 5
  6. 6. Project Planning Objectives • The main objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. • These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progresses. • In addition, estimates should attempt to define best case and worst case scenario so that project outcomes can be controlled. • The planning objective is achieved through a process of information discovery that leads to reasonable estimates. 6
  7. 7. Decomposition Techniques • Software project estimation is a form of problem solving and in most of the cases, the problem to be solved ( i.e. developing a cost and efforts estimate for a software project) is to complex to be considered as one piece. • So, there is a need of decomposing the main problem into set of sub problems( manageable Unit) • We also call this approach as “ Divide and Conquer” . • Decomposition can be for “Process” or “Problem” • Estimation uses a single or both decomposition process. • Before applying any one of the decomposition process, software sizing, problem based estimation and process based estimation are to be known. 7
  8. 8. Software Sizing • The accuracy of a software project estimate is predicated on a number of things: – The degree to which the planner has properly estimated the size of the product to be built. – The ability to translate the size estimate into human efforts, calendar time and cost. – The degree to which the project plan reflects the abilities of the software team. – The stability of product requirements and the environment that supports the software engineering efforts. 8
  9. 9. Continue… • Let’s consider software sizing problem. • A project estimate is only as good as the estimate of the size of the work to be accomplished, sizing represent the project planner’s first major challenge. • In the context of project planning, the size refers to a quantifiable outcome of the software project. • In a direct approach, size can be measured in LOC and in indirect approach, size is represented as FP. 9
  10. 10. Approaches to the Sizing Problem • “Fuzzy Logic” sizing: – This approach uses the appropriate reasoning techniques that are the foundation of fuzzy logic. – To apply this approach, the planner must identify the type of application, establish its magnitude on a qualitative scale, and then refine the magnitude within the original range. • Function point sizing: – It uses a measure of the functionality delivered by the application as a normalization value. – Function points are derived using an experimential relationship based on the countable direct measures of software’s information domain and assessment of software complexity 10
  11. 11. Continue… • Standard component sizing: – Software is composed of a number of different standard components that are generic to a particular application area. – Example: Standard components for an information system are subsystem, modules, screens, reports, interactive programs, batch programs, files, LOC, and object level instructions. – The project planner estimates the number of occurrence of each standard component and then uses historical project data to determine the delivered size as per standard component. 11
  12. 12. Continue… • Change sizing: – This approach is used when a project encompasses the use of existing software that must be modified in some way as part of project. – The planner estimates the number and type( eg: reuse, adding code, changing code, deleting code) of modifications that must be accomplished. 12
  13. 13. Problem Based Estimation • The LOC and FP data are used in two ways during software project estimation: • As an estimation variable to size each element of the software • As baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort projections • LOC and FP are distinct estimation techniques: but they have few common features. • The project planner begins with bounded statements of software scope and from this statement attempts are made to decompose software into problem functions that can each be estimated individually. 13
  14. 14. Continue… • LOC and FP is then estimated for each functions. • Baseline productivity metrics ( e.g. LOC/pm or FP/pm9) are then applied to the appropriate estimation variable, and cost or effort for the function derive. • Function estimates are combined to produce an overall estimate of the entire project. • The LOC and FP estimation techniques differ in the level of details required for decomposition and the target of the partitioning. • When LOC is used as the estimation variable, decomposition is absolutely essential and is often taken to considerable levels of details. 14
  15. 15. 15
  16. 16. LOC-Based Estimation 16
  17. 17. LOC-Based Estimation Functions UICF 2DGA 3DGA DSM CGDF PCF DAM Totals estimated LOC $/LOC Cost Effort (months)LOC/pm 2340 5380 6800 3350 4950 2140 8400 33,360 14 20 20 18 22 28 18 315 220 220 240 200 140 300 32,000 107,000 136,000 60,000 109,000 60,000 151,000 655,000 7.4 24.4 30.9 13.9 24.7 15.2 28.0 145.0 17
  18. 18. FP-Based Estimation 18
  19. 19. 19
  20. 20. number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces algorithms measurement parameter 4 5 4 7 7 3 count x x x x x x count-total = = = = = = weight complexity multiplier feature points 0.25 p-m / FP = 120 p-m 40 25 12 4 4 60 160 125 48 28 28 180 569 .84 478 FP Based Estimation 20
  21. 21. Process Based Estimation • Here, the process is decomposed into a relatively small set of tasks and the efforts required to accomplish each task is identified. • Like the problem based estimation, process based estimation begins with a description of software functions obtained from the project scope. • A series of software process activities must be performed for each function. • Once problem functions and process activities are melded , the planner estimates the efforts ( eg. Person-month) that will be required to accomplish each software process activity for each software functions. 21
  22. 22. DFD and ERD Quick Review 22
  23. 23. Elements of Analysis Model • The analysis model must achieve three primary objectives: – To describe what the customer requires – To establish a basis for the creation of a software design – To define a set of requirements that can be validated once the software is built 23
  24. 24. Why Data Modeling? • examines data objects independently of processing • focuses attention on the data domain • creates a model at the customer’s level of abstraction • indicates how data objects relate to one another 24
  25. 25. Entity Relation Diagram (ERD) • The ERD is the notation that is used to conduct the data modeling activity. • The objects and its relationship is/are the main parts in data modeling. • These pairs can be represented graphically using the entity/relationship diagram. • A set of primary components such as : data objects, attributes, relationships are identified in ERD 25
  26. 26. Cardinality • It defines as the maximum number of objects that can participate in a relationship. • It is the specification of the number of occurrences of one object that can be related to the number of occurrence of another object. • One to One ( 1:1) : An occurrence of object “A” can relate to one and only one occurrence of object “B”; and vice versa • One to Many ( 1:N) : One occurrence of object “A” can relate to one or many occurrence of object “B”; but an occurrence of object “B” can relate to only one occurrence of object ‘A” • Many to Many (M:N) : An occurrence of object “A” can relate to one or more occurrence of object “B” and vice versa. • Students are asked to refer PP 319 for details. 26
  27. 27. (0, m) (1, 1) object objectrelationship 1 2 One common form: (0, m) (1, 1) object 1 object 2 relationship Another common form: attribute ERD Notation! 27
  28. 28. (1,1) (1,m) placesCustomer request for service generates (1,n) (1,1) work order work tasks materials consists of lists (1,1) (1,w) (1,1) (1,i) selected from standard task table (1,w) (1,1) ERD: An Example 28
  29. 29. Need of DFD 29
  30. 30. Need of DFD 30
  31. 31. What are DFDs? 31
  32. 32. 32
  33. 33. Symbols used in DFD 33
  34. 34. Continue… 34
  35. 35. Rules of Data Flow 35
  36. 36. Data Flow Diagrams 36
  37. 37. Styles in Drawing DFD 37
  38. 38. Describing a System with DFD 38
  39. 39. Context Diagram of Mess Management System 39
  40. 40. Leveling DFD 40
  41. 41. Why do we level DFD? 41
  42. 42. Expanded DFD for Hostel Mess Management System 42
  43. 43. Expanded DFD for Hostel Mess Management System 43
  44. 44. Expanded DFD Billing system 44
  45. 45. Leveling Rules 45
  46. 46. Illegal Construction 46
  47. 47. Illegal Construction in DFD 47
  48. 48. Leveling Examples Refer PP 321 48
  49. 49. The COCOMO 2 model • An empirical model based on project experience. • Well-documented, ‘independent’ model which is not tied to a specific software vendor. • Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. • COCOMO 2 takes into account different approaches to software development, reuse, etc. 49
  50. 50. COCOMO 2 models • COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. • The sub-models in COCOMO 2 are: – Application composition model. Used when software is composed from existing parts. – Early design model. Used when requirements are available but design has not yet started. – Reuse model. Used to compute the effort of integrating reusable components. – Post-architecture model. Used once the system architecture has been designed and more information about the system is available. 50
  51. 51. COCOMO estimation models 51
  52. 52. Risk Management • Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. • A risk is a probability that some adverse circumstance will occur – Project risks affect schedule or resources; – Product risks affect the quality or performance of the software being developed; – Business risks affect the organisation developing or procuring the software. 52
  53. 53. Examples of common project, product, and business risks Risk Affects Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organizational management with different priorities. Hardware unavailability Project Hardware that is essential for the project will not be delivered on schedule. Requirements change Project and product There will be a larger number of changes to the requirements than anticipated. Specification delays Project and product Specifications of essential interfaces are not available on schedule. Size underestimate Project and product The size of the system has been underestimated. CASE tool underperformance Product CASE tools, which support the project, do not perform as anticipated. Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed. 53
  54. 54. The risk management process • Risk identification – Identify project, product and business risks; • Risk analysis – Assess the likelihood and consequences of these risks; • Risk planning – Draw up plans to avoid or minimise the effects of the risk; • Risk monitoring – Monitor the risks throughout the project; 54
  55. 55. The risk management process 55
  56. 56. Risk identification • May be a team activities or based on the individual project manager’s experience. • A checklist of common risks may be used to identify risks in a project – Technology risks. – People risks. – Organisational risks. – Requirements risks. – Estimation risks. 56
  57. 57. Examples of different risk types Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected. (1) Reusable software components contain defects that mean they cannot be reused as planned. (2) People It is impossible to recruit staff with the skills required. (3) Key staff are ill and unavailable at critical times. (4) Required training for staff is not available. (5) Organizational The organization is restructured so that different management are responsible for the project. (6) Organizational financial problems force reductions in the project budget. (7) Tools The code generated by software code generation tools is inefficient. (8) Software tools cannot work together in an integrated way. (9) Requirements Changes to requirements that require major design rework are proposed. (10) Customers fail to understand the impact of requirements changes. (11) Estimation The time required to develop the software is underestimated. (12) The rate of defect repair is underestimated. (13) The size of the software is underestimated. (14) 57
  58. 58. Risk planning • Consider each risk and develop a strategy to manage that risk. • Avoidance strategies – The probability that the risk will arise is reduced; • Minimisation strategies – The impact of the risk on the project or product will be reduced; • Contingency plans – If the risk arises, contingency plans are plans to deal with that risk; 58
  59. 59. Strategies to help manage risk Risk Strategy Organizational financial problems Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business and presenting reasons why cuts to the project budget would not be cost- effective. Recruitment problems Alert customer to potential difficulties and the possibility of delays; investigate buying-in components. Staff illness Reorganize team so that there is more overlap of work and people therefore understand each other’s jobs. Defective components Replace potentially defective components with bought-in components of known reliability. Requirements changes Derive traceability information to assess requirements change impact; maximize information hiding in the design. 59
  60. 60. Strategies to help manage risk Risk Strategy Organizational restructuring Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Database performance Investigate the possibility of buying a higher-performance database. Underestimated development time Investigate buying-in components; investigate use of a program generator. 60
  61. 61. Data Dictionary • It is a repository that contains description of all data objects consumed or produced by the software. 61
  62. 62. Building a Data Dictionary 62 Name: Aliases: Where used: How used: Description: Format: the primary name of the composite data item other names for the data item data transforms (processes) that use the composite data item the role of the data item (input, output, temporary storage, etc. a notation for representing content (presented on next slide) specific information about data types, pre-set values (if known)
  63. 63. Data Dictionary Notation 63 Notation = + [ ] { } ( ... ) * ... text ...* n Meaning is composed of and either-or n repetitions of optional data delimits a comment
  64. 64. Data Dictionary Example 64 telephone number integrated office phone system Name: Aliases: Where/How used: Description: Format: telephone number phone number, number read-phone-number (input) display-phone-number (output) analyze-long-distance-calls (input) telephone no. = [ local extension | outside no. | 0] outside no. = 9 + [ service code | domestic no. ] service code = [ 211 |411 |611 |911 ] domestic no. = ( ( 0 ) + area code ) + local number area code = *three numeral designator* Build the requirements dictionary: alphanumeric data system output

    Be the first to comment

    Login to see the comments

SPP

Views

Total views

1,524

On Slideshare

0

From embeds

0

Number of embeds

3

Actions

Downloads

20

Shares

0

Comments

0

Likes

0

×