Featured Posts

Concept of Project Metrics and the common sources and type of risks in software development projects

Project Metrics :  A software team can use software project metrics to adapt project workflow and technical activities.

  • Project metrics are used to avoid development schedule delays, to mitigate potential risks, and to assess product quality on an on going basis.
  • Every project should measure its inputs (resources), outputs (deliverable), and results (effectiveness of deliverable).
Project metrics enable project manager to :

  1. Assess status of ongoing project
  2. Track potential risks
  3. Uncover problem before they go critical
  4. Adjust work flow or tasks
  5. Evaluate the project team's ability to control quality of software work products
Project metrics tell you whether the project is meeting its goals.

Goal of Project metrics :

  • To improve product quality and development team productivity concerned with productivity and quality measures.
  • Measures of SW development output as function of effort and time.
  • Measures of usability

Difference between Size-oriented and Function-oriented metrics

Size-oriented Metrics :  It attempts to quantify software projects by using the size of the project to normalise other quality measures.

  • Possible data to collect
  • Number of lines of code
  • Number of person-months to complete
  • Cost of the project
  • Number of pages of documentation
  • Number of errors corrected before release
  • Number of bugs found post release
Function-Oriented Metrics :  It attempts to measure the functionality of a software system.

  • Use a unit of measure called function point
  • Some possible function points
  • Internal data structures
  • External data structures
  • User inputs
  • User outputs
  • Transformations
  • Transitions

(b) The common sources and type of risks in software development projects

      There are 10 primary sources of Software Risks.
  1. Personal Shortfalls : Staffing with top talent, job matching, team building, key personnel agreements, cross training.
  2. Unrealistic schedules and budgets :  Detailed multi-source cost and schedule estimation, design to cost, incremental development, software reuse, requirements scrubbing.
  3. Developing the wrong functions and properties :  Organisation analysis, mission analysis, operations-concept formulation, user surveys and user participation, prototyping, early user's manuals, off-nominal performance analysis, quality-factor analysis.
  4. Developing the wrong user interface :  Prototyping scenarios, task analysis, user participation.
  5. Gold-plating :  Requirements scrubbing, prototyping, cost-benefit analysis, designing hiding, incremental development.
  6. Continuing stream of requirements changes : High chance thresholds, information reference checking, and compatibility analysis.
  7. Shortfalls in externally furnished components :  Bench-marking, inspections, reference checking and compatibility analysis.
  8. Shortfalls in externally performed tasks : Reference checking, pre-award audits, award-free contracts, competitive design or prototyping, team-building.
  9. Real-time performance shortfalls :  Simulation, bench-marking, modelling, prototyping, instrumentation, tuning.
  10. Straining computer science capabilities :  Technical analysis, cost-benefit analysis, prototyping, reference checking.
Types of Risks :  Risks  can be categorized as follows :
  • Project risks : Risks that threaten the project.
  • Product risks : Risks that threaten the quality of the software developed.
  • Business risks : Risks that threaten the development (or client) organization.
Software development projects are subject to many risks, including :
  • Poorly defined requirements
  • Client requirements changes
  • Poor techniques for cost estimation
  • Rapid technological changes ( i.e a project can become obsolete before it is even competed)
  • Dependence on skills of individual developers
  • Extreme mobility of developers, etc.
     As a result, project managers must try to anticipate risks that could threaten the project or affect the schedule or the quality of the software developed.
      Strategies to deal with risks in software development projects :  Strategies to deal with risks in software development projects include the following activities :
  • Risk Planning
  • Risk mitigation
  • Risk Resolution
  • Risk Monitoring
(i) Risk Planning :  Risk planning is to strategies to deal with risk.  These strategies fall into three categories :
  1. Risk Avoidance
  2. Risk Minimization
  3. Risk Contingency Plans
(ii) Risk Mitigation : The risk mitigation is a plan that would reduce or eliminate the highest risks. The key question is : What should be done and who is responsible to eliminate or minimize the risk ? The mitigation plan include a description of the action that can be taken to mitigate the red rated risk and assigns a primary handler for the action.

(iii) Risk Resolution : When a risk has occurred, it has to be solved. Risk resolution is the execution of the plans for dealing with each risk. If the risk at the watch list, a plan of how to resolve the risk already had taken place. The project manager has to respond to the already chalked out plan of how to resolve the risk.

(iv) Risk Monitoring : Risk Monitoring is the continually reassessing of risk as the project proceeds and conditions changes. For example, successful completion of beta testing means that the risk of the client organization rejecting the system is minimal, while large turnover in development staff usually increases project and product risks.



IEEE Project Domain management in software engineering is distinct from traditional project deveopment in that software projects have a unique lifecycle process that requires multiple rounds of testing, updating, and faculty feedback. A IEEE Domain project Final Year Projects for CSE system development life cycle is essentially a phased project model that defines the organizational constraints of a large-scale systems project. The methods used in a IEEE DOmain Project systems development life cycle strategy Project Centers in Chennai For CSE provide clearly defined phases of work to plan, design, test, deploy, and maintain information systems.

This is enough for me. I want to write software that anyone can use, and virtually everyone who has an internet connected device with a screen can use apps written in JavaScript. JavaScript Training in Chennai JavaScript was used for little more than mouse hover animations and little calculations to make static websites feel more interactive. Let’s assume 90% of all websites using JavaScript use it in a trivial way. That still leaves 150 million substantial JavaScript Training in Chennai JavaScript applications.


Post a Comment


www.posthatke.com. Powered by Blogger.
Copyright © www.posthatke.com | Blogger Templates | Designed By posthatke.com