Loading ...
Sorry, an error occurred while loading the content.

request to fill a xp project questionnaire

Expand Messages
  • K.Vivekanandan
    Dear members, I am doing research (ph.d ) in pondicherry university india. In the field of extreme programming. I am collecting data from the completed
    Message 1 of 1 , Sep 15 9:47 PM
    • 0 Attachment
      Dear members,
      I am doing research (ph.d ) in pondicherry university india. In the
      field of extreme programming. I am collecting data from the
      completed extreme programming(Xp) projects. I request you to provide
      the project data (atleast one project data) in the questionnaire
      attached below. The questionnaire is lengthy but most of the
      questions (other than first seven questions) are all multiple
      choice questions. The data will be kept confidential. Unless it is
      explicitly required by you, I will not disclose your company name
      anywhere. The data will be used to build a cost model only and not
      for comparing performance between companies. For any clarification
      please mail to kvivek27@... or kvivek27@...
      Thanking you,
      Expecting favourable reply,
      K.Vivekanandan


      ---------------------------------------------------------------------
      ---
      -----------------------------
      Please send the filled-in questionnaire to kvivek27@... or
      kvivek27@...

      The data is collected at the project level. So please fill the
      separate questionnaire for each of the Xp project.

      At the end of the questionnaire major activities in each of the
      extreme programming practices are given.

      The questions 1 to 8 are adopted from COCOMO II data collection
      questionnaire and from model manual of COCOMO II (The parameters
      are
      kept as it is only the presentation differs from the original
      OCOMO
      II questionnaire.)
      Ref: http://sunset.usc.edu/research/COCOMOII/cocomo_main.html#data

      PROJECT QUESTIONAIRE
      (Please answer the following) :
      1.Project Identification Number or Name: ( If it is to be kept very
      confidential, you can give a dummy project identification number)


      2.Organization name and address: (Please give only your organization
      name and address. Client name and addresses are not necessary)



      3.Actual duration of the project, in number of calendar months:
      (From
      planning game to final release of the product)


      Actual Duration of the project: ------------------------ months.


      4.Total Effort in person months (including the software developers
      time (planning game, design, code, test, integration), project
      management time, administrative support time and project support
      personnel time e.g configuration management and quality assurance)


      Total Effort = --------------------------- Person months

      5.Size of software that was developed. /****IMPORTANT: Fill in any
      one one of the following from (a) to (c):***/

      (a) Give the number of source line of the code (SLOC) and also
      please specify the method /tool you employed to count the number of
      lines of the code:

      (b) Give the number function points and also specify the language
      you used for developing the code.


      (c) Any other size measure and also specify the method you
      employed to arrive at the size measure.



      6.In the above size measure how much percentage is adopted/reused
      from the other sources(libraries, other projects or from the same
      projects ). /***IMPORTANT *****Please fill in any one of the
      following from (a) to (d)./

      (a) If significant amount of the code has been adopted or reused
      from the other projects, please enter the percentage of the code
      adopted /reused.

      (b) If no significant amount of the code has been adopted/reused
      please enter Yes here:

      (c) Have not kept track of the size of the adopted code please enter
      Yes here:

      (d) If you don't know please enter Yes here:


      7.The percentage of code breakage:This is an estimate of how much
      the requirements have changed over the life time of the
      project. /***** IMPORTANT**********/Please fill in any one of the
      following from (a) to
      (c)

      Example: It is the percentage of the code thrown away due to
      requirements volatility. For example a project which delivers 100
      units
      (FUNCTION POINT/ANY OTHER SIZE MEASURE) of code but discards
      additional 20 units worth code , would have a breakage of value
      20.
      Fill any one of the following

      (a)If significant amount of code breakage then enter the code
      breakage value as indicated above.


      (b)If no significant code breakage enter Yes below:


      (c)Have not kept track of the code breakage. Then enter X


      (8) For each of the cost factor given below, please select one out
      of the following six ratings: VERY LOW, LOW, NOMINAL, HIGH, VERY
      HIGH, EXTRA HIGH by entering x or X near by it. Some of the cost
      factors do not contain all the six ratings.

      8(1). Precedentedness(PREC): If the product is similar to several
      that have been developed.

      (a)thoroughlyunprecedented (VERYLOW)
      (b)Largely unprecedented (LOW)
      (c)Somewhat unprecedented (NOMINAL)
      (d)Generally familiar (HIGH)
      (e)Largely familiar (very high)
      (f)Thoroughly familiar (EXTRA HIGH)
      (G) I DON'T KNOW

      8(2) Required Software Reliability (RELY): If the developed
      software is installed and the failiure of the software leads to ...
      (choose any one of the following)
      (a)Slightly inconvenience to the users (VERY LOW)
      (b) easily recoverable losses to the users. (LOW)
      (c) Moderate easily recoverable losses to users (NOMINAL)
      (d)High financial loss to the users (HIGH)
      (f) Risk to human life. (VERY HIGH)
      (g) I DON'T KNOW


      8(3). Data Size (DATA):

      (a) <1000 bytes LOW
      (b) 1001 to 10,000bytes NOMINAL
      (c) 10,001 to 100,000bytes HIGH
      (d) Greater than 100,000 bytes VERY HIGH
      (e) DON'T KNOW

      8(4). Develop for Reuse (RUSE):This cost driver accounts for the
      additional effort needed to construct components intended for reuse
      on the current or future projects.
      (a) None (LOW)
      (b) Across the project (NOMINAL)
      (c) Across program (HIGH)
      (d) Acros Product Line (VERY HIGH)
      (e) Across multiple product lines (EXTRA HIGH)
      (f) I DON'T KNOW

      8(5). Documentation match to life-cycle needs (DOCU): Your
      organization requires the documentation for the project that is ...

      (a) Many life cycle needs uncovered VERY LOW
      (b) Some life cycle needs uncovered LOW
      (c) Right sized to lifecycle needs NOMINAL
      (d) Excessive for lifecycle needs HIGH
      (e) Very excessive for life cycle needs VERY HIGH
      (f) I DON'T KNOW


      8.(6) Execution Time Constraint (TIME): When developed software is
      installed, it consumes ..... (

      (a)50% use ofavailable execution time (NOMINAL)
      (b) 70% (HIGH)
      (c) 85% (VERY HIGH)
      (d) 95% (EXTRA HIGH)
      (e) I DON'T KNOW

      8(7) Main Storage Constraint (STOR): When the developed, software is
      installed, it consumes ---
      (a) 50% use of availablestorage (NOMINAL)
      (b) 70% (HIGH)
      (c) 85% (VERY HIGH)
      (d) 95% (EXTRA HIGH)
      (e) I DON'T KNOW

      8(8) Team Cohesion (TEAM):
      (a) Very difficult interactions (VERY LOW)
      (b)Some difficult interactions (LOW)
      (c) Basically co-operative interactions (NOMINAL)
      (d) Largely cooperative interactions (HIGH)
      (e) Highly cooperative (VERY HIGH)
      (f) Seamless interaction (EXTRA HIGH)
      (g) I DON'T KNOW

      8(9) Analyst Capability (ACAP)/ Onsite Customer Capability(OCCAP):

      (a) 15th Percentile (VERY LOW)
      (b) 35h percentile (LOW)
      (c) 55th percentile (NOMINAL)
      (d) 75th percentile (HIGH)
      (e) 90 percentile (VERY HIGH)
      (g) I DON'T KNOW

      8(10).Programmer Capability (PCAP): Evaluation should be based on
      the capability of the programmers as a team rather than as
      individuals.

      (a) 15th Percentile (VERY LOW)
      (b) 35h percentile (LOW)
      (c) 55th percentile (NOMINAL)
      (d) 75th percentile (HIGH)
      (e) 90 th percentile (VERY HIGH)
      (g) I DON'T KNOW

      8(11). Personnel Turnover. This denotes number of personnel goes
      out and or comes in to the project.
      (a) 48% per year (VERY LOW)
      (b) 24%/ per year (LOW)
      (c) 12% per year (NOMINAL)
      (d) 6% per year (HIGH)
      (e) 3% per year (VERY HIGH)
      (g) I DON'T KNOW

      8(12). Applications Experience (AEXP): This rating is dependent on
      the level of applications experience of the project team developing
      the software system or subsystem.
      (a)2 months (VERY LOW)
      (b) 6 months (LOW)
      (c) 1 year (NOMINAL)
      (d) 3 years (HIGH)
      (e) 6 years (VERY HIGH)
      (g) I DON'T KNOW

      8(13). Platform Experience (PEXP): The average platform experience
      for the development team.
      (a)2 months (VERY LOW)
      (b) 6 months (LOW)
      (c) 1 year (NOMINAL)
      (d) 3 years (HIGH)
      (e) 6 years (VERY HIGH)
      (f) I DON'T KNOW

      8(14) Language and Tool Experience (LTEX) (including Xp tools) :
      This is a measure of the level of programming language and software
      tool experience of the project team developing the software system
      or subsystem.

      (a)2months (VERY LOW)
      (b)6 months (LOW)
      (c)1 year (NOMINAL)
      (d)3 years (HIGH)
      (e)6 years (VERY HIGH)
      (f) I DON'T KNOW

      8(15). Development Flexibility (FLEX): This cost driver captures the
      amount of constraints the product has to meet. The more flexible the
      requirements, schedules, interfaces, etc., the higher the rating.

      (a) Rigorous VERY LOW
      (b) occasional relaxation LOW
      (c) some relaxation NOMINAL
      (d) general conformity HIGH
      (e) someconformity VERY HIGH
      (f) general goals EXTRA HIGH
      (g) DON'T KNOW

      8(16). Use of Software Tools (TOOL) including the Xp Tools:

      (a) Edit, code, debug VERY LOW
      (b) Simple, front end back end CASE little integration LOW
      (c) Basic lifecycle tools moderately integrated NOMINAL
      (d)Strong, mature life cycle tools, moderately integrated HIGH
      (e) Strong mature, proactive life cycle tools, well integrated
      with processes, methods reuse VERY HIGH
      (f) I DON'T KNOW

      8.(17). Platform Volatility (PVOL): "Platform" used here to mean the
      complex of hardware and software (OS, DBMS, under lying hardware
      and network etc.,) the software product calls on to perform its
      tasks. (How frequently the changes occur in the platform) This
      rating ranges from low, where there is a major change every 12
      months, to very high, where there is a major change every two weeks.

      (a) Major changes Changes occurs to the platform every 12 months
      (LOW)
      (b) Major changes occurs to the platform every 6 months; (NOMINAL)
      (c) Major changes occurs to platform every two months (HIGH)
      (d) Major changes occurs every two weeks (VERY HIGH)
      (e)I DON'T KNOW


      8(18) Required Development Schedule (SCED): Required Scheduling:
      This rating measures the schedule constraint imposed on the project
      team developing the software. The ratings are defined in terms of
      the percentage of schedule stretch-out or acceleration with respect
      to a nominal schedule for a project requiring a given amount of
      effort.

      (a) 75% of nominal (VERY LOW)
      (b) 85% (LOW)
      (c) 100% (NOMINAL)
      (d) 130% (HIGH)
      (e) 160% (VERY HIGH)
      (f) I DON'T KNOW

      8(19).Architecture / Risk Resolution (RESL) through conventional
      means or through Xp practices. :

      (a) Little 20% VERY LOW
      (b) Some (40%) LOW
      (c) Often (60%) NOMINAL
      (d) Generally(75%) HIGH
      (e) Mostly(90%) VERY HIGH
      (f) Full(100%) EXTRA HIGH
      (g) I DON'T KNOW

      8(20). Process Maturity Process Maturity (PMAT).

      (a) CMM Level 1 (lower level) equivalent
      (b) CMM level 1 (upper level) Equivalent
      (c) CMM Level 2 equivalent
      (d) CMM Level 3 equivalent
      (e) CMM Level 4 equivalent
      (f) CMM Level 5 equivalent
      (g) No Response


      8.21 Multi Site Development
      (I) . SITE Location:
      (a) International (VERY LOW)
      (b) Multi-city and Multi-company (LOW)
      (c) Multi-city or Multi-company (NOMINAL)
      (d) Same city or metro. area (HIGH)
      (e) Same building or complex (VERY HIGH)
      (f) Fully collocated (EXTRA HIGH)
      (g) I DON'T KNOW

      (II) SITE communications (If you select fully collocated don't
      answer the follwing question)
      (a) Some phone,mail (VERY LOW)
      (b) Individual phone, FAX (LOW)
      (c) Narrowband email (NOMINAL)
      (d) Wideband electronic communication. (HIGH)
      (e) Wideband elect. comm, occasional video conf. (VERY HIGH)
      (f) Interactive multimedia (EXTRA HIGH)

      8(22). Product Complexity (CPLX): Please put X in any one of the
      column
      by condsidering complexity involved in control operations, device
      dependent operations, data management operations and user interface
      management operations. (a)VERY LOW
      (b)LOW
      (c)NOMINAL
      (d)HIGH
      (e)VERY HIGH
      (f)EXTRA HIGH
      (g)I DON'T KNOW


      (9) Questionnaire related to software development Practices
      The rating for each of the 12 practices are given as:
      . Almost always (over 90% of the time) when a practice is
      adopted as recommended
      . Frequently (about 60 to 90% of the time) When the
      practices are adopted but some times the practices are omitted due
      to difficult circumstances
      . About Half (about 40 to60% of the time)When the practices is
      followed as recommended
      . Occasionally (about 10 to 40% of the time) when the goals are
      achieved about half of the time
      . Rarely if ever( less than 10% of the time)when the practices
      are some times adopted but less often
      . Don't know When you are uncertain about how to respond for
      the
      particular practice
      Please enter your option by entering X or x near by the option you
      want to select

      9(1). Planning Game:
      The requirements are written as user stories.. The effort and risk
      are estimated for each of the story. The stories for first
      iteration and release date were planned. The cost implications of
      using various technology options are analyzed. Roles and team
      organization are decided. The order of story development with an
      iteration (doing risky items first can be instigated). Story cards
      are prepared and managed. In the case of difficult stories, the
      spikes are created to understand the potential of the solution.
      Customer determines the scope(the stories for release and stories
      for the iteration)

      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(2).Continuous Testing:The unit tests are performed before and
      after integration and re-factoring. As soon as the code for a unit
      is completed the unit test are done. The unit test cod eare written
      even before the writing the code for unit.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(3) Pair programming: Two persons are allotted only one terminal.
      Together the pair design, write test code, code, and re-factor if
      necessary. Pair programmers are interchanged. The working space for
      pair programmers are arranged comfortably.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(4). Re-factoring: The quality of the code is improved, without
      affecting the functionality of the code, by ensuring the clarity
      of the code, no duplication, no long classes and the other no bad
      code smells.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(5) Simple Design: No big front up design. Design using CRC cards
      only. Allowing the design to evolve to fit the changing
      requirements. Keep classes which do only one job at first. Everybody
      understood the system metaphor.The critical design decision are
      taken during coding only. The design get further improved in
      refactoring
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(6) Collective code ownership: Every body owns all the code meaning
      every body is responsible for it. The developers ensure that the
      unit tests must run before and after each integration.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(7) Continuous Integration: Integrate the code several times a day
      after they get unit tests run for the system to run. Build process
      is stream lined. One or more machine(s) are reserved for integration.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(8) Onsite customer: Availability of the customer as a part of the
      development team for the discussions and planning game activites.
      Customer writes stories and acceptance tests with the help of
      development team.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(9) Small releases: Small but frequent releases of the are
      happened and feedback is obtained. The obtained feedback is
      included in its planning for the next release.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(10).40 hour /week: The sustainable work hours for company and the
      developer is decided and strictly followed. i.e. overtime is not
      allowed.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(11). Coding standards: Everybody agrees on coding standard and
      the team sticks to it. The coding standard guidelines are
      sufficient to communicate the code clearly.

      (a)Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      9(12) System Metaphor: Everybody understand how the components of
      the system fits together. Spikes are created and tested. Everybody
      clearly understand the system metaphor.
      (a) Almost always
      (b) Frequently
      (c) About half
      (d) Occasionally
      (e) Rarely if ever
      (f) Not Followed

      --------------------------------------- Thank you--------------------
      -------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.