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).
- Assess status of ongoing project
- Track potential risks
- Uncover problem before they go critical
- Adjust work flow or tasks
- Evaluate the project team's ability to control quality of software work products
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
- 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.
- Personal Shortfalls : Staffing with top talent, job matching, team building, key personnel agreements, cross training.
- Unrealistic schedules and budgets : Detailed multi-source cost and schedule estimation, design to cost, incremental development, software reuse, requirements scrubbing.
- 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.
- Developing the wrong user interface : Prototyping scenarios, task analysis, user participation.
- Gold-plating : Requirements scrubbing, prototyping, cost-benefit analysis, designing hiding, incremental development.
- Continuing stream of requirements changes : High chance thresholds, information reference checking, and compatibility analysis.
- Shortfalls in externally furnished components : Bench-marking, inspections, reference checking and compatibility analysis.
- Shortfalls in externally performed tasks : Reference checking, pre-award audits, award-free contracts, competitive design or prototyping, team-building.
- Real-time performance shortfalls : Simulation, bench-marking, modelling, prototyping, instrumentation, tuning.
- Straining computer science capabilities : Technical analysis, cost-benefit analysis, prototyping, reference checking.
- 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.
- 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.
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
- Risk Avoidance
- Risk Minimization
- Risk Contingency Plans
(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.
Posts
1 comments:
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.
ReplyThis 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