Balancing software project drivers a rational quantitative approach

450 views
349 views

Published on

The DSS presented in this document is a tool that improves the effectiveness of the decision making process that results in estimating, planning, and adapting: the products (software architecture, design specifications and code ), the activities (designing architecture, defining design specifications, and producing code) , and the measures of goodness (number of known requirements met, degree of resilience to new requirements, and degree of reusability) of the design and implementation phases of a Software Development Life Cycle.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
450
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Balancing software project drivers a rational quantitative approach

  1. 1. Page 1 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting Balancing Software Project Drivers - A Rational Quantitative Approach
  2. 2. Page 2 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting IntroductionThe increasing role of mission critical software products and a highly competitive software market leaves little room for poorlymanaged software projects with unclear development processes [Yourdon, 1997].Decision Support Systems (DSS) are valuable tools that can help software project managers model their decision problems. A DSS canalso provide great value in assessing the potential impact of alternative course of actions [Sage, 1991].From a global perspective on software projects, Grady Booch [1998] defines several “Artifacts” as being byproducts of developmentprocesses or aids to development processes. These artifacts are classified according to their principle users or according to the clientsthat they serve: the development team itself, end users, and software management teams.The development team artifacts are: The software’s architecture Design specifications CodeThe end users’ artifacts are: The software requirements Data i.e. raw information that may be used within or across applications inside the end users’ organization Human interfaces i.e. general look and feel of a family of programsThe software project management team artifacts are: Estimates (costs, development time, quality level) Project plans (staffing and scheduling ) DocumentationThe Decision Support System (DSS) presented in this document is a tool that facilitates the definition and production of project estimatesand project plans focused on the design and implementation phases of the software development life cycle.Booch also suggests that every well-define process has four roles: Provide guidance as to the order of a team’s activities
  3. 3. Page 3 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting Specify what artifacts should be developed Direct the tasks of individual developers and the team as a whole Offer criteria for monitoring and measuring the project’s products and activitiesHe then respectively relates these four roles to the purpose, products, activities, and measures of goodness of each phase of a softwaredevelopment life cycle.The DSS presented in this document is a tool that improves the effectiveness of the decision making process that results in estimating,planning, and adapting: the products (software architecture, design specifications and code ), the activities (designing architecture, defining design specifications, and producing code) and the measures of goodness (number of known requirements met, degree of resilience to new requirements, and degree of reusability)of the design and implementation phases of a software development life cycle.1-System ScopeThe general architecture of the DSS is presented in figure 1. It contains the following subsystems: User Interface that permits the dialog between the DSS and its users. Database that provides persistent storage of the data manipulated by the DSS. ModelBase that is the representation of the mathematical models used by the DSS. Database Management System. Modelbase Management System. Management Software that integrates the communications among the User Interface, the Database Management System, and the ModelBase Management System.
  4. 4. Page 4 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting2-Project ScopeTo the best of my knowledge, the DSS described in this project does not refer to an existing system utilized by a commercial orgovernment software development organization. Furthermore, this DSS is not tailored to any specific software developmentorganization. The project findings and results although substantial are kept generic enough to be utilized by an existing organization orbecome part of the foundation of a new business. Figure 1: DSS High Level Architecture
  5. 5. Page 5 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting MODELBASE ANALYSIS1-Overview1.1-Single software project management policiesSoftware management teams continuously strive to achieve balance in fulfilling stakeholders’ expectations. Attaining such a balancefrequently involves conducting a continuous trade off of the software feature set, cost, schedule, and degree of reusability [Rico 2004].Taken individually, each one of the figures being traded off has associated with it a specific optimal achievement direction that definesits management policy. They are summarized in the following table: Objective or Management Policy Object Deliver software that has as many requirements met as Software features set possible Do not exceed budgeted costs Software development effort cost Deliver software on schedule Software delivery schedule Produce software with as many reusable features as possible Software degree of reusability.We have related the individual objectives mentioned previously to quantitative expressions that capture their essence.Several software management objectives compete to be totally fulfilled. Software development managers are faced with the challengeof finding the optimal balance of these objectives. A useful approach is to prioritize these objectives according to what the DecisionMaker judges as the most important objectives to achieve.Once the objectives have been ranked, the optimal balance of fulfilled objectives can be derived by several techniques. GoalProgramming techniques fit well the problem at hand. The achievement function of the goal programming problem expresses theoptimal balance in achieving the various stated goals.
  6. 6. Page 6 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting1.2-Multiple related software projects managementBeyond managing a single software project, software development management teams have to address management decisions thatinvolve several related successive or concurrent software projects. Here the focus is mainly on the design and implementation phasesof successive software products that share to varying degrees commonalties in terms of architecture, detail design specifications, andtypes of implemented functionalities.The set of related software projects has the following characteristic: each software project covers activities that are initiated by thedefinition of a specific set of software requirements; they include the production of design artifacts and the implementation and testingof software code prior to being packaged as releasable software product.Two planning approaches that respond to two kinds of planning strategies are presented. Both approaches try to match future projectcharacteristics to development effort capability: The first strategy is to find the kind of software projects that match the current profile of the organization software development capability. The second strategy is to define the organization software development capability that will match a given set of future software projects.1.3-Model elementsA software product development effort conducted by an organization generates two major artifacts: Design Specifications (Software Architecture and Detail Design Specifications) Software Code.We define three types of software development efforts for the production of design specifications and the implementation of softwareCode: Efforts that require “no real effort” (indexed O), Efforts that produced partially or totally reusable features (indexed N), Efforts that produced non-reusable features (indexed W).Software Architects and software abstractionists are most often in charge of producing the software architecture and designspecifications while Application Engineers are responsible for implementing the software Code [Grady Booch, 1998].
  7. 7. Page 7 of 25 Copyright © 2010-2013 Pragmatic Cohesion ConsultingCompared to the production of non-reusable features, the production of reusable features requires more experience and more advancedskills from the team assigned to it. Therefore, there is a high probability that team members assigned to the production of reusablefeatures will sell their experience and skills at a higher price than those assigned to the production of non-reusable features.Our discussion introduces the design of the software architecture as a major driver for the remaining detail design and codeimplementation activities [Rosenberg, Stephens, Collins-Cope; 2005].Reusable features of the software as well as features of the software that were produced with little or no efforts are also introduced ashaving a strategic value in terms of custom development time saving. The use and production of these types of features relate toWalker Royce’s [1998] component-based development that defines a component as “a cohesive set of preexisting lines of code, eitherin source or executable format, with a defined interface and behavior”.Our model uses ratios that define the mean rate at which design specifications are produced and the mean rate at which software codeis implemented. The values of these rates depend on various factors such as: Skill level of the development team, Size of the development team, Development tools, Development methodology or paradigm,These factors strongly vary from one organization to the next.Our model also includes development cost figures that relate to the 3 types of development efforts previously defined [Bohem andPapaccio, 1988]. Cost figures are related to the production rates previously discussed, the mean time required for producing designspecifications, and the mean time required for implementing software code. These cost figures also strongly depend on the: Skill level of the development team, Size of the development team, Development tools, Development methodology or paradigm,Once again, these factors will likely vary from one organization to the next.The degree to which software features can be reused to develop multiple software products depends mainly on: The similarity between the initial software and the other ones in terms of problem domain, requirements set, programming language, notations, machine architecture, development tool, and standards.
  8. 8. Page 8 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting The actual occurrence of identical software components across several projects.Reusable software components could be source code libraries or software design frameworks with multiple classes, interfaces, orfunctions.2-Model Details2.1-Single software project management policiesSoftware Feature SetThe software feature set needs to be complete in order to meet the software requirements. But it is a moving target since severalrequirements are at first unknown and are discovered only during the development phase.Software development effort costThe software cost needs to be minimized and needs to be lower than a given budgeted cost. As often noticed, several software projectsare above expected cost therefore the actual incurred cost needs to be as close as possible to the budgeted cost if it exceeds it.Software delivery scheduleAny planned deadline of a software release needs ideally to be exactly met. Software projects are known to be delivered late thereforethe actual incurred development time needs to be as close as possible to the planned time if it exceeds it.Software degree of reusabilityWith respect to the two sets of development efforts (specifying Architecture/Design and Implementing Code) software developmentteams need to yield the best balance of skills and size that allows the completion of the software within the planned schedule and at thebudgeted cost while taking advantage of as many reusable software components as possible.2.2-Multiple related software projects management policiesRelated projects could be about different software products or they could be about several releases or versions of a same softwareproduct. The analysis approach that is presented in this section tries to offer a generic enough framework that applies to both types ofsoftware products.
  9. 9. Page 9 of 25 Copyright © 2010-2013 Pragmatic Cohesion ConsultingIn the case of successive releases of the same software product, the most recent set of software requirements may vary due to thefollowing reasons: in response to feedback from users who expect more or different software features. in response to the discovery by the development team of major overseen software requirements.In the case of different successive software products, a new set of software requirements is usually determine in response to theidentification of new markets to conquer.2.3-Further definition of development effortsWe are postulating that a software product development effort conducted by an organization generates 2 major artifacts: a set of designspecifications and a set of implemented software code.Any design specification or implemented software code can be decomposed into 3 distinct subsets: The first subset is characterized by the fact that its production requires little or no consumption of development efforts in order to become part of the software product; it is either directly taken from a previous software development effort within the same organization or it is bought from a third party vendor. The second subset is characterized by the fact that its production is the result of a new development effort conducted within the organization and it has the properties of being totally or partially reusable for other software development efforts. The third subset is characterized by the fact that it is also the result of a new development effort but it is very unlikely to be reused for another software development effort.Let introduce the following convention: The software is represented as a first set of D design specifications and a second set of C implemented software code. O Index represents the first subset of the software that does not require new development efforts. N Index represents the second subset of the software that requires new development efforts and is partially or totally reusable. W Index represents the third subset of the software that requires new development efforts and is not reusable.The following variables are introduced: PDO and PCO: are respectively the mean proportions of total software Design Specifications and Software Code that do not require new development efforts.
  10. 10. Page 10 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting PDN and PCN: are respectively the mean proportions of total Software Design Specifications and Software Code that require new development efforts and that are partially or totally reusable. PDW and PCW: are respectively the mean proportions of total Software Design Specifications and Software Code that require new development efforts and that are not reusable. With the following relation holding: PDO+PDN+PDW = 1 [E1] PCO+PCN+PCW = 1 [E2]Let D represent the total amount of Design Specifications. D’s unit could be for example the number of classes and interfaces or anyother metric that is be suitable to size the set of Design Specifications. It is possible to derive the following variables from (E1): DO = PDO x D : the mean amount of design specifications of the software that do not require new development efforts. DN = PDN x D : the mean amount of design specifications of the software that require new development efforts and that are totally or partially reusable. DW = PDW x D : the mean amount of design specifications of the software that require new development efforts and that are not reusable.Let C represent a measure of the total size of implemented Software Code. C’s unit could be for example in Software Lines of Code orany other metric that is appropriate to size the set of implemented Software Code. By analogy, the following variables can be identifiedfor the software code: CO = PCO x C : the mean amount of Software Code that do not require new development efforts. CN = PCN x C : the mean amount of Software Code that requires new development efforts and that is totally or partially reusable. CW = PCW x C : the mean amount of Software Code that requires new development efforts and that is not reusable.The magnitudes of DO and CO are especially useful to the development effort since they require no development time. DN and CNrepresent a substantial development efforts “investment” for the current software project but they have the potential to fully or partiallybecome the “DO” and “CO” of other software development efforts. DW and CW are “one time use” development efforts with no orvery little chance of ever being reuse in another software development projects.In summary, three types of software development efforts have been defined for the production of design specifications and theimplementation of software code: those that require “no real effort” (indexed O),
  11. 11. Page 11 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting those that produced partially or totally reusable features (indexed N), those that produced non-reusable features (indexed W).2.4-Allocation of resources to development effortsSoftware development efforts can be viewed as the production of design specifications and the implementation of software code. Fromthe previous paragraph, we have defined three groups of such efforts among which only two really require new consumption of staffresources in order to take place: the production of reusable features and the production of non-reusable features.Software architects and software abstractionists are most often in charge of producing the software architecture and designspecifications. Application engineers are responsible for the implementation of software code [Grady Booch, 1998]. According to ourdefinition of software effort types, both the production of design specifications and the implementation of software code need to covertwo activities: the first one resulting in the production of reusable features and the second one resulting in the production of non-reusable features. Compared to the production of non-reusable features, the production of reusable features requires more experienceand more advanced skills from the team assigned to it. Therefore, there is a high probability that team members assigned to theproduction of reusable features sell their experience and skills at a higher price than those assigned to the production of non-reusablefeatures. In addition, software architects and software abstractionists cost more than application engineers but they are in much lessernumber than the application engineers in most software development projects.2.5- Relationship with 2 major principles of modern software development management.In 1998 Walker Royce presents 10 principles of modern software management. The first one and the third one are quoted next.First -Base the process on an architecture-first approach.Third -Transition design methods to emphasize component-based development.Our discussion has introduced the design of the software architecture as a major driver of both the remaining design andimplementation activities.Reusable features of the software as well as features of the software that were produced with little or no efforts were also presented ashaving a strategic value in terms of custom development time saving. The use and production of these types of features relate toRoyce’s component-based development that defines a component as “a cohesive set of preexisting lines of code, either in source orexecutable format, with a defined interface and behavior”.
  12. 12. Page 12 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting2.6- Rates of productionIn this section, we are interested in establishing a relationship between time and the variables expressing the mean amount of designspecifications and the mean amount of implemented software code. We introduce the following variables: TDN: mean time required to produce DN amount of design specifications TDW: mean time required to produce DW amount of design specifications TDO: mean time required to produce DO amount of design specifications. TDO by definition is equal to 0 units of time TCN: mean time required to implement CN amount of software code TCW: mean time required to implement CW amount of software code TCO: mean time required to implement CO amount of software code. TCO by definition is equal to 0 units of time.The following ratios define the mean rate at which design specifications are produced and the mean rate at which software code isimplemented.CDN = DN/TDN : mean production rate of DN amount of design specifications.CDW = DW/TDW : mean production rate of DW amount of design specifications.CCN = CN/TCN : mean implementation rate of CN amount of software code.CCW = CW/TCW : mean implementation rate of CW amount of software code.The following relations can be derived: DN = CDN x TDN [E10]: the mean amount of design specifications that require new development efforts and that are totally or partially reusable. DW = CDW x TDW [E11]: the mean amount of design specifications that require new development efforts and that are not reusable. CN = CCN x TCN [E12]: the mean amount of Software Code that requires new development efforts and that is totally or partially reusable. CW = CCW x TCW [E13]: the mean amount of Software Code that requires new development efforts and that is not reusable.The values of the above variables depend on various factors such as: the skill level of the development team, the size of the development team,
  13. 13. Page 13 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting the development tools, the development methodology or paradigm,These factors strongly vary from one organization or project to the next.2.7- Development efforts cost figuresAn important aspect of project management responsibilities is planning and measuring cost expenditures throughout the project lifecycle. Such an activity is performed differently from one organization to the next therefore it may take many forms. In this project,development efforts have been classified in three generic groups that remain valid regardless of organization specific practices andpolicies. More specifically cost figures are related to both the production rates previously introduced and the mean time required toproduce design specifications and the mean time required to implement software code.The following variables are introduced: MDN: mean cost of producing one unit of design specifications. MDW: mean cost of producing one unit of design specifications. MCN: mean cost of implementing one unit of software code. MCW: mean cost of implementing one unit of software code.The cost of producing DN amount of design specifications is: MDN x DN = MDN x CDN x TDN [E14]The cost of producing DW amount of design specifications is: MDW x DW = MDW x CDW x TDW [E15]The cost of implementing CN amount of software code is: MCN x CN = MCN x CCN x TCN [E16]The cost of implementing CW amount of software code is: MCW x CW = MCW x CCW x TCW [E17]The values of the above variables depend on various factors such as: the skill level of the development team, the size of the development team, the development tools,
  14. 14. Page 14 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting the development methodology or paradigm,These factors strongly vary from one organization or project to the next.2.8- Development effort reuseAs mentioned before, among the three types of development efforts, one does not really require any development effort. It is expressedby the variables DO and CO. The DO design specifications and CO implemented software code are either directly taken from aprevious software development effort within the same organization or are bought from a third party vendor. In this section we focus onthe process by which DO and CO are taken from a previous software development effort conducted by the same organization.Using the three types of development efforts mentioned in this project, the reusable portion of any software can be expressed asfollow: KDO x DO for reuse of the “non-effort consuming” part of design specifications. KCO x CO for reuse of the “non-effort consuming” part of implemented software code. KDN x DN for reuse of the “design for reuse” part of design specifications. KCN x CN for reuse of the “implemented for reuse” part of implemented software code.Where KDO, KCO, KDN and KCN are adjustment factors that express what fraction of the software project under consideration istransferred to another given software project. KDO, KCO, KDN and KCN are by definition between 0 % and 100%.The magnitudes of KDO, KCO, KDN and KCN depend mainly on: The similarity between the initial software and the new one to develop in terms of problem domain, requirements set, programming language, notations, machine architecture, development tool, and standards. The effective reuse of software components in terms of occurrences of identical components across several projects.Reusable software components could be source code libraries or software design frameworks with multiple classes, interfaces, orfunctions. The important fact is that whatever the sources of reuse, the reused components become for the current project its set of“Non-effort consuming” design specifications and implemented software code. The more “non-effort consuming” designspecifications and implemented software code used, the less “effort-consuming” design specifications and implemented software codeneeded to complete the project. The ultimate outcome yields a substantial reduction of the software custom development time andeffort.
  15. 15. Page 15 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting3- Using software development effort models in managerial decisionsSoftware development management teams would like to find ways to answer the following questions regarding given softwareprojects: What amount of software features will likely be produced? What amount of reusable features will likely be produced? What amount of non-reusable features will likely be produced? How long will it take to complete the production of the software features? How much time needs to be dedicated the production of reusable features? How much time needs to be dedicated to the production of non-reusable features? How much will the development effort cost? What will be the cost of the reusable features produced? What will be the cost of the non-reusable features produced?While knowing the following development capability parameters: Mean cost of producing 1 unit of reusable design specification Mean cost of producing 1 unit of non-reusable design specification Mean cost of implementing 1 unit of reusable software code Mean cost of implementing 1 unit of non-reusable software code Mean production rate of 1 unit of reusable design specification Mean production rate of 1 unit of non-reusable design specification Mean implementation rate of 1 unit of reusable software code Mean implementation rate of 1 unit of non-reusable software codeAnd knowing the following project constraints: The expected amount of design specifications The expected amount of implemented software code The expected development effort budgeted cost The planned time for producing design specifications The planned time for implementing software code
  16. 16. Page 16 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting3.1 Optimal single software project management policies.In this section we will relate the individual software policies mentioned previously under section 2.1 to quantitative expressions thatcapture their essence.Software Feature SetThe software feature set consists of D amount of design specifications and C amount of implemented software code.Using the three types of development efforts, the following relations are presented:D = DO + DN + DW[E20]C = CO + CN + CW[E21]By substituting [E10] to [E13] in [E20] and [E21]:D = DO + (CDN x TDN) + (CDW x TDW) [E30.1]C = CO + (CCN x TCN) + (CCW x TCW) [E30.2]Software development effort costDevelopment effort costs are incurred as design specifications are produced and software code is implemented. The development costbudgeted figures are MD for design specifications production and MC for software code implementation. The following relationstranslate the policy that relates budgeted costs to incurred costs:MD > (MDN x DN) + (MDW x DW)Which is the same as:MD > (MDN x CDN x TDN) + (MDW x CDW x TDW) [E31.1]MC > (MCN x CN) + (MCW x CW)Which is the same as:MC > (MCN x CCN x TCN) + (MCW x CCW x TCW) [E31.2]
  17. 17. Page 17 of 25 Copyright © 2010-2013 Pragmatic Cohesion ConsultingSoftware delivery scheduleLet TD and TC be respectively the planned time for producing design specifications and the planned time for implementing softwarecode.The actual time spent for the production of design specifications and the actual time spent for the implementation of software codemust be equal to the planned development times. The following equations capture these relations:TD = TDN + TDW[E32.1]TC = TCN + TCW[E32.2]Software degree of reusabilityFrom a global perspective, the development team is composed of software architects and software abstractionists who are in charge ofproducing the software architecture and detail design specifications. Application engineers are responsible for implementing softwarecode. Within each one of these groups two skills level are defined. The first one is capable of producing reusable features and thesecond one is mainly capable of producing non-reusable features. The strategic interest of reusable features has been presented severaltimes in this presentation. It is then desirable that as many as possible software features exhibit this property. This fact can betranslated by the following equations:TDN > 0 [E33.1] and CDN > 0[E34.1]TCN > 0 [E33.2] and CCN > 0[E34.2]3.2 Optimal set of single software project management policies.From the previous discussion, it appears that several software management objectives compete to be totally fulfilled. Softwaredevelopment managers are faced with the challenge of finding the optimal balance of these objectives. A useful approach is toprioritize these objectives according to what the Decision Maker judges as the most important objectives to achieve. These objectivesare listed below with no implications about their relative importance.
  18. 18. Page 18 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting Objective or Management Policy Object Deliver software that has as many requirements met as Software features set possible Do not exceed budgeted costs Software development effort cost Deliver software on schedule Software delivery schedule Produce software with as many reusable features as possible Software degree of reusability.Once the objectives have been ranked, the optimal balance of fulfilled objectives can be derived by several techniques. Next wepresent how Goal Programming fits well the problem at hand.Two similar goal programming problems can be formulated: the first one is about design specifications while the other one is aboutimplemented software code. The formulation that follows addresses implemented software code.Optimize: the achievement of ranked project development objectivesGiven: the following aspiration levels:  C – CO : Amount of software code to implement  MC : Software code implementation budgeted cost  TC : Software code implementation planned timeAnd given:the following production parameters:  CCN : Mean production rate of reusable software code  CCW : Mean production rate of non-reusable software code  MCN : Mean cost of producing one unit of reusable software code  MCW : Mean cost of producing one unit of non-reusable software codeThe following relations constitute the Goal Programming constraints: (CCN x TCN) + (CCW x TCW) = C - CO [E30.2] (MCN x CCN x TCN) + (MCW x CCW x TCW) < MC [E31.2] TCN + TCW = TC [E32.2] TCN > 0 [E33.2]
  19. 19. Page 19 of 25 Copyright © 2010-2013 Pragmatic Cohesion ConsultingThe decision variables in the above relations are TCN and TCW. Each relation has an aspiration level and a direction of preferencethat are summarized below with additional goal programming deviation variables. Right Hand Side Deviation Variables Aspiration Achievement function Goal Level (CCN x TCN) + (CCW x TCW) dC-, dC+ C - CO minimize deviation: (dC- + dC+)(MCN x CCN x TCN) + (MCW x CCW x TCW) dM-, dM+ MC minimize over achievement :(dM+) TCN + TCW dT-, dT+ TC minimize deviation : (dT- + dT+) TCN dN-, dN+ 0 minimize under achievement: (dN-)The achievement function of the goal programming problem expresses the optimal balance in achieving the various stated goals. It canbe expressed as any of the following: Minimize the weighted sum of the goal deviations where weights are representative of priorities among the objectives. Minimize some function of the goal deviations. Minimize the worst deviation of the goal deviations. Lexicographic minimization of an ordered set of goal deviations.3.3 Post optimal analysis of a set of single software project managementThe solution to the goal programming problem described previously provides the following information with respect to the prioritiesdefined by the decision maker: How long it takes to complete the production of the software features How much time is dedicated the production of reusable software features How much time is dedicated to the production of non-reusable software features What amount of software features have been produced What amount of reusable software features has been produced What amount of non-reusable software features has been produced How much it costs to produce the software features What is the total cost of the reusable software features What is the total cost of the non-reusable software features
  20. 20. Page 20 of 25 Copyright © 2010-2013 Pragmatic Cohesion ConsultingPost optimality analysis is useful to respond to the following questions: How do modifications in the stated priorities influence the optimal solution proposed? This question addresses concerns such as: if cost becomes the biggest priority instead of feature set, is the solution still valid? Within what range can the aspiration levels on desired feature set, cost, and schedule vary without making proposed solution non- feasible?3.4 Multiple related software projects management.Next, is presented an analysis procedure that allows planning a series of successive software projects. The three types of developmentefforts (non-effort consuming, effort consuming with reusable property, effort consuming with non-reusable property) and the 2 typesdevelopment activities (producing design specifications, implementing software code) previously presented are taken into account.For each project under consideration, the following software development effort parameters are defined: D: the amount of design specifications C: the amount of software code to implement TD: the planned time for producing design specifications TC: the planned time for implementing software code TDN: the mean time needed to produce DN amount of reusable design specifications TDW: the mean time needed to produce DW amount of non reusable design specifications TCN: the mean time needed to implement CN amount of reusable software code TCW: the mean time needed to implement CW amount of non-reusable software code M: the development effort budgeted cost MD : budgeted cost to produce D amount of design specifications MC : budgeted cost to implement C amount of software code MDN : mean cost of producing 1 unit of reusable design specification MDW : mean cost of producing 1 unit non-reusable design specification MCN : mean cost of implementing 1 unit of reusable software code
  21. 21. Page 21 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting MCW: mean cost of implementing 1 unit of non-reusable software code CDN: the mean production rate of 1 unit of reusable design specification CDW: the mean production rate of 1 unit of non-reusable design specification CCN: the mean implementation rate of 1unit of reusable software code CCW: the mean implementation rate of 1unit of non-reusable software code KDN: the reusability degree of DN amount of reusable design specifications KCN: the reusability degree of CN amount of reusable software codeThe strategies presented address a set of N successive related software projects. The organization objective is to develop the Nthproject with the following forecasted characteristics: Dn amount of design specifications Cn amount of software code TDn planned time for producing design specifications TCn planned time for implementing software code Mn budgeted development cost PD0n proportion of non-effort consuming design specifications PC0n proportion of non-effort consuming implemented software codeThe strategic variables are PD0n and PC0n since they reflect the portion of the software project that does not need to consumedevelopment efforts therefore they are strong indicators of development effort cost savings. A natural procedure is to graduallyincrease PD0 and PF0 from one project to the next by making sure that each software produces features that possess an effectivedegree of reusability for subsequent projects.Next we present two planning approaches that respond to two kinds of planning strategies. Both approaches try to match future projectcharacteristics to development effort capability.3.4.1 First approach –marketing strategy
  22. 22. Page 22 of 25 Copyright © 2010-2013 Pragmatic Cohesion ConsultingThe first strategy is a marketing one and it consists of finding the kind of software projects that match the current profile of theorganization software development capability.This approach can be modeled as follow using the software development effort parameters previously introduced:Given the following characteristics of the Nth project: Dn amount of design specifications Cn amount of implemented software code TDn planned time for producing Dn amount of design specifications TCn planned time for implementing Cn amount of software code Mn budgeted development cost PD0n proportion of non-effort consuming design specifications PC0n proportion of non-effort consuming implemented software codeAnd given the forecasted values for each one of the (N-1) projects: MDN : mean cost of producing 1unit of reusable design specification MDW : mean cost of producing 1 unit of non-reusable design specification MCN : mean cost of implementing 1unit of reusable software code MCW: mean cost of implementing 1unit of non-reusable software code CDN: the mean production rate of 1 unit of reusable design specification CDW: the mean production rate of 1 unit if non-reusable design specification CCN: the mean implementation rate of 1unit of reusable software code CCW: the mean implementation rate of 1 unit if non-reusable software codeFind the values of the following parameters for each one of the (N-1) projects:-D: the amount of design specifications-C: the amount of software code to implement-M: the development effort budgeted cost-TD: the planned time for producing design specifications-TC: the planned time for implementing software code-KDN: the reusability degree of DN amount of reusable design specifications-KCN: the reusability degree of CCN amount of reusable implemented software code.
  23. 23. Page 23 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting3.4.2 Second approach – workforce development strategyThe second strategy is a workforce development one that defines the organization software development capability that will match agiven set of future software projects.Given the following characteristics of the Nth project: Dn amount of design specifications Cn amount of implemented software code TDn planned time for producing Dn amount of design specifications TCn planned time for implementing Cn amount of software code Mn budgeted development cost PD0n proportion of non-effort consuming design specifications PC0n proportion of non-effort consuming implemented software codeAnd the forested values for each one of the (N-1) projects: D: amount of design specifications C: amount of software code to implement M: the development effort budgeted cost TD: the planned time for producing design specifications TC: the planned time for implementing software codeFind the values of the following parameters for each one of the (N-1) projects:-MDN: mean cost of producing 1unit of reusable design specification-MDW: mean cost of producing 1unit of non-reusable design specification-MCN: mean cost of implementing 1 unit of reusable software code-MCW: mean cost of implementing 1 unit of non-reusable software code-CDN: the mean production rate of 1unit of reusable design specification-CDW: the mean production rate of 1unit of non-reusable design specification-CCN: the mean implementation rate of 1unit if reusable software code-CCW: the mean implementation rate of 1unit of non-reusable software code
  24. 24. Page 24 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting-KDN: the reusability degree of DN amount of reusable design specifications-KCN: the reusability degree of CN amount of reusable software code
  25. 25. Page 25 of 25 Copyright © 2010-2013 Pragmatic Cohesion ConsultingReferences:-Bohem B.W. and Papaccio P.N. 1988, Understanding and controlling software cost, IEEE Transactions on Software Engineering14(10)-Booch G. (1998), Object Solutions: Managing the Object-Oriented Project, Addison-Wesley, Menlo Park, CA-Rico D.F (2004), ROI of software process improvement: Metrics for project managers and software engineers, J. Ross, Boca Raton,FL.-Rosenberg D., Stephens M., and Collins-Cope M. (2005), Agile Development with ICONIX Process-People, Process andPragmatism, Apress.-Royce W. (1998), Software Project Management a Unified Framework, Reading, MA-Sage A. P. (1991) Decision Support Systems Engineering. Wiley Series in Systems Engineering, New York.-Yourdon E. (1997), Death march: The complete software developer’s guide to surviving “Mission Impossible” projects, Prentice Hall,Upper Saddle River, NJ.

×