A software requirement is a property which must be exhibited by software developed or adapted to solve a particular problem. The problem may be to automate part of a task of someone who will use the software, to support the business processes of the
organization that has commissioned the software, to correct shortcomings of existing software, to control a device, and many more. The functioning of users,business processes, and devices is typically complex. By extension, therefore,the equirements on particular software are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.
An essential property of all software requirements is that they be verifiable. It may be difficult or costly to verify certain software requirements. For example, verification of the throughput requirement on the call center may necessitate the development of simulation software. Both the software requirements and software quality personnel must ensure that the requirements can be verified within the available resource constraints.
Product and Process Requirements
A distinction can be drawn between product parameters and process parameters. Product parameters are requirements on software to be developed (for example,
“The software shall verify that a student meets all prerequisites before he or she registers for a course.”).A process parameter is essentially a constraint on the
development of the software (for example, “The software shall be written in Ada.”). These are sometimes known as process requirements.
Some software requirements generate implicit process requirements. The choice of verification technique is one example. Another might be the use of particularly
rigorous analysis techniques (such as formal specification methods) to reduce faults which can lead to inadequate reliability. Process requirements may also be imposed
directly by the development organization, their customer,or a third party such as a safety regulator [Kot00; Som97].
Functional and Nonfunctional Requirements
Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as
capabilities.Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.
They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability
requirements, or one of many other types of software requirements. These topics are also discussed in the Software Quality KA. [Kot00; Som97].
Emergent Properties
Some requirements represent emergent properties of software—that is, requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system,
information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture. [Som05]
Thursday, November 13, 2008
Tuesday, November 11, 2008
Software Testing Activities
Introduction: Testing is an essential activity in software engineering.In the simplest terms, it amounts to observing the execution of a software system to validate whether it behaves as intended and identify potential malfunctions. Testing can consume fifty percent, or even more, of the development costs [1], and a recent detailed survey in the United States [2] quantifies the high economic impacts of an inadequate software testing infrastructure.
Software testing is a broad term encompassing a wide spectrum of different activities, from the testing of a small piece of code by the developer (unit testing), to the customer validation of a large information system (acceptance testing), to the monitoring at run-time of a network-centric service-oriented application. In the various stages, the test cases could be devised aiming at different objectives, such as exposing deviations from user’s requirements, or assessing the conformance to a standard specification, or evaluating robustness to stressful load conditions or to malicious inputs, or measuring given attributes, such as performance or usability, or estimating the operational reliability, and so on. Besides, the testing activity could be carried on accordingto a controlled formal procedure, requiring rigorous planning and documentation, or rather informally and ad hoc (exploratory testing).
Some Common Observations:
WHY: why is it that we make the observations? This question concerns the test objective, e.g.: are we looking for faults? or, do we need to decide whether the product can be released? or rather do we need to evaluate the usability of the User Interface?
HOW: which sample do we observe, and how do we choose it? This is the problem of test selection, which can be done ad hoc, at random, or in systematic way by applying some algorithmic or statistical technique. It has inspired much research, which is understandable not only because it is intellectually attractive, but also because how the test cases are selected -the test criterion- greatly influences test efficacy.
HOW MUCH: how big of a sample? Dual to the question of how do we pick the sample observations (test selection),is that of how many of them do we take (test adequacy,or stopping rule). Coverage analysis or reliability measures constitute two “classical” approaches to answer such question.
WHAT: what is it that we execute? Given the (possibly composite) system under test, we can observe its execution either taking it as a whole, or focusing only on a part of it, which can be more or less big (unit test, component/subsystem test, integration test), more or less defined:
this aspect gives rise to the various levels of testing, and to the necessary scaffolding to permit test execution of a part of a larger system.
WHERE: where do we perform the observation?
Strictly related to what do we execute, is the question whether this is done in house, in a simulated environment or in the target final context. This question assumes the highest relevance when it comes to the testing of embedded systems.
WHEN: when is it in the product lifecycle that we perform the observations? The conventional argument is that the earliest, the most convenient, since the cost of fault removal increases as the lifecycle proceeds. But, some observations,in particular those that depend on the surrounding
context, cannot always be anticipated in the laboratory, and we cannot carry on any meaningful observation until the system is deployed and in operation.
These questions provide a very simple and intuitive characterization schema of software testing activities, that can help in organizing the roadmap for future research challenges.
References:
[1]B. Beizer. Software Testing Techniques (2nd ed.). Van Nostrand
Reinhold Co., New York, NY, USA, 1990.
[2]NIST. The economic impacts of inadequate
infrastructure for software testing,http://www.nist.gov/director/prog-ofc/report02-3.pdf.
[3]Antonia Bertolino,"Software Testing Research: Achievements, Challenges, Dreams",ACM,2007.
Software testing is a broad term encompassing a wide spectrum of different activities, from the testing of a small piece of code by the developer (unit testing), to the customer validation of a large information system (acceptance testing), to the monitoring at run-time of a network-centric service-oriented application. In the various stages, the test cases could be devised aiming at different objectives, such as exposing deviations from user’s requirements, or assessing the conformance to a standard specification, or evaluating robustness to stressful load conditions or to malicious inputs, or measuring given attributes, such as performance or usability, or estimating the operational reliability, and so on. Besides, the testing activity could be carried on accordingto a controlled formal procedure, requiring rigorous planning and documentation, or rather informally and ad hoc (exploratory testing).
Some Common Observations:
WHY: why is it that we make the observations? This question concerns the test objective, e.g.: are we looking for faults? or, do we need to decide whether the product can be released? or rather do we need to evaluate the usability of the User Interface?
HOW: which sample do we observe, and how do we choose it? This is the problem of test selection, which can be done ad hoc, at random, or in systematic way by applying some algorithmic or statistical technique. It has inspired much research, which is understandable not only because it is intellectually attractive, but also because how the test cases are selected -the test criterion- greatly influences test efficacy.
HOW MUCH: how big of a sample? Dual to the question of how do we pick the sample observations (test selection),is that of how many of them do we take (test adequacy,or stopping rule). Coverage analysis or reliability measures constitute two “classical” approaches to answer such question.
WHAT: what is it that we execute? Given the (possibly composite) system under test, we can observe its execution either taking it as a whole, or focusing only on a part of it, which can be more or less big (unit test, component/subsystem test, integration test), more or less defined:
this aspect gives rise to the various levels of testing, and to the necessary scaffolding to permit test execution of a part of a larger system.
WHERE: where do we perform the observation?
Strictly related to what do we execute, is the question whether this is done in house, in a simulated environment or in the target final context. This question assumes the highest relevance when it comes to the testing of embedded systems.
WHEN: when is it in the product lifecycle that we perform the observations? The conventional argument is that the earliest, the most convenient, since the cost of fault removal increases as the lifecycle proceeds. But, some observations,in particular those that depend on the surrounding
context, cannot always be anticipated in the laboratory, and we cannot carry on any meaningful observation until the system is deployed and in operation.
These questions provide a very simple and intuitive characterization schema of software testing activities, that can help in organizing the roadmap for future research challenges.
References:
[1]B. Beizer. Software Testing Techniques (2nd ed.). Van Nostrand
Reinhold Co., New York, NY, USA, 1990.
[2]NIST. The economic impacts of inadequate
infrastructure for software testing,http://www.nist.gov/director/prog-ofc/report02-3.pdf.
[3]Antonia Bertolino,"Software Testing Research: Achievements, Challenges, Dreams",ACM,2007.
Tuesday, November 4, 2008
Challenges in Citizen Centric E-Government
The promise of E-Government (and its more recent spin-offs of E-Democracy,E-Participation, E-Procurement, and a range of other “E-‘s”) is to engage citizenry in government in a citizen-centered manner, but also to develop quality government services and delivery systems that are efficient and effective. Citizen-centered
E-Government suggests that governments will provide services and resources tailored to the actual service and resource needs of users, including citizens, residents, government employees, and others. Efficient and effective E-Government suggests that
governments will gain economies of scale, reduce costs, and provide technology-enabled user services. There have been many predictions that E-Government will revolutionize democratic participation or that it will revolutionize the delivery of government services in one of these ways for a number of years citizen-oriented E-Government requires a number of planning and design processes to be successful and that using such an approach may, in fact, increase the costs of providing E-Government services. Users of e-government comprise a number of groups—citizens employing government information and services; residents and immigrants seeking
information about their new country; government employees using e-government in their job functions; people in other countries wishing to know more about a nation; and on and on. Typically, “top-down” or systems-based E-Government design
fails to adequately consider citizen information needs. Thus, the degree to which both goals of improved user-oriented EGovernment and more efficient (reduced costs of) government services can be accomplished simultaneously through EGovernment
may be problematic. There are number of questions to answer before initiating a comprehensine EGovernment framework:
User Level Questions:
1)What are user expectations from E-Government services
and resources?
2) What are the issues and barriers users encounter when
using E-Government services and resources?
3) What factors facilitate and enhance do users experiences
with E-Government services and resources?
Government Level Questions:
Questions with federal and state government personnel
responsible for E-Government services and resources included:
1) What are the primary drivers of the development and
implementation of E-Government services and resources?
2) To what extent are citizen needs and expectations
included in the design and implementation of EGovernment
services and resources?
3) How are citizen identified expectations and desires in EGovernment
services and resources incorporated into the
overall design and continual enhancement of E-Government
services and resources?
REFERENCES:
Paul,John,C, Charles,R. "Citizen Centric E-Government Services:Cost,Benefits and Research Needs"ACM,2007.
Millard, J. (2006). User attitudes to e-government citizen services
in Europe. International Journal of Electronic Government
Research, 2(2), 49-58.
Noveck, B. S. (2003). Designing deliberative democracy in
cyberspace: The role of the cyber-lawyer. Boston University
Journal of Science and Technology, 9, 1-91.
E-Government suggests that governments will provide services and resources tailored to the actual service and resource needs of users, including citizens, residents, government employees, and others. Efficient and effective E-Government suggests that
governments will gain economies of scale, reduce costs, and provide technology-enabled user services. There have been many predictions that E-Government will revolutionize democratic participation or that it will revolutionize the delivery of government services in one of these ways for a number of years citizen-oriented E-Government requires a number of planning and design processes to be successful and that using such an approach may, in fact, increase the costs of providing E-Government services. Users of e-government comprise a number of groups—citizens employing government information and services; residents and immigrants seeking
information about their new country; government employees using e-government in their job functions; people in other countries wishing to know more about a nation; and on and on. Typically, “top-down” or systems-based E-Government design
fails to adequately consider citizen information needs. Thus, the degree to which both goals of improved user-oriented EGovernment and more efficient (reduced costs of) government services can be accomplished simultaneously through EGovernment
may be problematic. There are number of questions to answer before initiating a comprehensine EGovernment framework:
User Level Questions:
1)What are user expectations from E-Government services
and resources?
2) What are the issues and barriers users encounter when
using E-Government services and resources?
3) What factors facilitate and enhance do users experiences
with E-Government services and resources?
Government Level Questions:
Questions with federal and state government personnel
responsible for E-Government services and resources included:
1) What are the primary drivers of the development and
implementation of E-Government services and resources?
2) To what extent are citizen needs and expectations
included in the design and implementation of EGovernment
services and resources?
3) How are citizen identified expectations and desires in EGovernment
services and resources incorporated into the
overall design and continual enhancement of E-Government
services and resources?
REFERENCES:
Paul,John,C, Charles,R. "Citizen Centric E-Government Services:Cost,Benefits and Research Needs"ACM,2007.
Millard, J. (2006). User attitudes to e-government citizen services
in Europe. International Journal of Electronic Government
Research, 2(2), 49-58.
Noveck, B. S. (2003). Designing deliberative democracy in
cyberspace: The role of the cyber-lawyer. Boston University
Journal of Science and Technology, 9, 1-91.
Model Driven Software Development
Model Driven Development (MDD) is an emerging paradigm for software development that specifies programs in domainspecific languages (DSLs), encourages greater degrees of automation, and exploits standards . MDD uses models to represent a program. A model is written in a DSL that specifies particular details of a program’s design. As an individual model captures limited information, a program is often specified by several different models. A model can be derived from other models by transformations, and program synthesis is the process of transforming high-level models into executables (which are also models).
Feature Oriented Programming (FOP) is a paradigm for software product lines where programs are synthesized by
composing features . A feature is an increment of program functionality, and is implemented by refinements that extend existing artifacts and that add new artifacts (code,makefiles, documentation, etc.). When features are composed,consistent artifacts that define a program are synthesized.A tenet of FOP is the use of algebraic techniques to specify and manipulate program designs.
Feature Oriented Model Driven Development (FOMDD) is a blend of FOP and MDD. Models can be refined by composing
features (a.k.a. endogenous transformations that map models expressed in the same DSL , and can be derived from other models (a.k.a. exogenous transformations that map models written in different DSLs .
Monday, November 3, 2008
Introduction to Requirement Elicitation
Elicitation. Requirements elicitation comprises activities that enable the understanding of the goals, objectives, and motives for building a proposed software system.
Elicitation also involves identifying the requirements that the resulting system must satisfy in order to achieve these goals.The requirements to be elicited may range from modifications to well-understood problems and systems (e.g., software
upgrades), to hazy understandings of new problems being automated, to relatively unconstrained requirements that are open to innovation2 (e.g., mass-market software).
As such, most of the research in elicitation focuses on technologies for improving the precision, accuracy, and variety of the requirements details:
• Techniques for identifying stakeholders help to ensure that everyone who may be affected by the software is consulted during elicitation.
• Analogical techniques, like metaphors and personas, help stakeholders to consider more deeply and be more precise about their requirements.
• Contextual and personal RE techniques analyze stakeholders’ requirements with respect to a particular context, environment, and perhaps individual
user, to help ensure that the eventual system is fit for use in that environment.
• Techniques for inventing requirements, like brainstorming and creativity workshops , help to identify nonessential requirements that make the final product
more appealing.
• Feedback techniques use models, model animations , simulation, and storyboards
to elicit positive and negative feedback on early representations of the proposed system.
Models can be used during elicitation to help catalyze discussion and to explore and learn about the stakeholders’needs. Such exploratory models, like cases, scenarios,enterprise models, and some policy and goal models, tend to be informal and intuitive, to facilitate early feedback from stakeholders. They tend also to be inexpensive to create and maintain, so that specifiers can keep them up-to-date as the requirements evolve.
Elicitation also involves identifying the requirements that the resulting system must satisfy in order to achieve these goals.The requirements to be elicited may range from modifications to well-understood problems and systems (e.g., software
upgrades), to hazy understandings of new problems being automated, to relatively unconstrained requirements that are open to innovation2 (e.g., mass-market software).
As such, most of the research in elicitation focuses on technologies for improving the precision, accuracy, and variety of the requirements details:
• Techniques for identifying stakeholders help to ensure that everyone who may be affected by the software is consulted during elicitation.
• Analogical techniques, like metaphors and personas, help stakeholders to consider more deeply and be more precise about their requirements.
• Contextual and personal RE techniques analyze stakeholders’ requirements with respect to a particular context, environment, and perhaps individual
user, to help ensure that the eventual system is fit for use in that environment.
• Techniques for inventing requirements, like brainstorming and creativity workshops , help to identify nonessential requirements that make the final product
more appealing.
• Feedback techniques use models, model animations , simulation, and storyboards
to elicit positive and negative feedback on early representations of the proposed system.
Models can be used during elicitation to help catalyze discussion and to explore and learn about the stakeholders’needs. Such exploratory models, like cases, scenarios,enterprise models, and some policy and goal models, tend to be informal and intuitive, to facilitate early feedback from stakeholders. They tend also to be inexpensive to create and maintain, so that specifiers can keep them up-to-date as the requirements evolve.
AGILE METHODOLOGIES
Agile methodologies have been in the software industry for quite some years and this has resulted in the proliferation of a number of approaches to this new way of developing software. All agile approaches have following common principles.
• Improved customer satisfaction
• Adopting to changing requirements
• Frequently delivering software
• Close collaboration of business people and developers
Traditional software development models are linear in nature with distinct categories e.g. waterfall model has five distinct stages, while agile methodologies are iterative in nature. In most traditional development methodologies a particular stage can’t be started until the previous stage has been finished. While in agile approaches iterative and short releases go through all the development phases in very short time. Agile methods dynamic quality techniques like test-driven development have an edge on static driven quality techniques e.g. inspection and technical reviews.
Traditional methodologies can’t handle projects with high volatile requirements due to their liner nature of processes while agile methods handle such projects with simple planning, short iterations, earlier releases and continuous customer engagement. Traditional methods are more effective for large and more complex projects, while in recent years the information systems and emergence of e-business applications with volatile and ambiguous requirements has changed the scene that traditional methodologies can’t satisfy the needs of these projects.
All Agile methods assign value to:
1.Individual and interactions over processes and tools.
2.Working software over comprehensive documentation.
3.Customer collaboration over contract negotiation
4.Responding to change over following a plan.
The most important practice of agile is ‘on-site’ customer concept i.e. continuous customer engagement, while in traditional approaches customer involvement is mainly in early phases of project. The CHAOS report showed the critical importance of customer involvement. Customer involvement was found to be the number one reason for project success, while the lack of user involvement was the main reason given for projects that ran into difficulties. Agile methods promise to increase customer satisfaction, to produce high quality software and to accelerate development times.
Agile methods are fundamentally iterative. They do not replicate the traditional linear sequence of requirements, design, implementation, and test; rather they repeat this sequence again and again.
In the projects where time to market is critical and a lot of unknown and ambiguous requirement exists, agile methods and especially eXtreme programming [2, 3, 4, 5] are proving to be a successful strategy because it handles unstable requirements throughout the development lifecycle and delivers products in shorter timeframes and under budget constraints. In this case study we compare agile-oriented projects and projects developed by employing traditional methodologies. We analyze and measure industry data and report their relative impact on certain quality parameters.
REFERENCES:
B.Boehm and R.Turner, Balancing Agility and Discipline-A Guide for the Perplexed, Addison-Wesley, 2003.
J.Highsmith, Agile Project Management, Creating innovative products, Addison-Wesley, 2004.
D, J.Anderson, Agile Management for Software Engineering, Applying the Theory of Constraints for Business Results, Prentice Hall, 2003.
• Improved customer satisfaction
• Adopting to changing requirements
• Frequently delivering software
• Close collaboration of business people and developers
Traditional software development models are linear in nature with distinct categories e.g. waterfall model has five distinct stages, while agile methodologies are iterative in nature. In most traditional development methodologies a particular stage can’t be started until the previous stage has been finished. While in agile approaches iterative and short releases go through all the development phases in very short time. Agile methods dynamic quality techniques like test-driven development have an edge on static driven quality techniques e.g. inspection and technical reviews.
Traditional methodologies can’t handle projects with high volatile requirements due to their liner nature of processes while agile methods handle such projects with simple planning, short iterations, earlier releases and continuous customer engagement. Traditional methods are more effective for large and more complex projects, while in recent years the information systems and emergence of e-business applications with volatile and ambiguous requirements has changed the scene that traditional methodologies can’t satisfy the needs of these projects.
All Agile methods assign value to:
1.Individual and interactions over processes and tools.
2.Working software over comprehensive documentation.
3.Customer collaboration over contract negotiation
4.Responding to change over following a plan.
The most important practice of agile is ‘on-site’ customer concept i.e. continuous customer engagement, while in traditional approaches customer involvement is mainly in early phases of project. The CHAOS report showed the critical importance of customer involvement. Customer involvement was found to be the number one reason for project success, while the lack of user involvement was the main reason given for projects that ran into difficulties. Agile methods promise to increase customer satisfaction, to produce high quality software and to accelerate development times.
Agile methods are fundamentally iterative. They do not replicate the traditional linear sequence of requirements, design, implementation, and test; rather they repeat this sequence again and again.
In the projects where time to market is critical and a lot of unknown and ambiguous requirement exists, agile methods and especially eXtreme programming [2, 3, 4, 5] are proving to be a successful strategy because it handles unstable requirements throughout the development lifecycle and delivers products in shorter timeframes and under budget constraints. In this case study we compare agile-oriented projects and projects developed by employing traditional methodologies. We analyze and measure industry data and report their relative impact on certain quality parameters.
REFERENCES:
B.Boehm and R.Turner, Balancing Agility and Discipline-A Guide for the Perplexed, Addison-Wesley, 2003.
J.Highsmith, Agile Project Management, Creating innovative products, Addison-Wesley, 2004.
D, J.Anderson, Agile Management for Software Engineering, Applying the Theory of Constraints for Business Results, Prentice Hall, 2003.
Monday, August 11, 2008
AN OVERVIEW OF EXISTING QUALITY MODELS
There are numerous quality management practices available in industry. These practices can be categorized into five general groups.
1.Total quality management
2.Management quality standards interpreted for software intensive systems
3.Specific IT quality standards with process capability determination features
4.National level quality award criteria
5.World-class standards
Within these groups there are a number of IT industries specific standards (BS15000 ,ISO9000-3 , international models (ISO 9001-2000, CMMI ) and quality awards (Baldrige , EFQM ).
Different models, standards and awards emphasize different activities. Which model fits to a specific industry or organization depends on the organization strategic objectives and the business in which the organization is operating. For example Michael Tingey in his book Malcolm Baldridge and SEI/CMM for Software (1997) studied the standards and models for the types of activities emphasized, he discovered that Malcom Baldrige model puts a large emphasis on improving and then on planning. In comparison, the ISO9001 standard puts its highest emphasis on managing and then on implementing. The SEI SW-CMM model is the reverse of ISO9001—its largest emphasis is on implementing and then managing.
1.Total quality management
2.Management quality standards interpreted for software intensive systems
3.Specific IT quality standards with process capability determination features
4.National level quality award criteria
5.World-class standards
Within these groups there are a number of IT industries specific standards (BS15000 ,ISO9000-3 , international models (ISO 9001-2000, CMMI ) and quality awards (Baldrige , EFQM ).
Different models, standards and awards emphasize different activities. Which model fits to a specific industry or organization depends on the organization strategic objectives and the business in which the organization is operating. For example Michael Tingey in his book Malcolm Baldridge and SEI/CMM for Software (1997) studied the standards and models for the types of activities emphasized, he discovered that Malcom Baldrige model puts a large emphasis on improving and then on planning. In comparison, the ISO9001 standard puts its highest emphasis on managing and then on implementing. The SEI SW-CMM model is the reverse of ISO9001—its largest emphasis is on implementing and then managing.
Friday, August 8, 2008
Process Improvement Issues in Small Software Industry
For the last one decade there is a multitude of literature being written on software process improvement (SPI) . SPI with conventional models like CMM/CMMI, ISO-15504 promises huge potential benefits for organizations. Some of the Process Improvement (PI) potential benefits are :
* Increased productivity
* Reduced cost
* Reduced defects
* Reduced rework
* Improved time to market with satisfied customers
However, most of the studies on SPI are centered on large organizations. Software process improvement (SPI) requires a considerable investment in terms of cost, time training, commitment from top management and good communication flow.
Traditional SPI approaches and assessment methods are costly for small organizations. The models underlying traditional SPI assessment and implementation programs such as CMM CMMI ISO90001 , SPICE and BOOTSTRAP were designed for large organizations. Process Improvement (PI) initiatives with such conventional models have difficulties and challenges when we implement them on small organizations. Hanna describes some major limitations of the existing SPI reference models. ISO/IEC 12207 and ISO/IEC15504 have undergone significant modifications during the last three years. So their adoption cost and suitability is not clear for small organizations. ISO 9001-2000 is not specific for software industry and it is not a set of processes as are CMM/CMMI. Another weakness of ISO 9001 is its generalizability. ISO-9001 is an abstract and sparse document that can be applied to any category of business. So it is very difficult to apply ISO-9001 standards to a software organization. Elif, Onur, Oguz and Billur also describe few limitations of ISO 9001 implementation in small organizations. Among major challenges of implementing ISO 9001, on small organizations are
* Lack of guidance of ISO 9001 standards on where to start and how to install quality system elements,
* Lack of action knowledge about process improvement principles
ISO9001 is lacking in maturity stages like CMM/CMMI. ISO-9001 organization choose to have only two statue, ‘satisfies’ or ‘not satisfied’ while CMM/CMMI have five distinct maturity stages for an organization to compare its process maturity with the levels below or above.
Although CMM/CMMI is a set of industry best practices but its implementation cost is a major drawback. For example, CMM based process assessment cost lies between +/- $25,000 and duration is +/- 8 months while its overall implementation cost is well over $100,000 which is disproportionate to the available resources of small organizations. In another case study it was estimated that CMMI based gap analysis would cost $20,000 for five days and SCAMPI certification audit would cost $30000 for eight days for total of $50,000 .
Another important limitation, of implying CMM/CMMI in small environment, is that many of the practices are not applicable (or not have clear benefit) to small organizations. One peculiar phenomenon of small organizations is their role multiplicities, one person has multiple roles. These overlapping roles make the implementation, of SPI reference models, very difficult for small structure organizations.
* Increased productivity
* Reduced cost
* Reduced defects
* Reduced rework
* Improved time to market with satisfied customers
However, most of the studies on SPI are centered on large organizations. Software process improvement (SPI) requires a considerable investment in terms of cost, time training, commitment from top management and good communication flow.
Traditional SPI approaches and assessment methods are costly for small organizations. The models underlying traditional SPI assessment and implementation programs such as CMM CMMI ISO90001 , SPICE and BOOTSTRAP were designed for large organizations. Process Improvement (PI) initiatives with such conventional models have difficulties and challenges when we implement them on small organizations. Hanna describes some major limitations of the existing SPI reference models. ISO/IEC 12207 and ISO/IEC15504 have undergone significant modifications during the last three years. So their adoption cost and suitability is not clear for small organizations. ISO 9001-2000 is not specific for software industry and it is not a set of processes as are CMM/CMMI. Another weakness of ISO 9001 is its generalizability. ISO-9001 is an abstract and sparse document that can be applied to any category of business. So it is very difficult to apply ISO-9001 standards to a software organization. Elif, Onur, Oguz and Billur also describe few limitations of ISO 9001 implementation in small organizations. Among major challenges of implementing ISO 9001, on small organizations are
* Lack of guidance of ISO 9001 standards on where to start and how to install quality system elements,
* Lack of action knowledge about process improvement principles
ISO9001 is lacking in maturity stages like CMM/CMMI. ISO-9001 organization choose to have only two statue, ‘satisfies’ or ‘not satisfied’ while CMM/CMMI have five distinct maturity stages for an organization to compare its process maturity with the levels below or above.
Although CMM/CMMI is a set of industry best practices but its implementation cost is a major drawback. For example, CMM based process assessment cost lies between +/- $25,000 and duration is +/- 8 months while its overall implementation cost is well over $100,000 which is disproportionate to the available resources of small organizations. In another case study it was estimated that CMMI based gap analysis would cost $20,000 for five days and SCAMPI certification audit would cost $30000 for eight days for total of $50,000 .
Another important limitation, of implying CMM/CMMI in small environment, is that many of the practices are not applicable (or not have clear benefit) to small organizations. One peculiar phenomenon of small organizations is their role multiplicities, one person has multiple roles. These overlapping roles make the implementation, of SPI reference models, very difficult for small structure organizations.
Sunday, August 3, 2008
software effort estimation
Formal estimation models There are many different types of formal effort estimation models available.
Effort estimation models may be based on sophisticated analyses and dependencies between effort and other variables in sets of previously completed projects and result in, e.g., formulae of the following type: Effort = a Sizeb * Adjustment factor
Examples of well-known estimation models are these:
COCOMO . In COCOMO, the use of effort of a typical project is assumed to follow a pre-defined formula regarding the relationship between Size and Effort. To account for differences in productivity, it is possible to make a number of (to some extent subjective) adjustments to the “nominal” effort estimate, e.g., the estimate can be adjusted for level of reuse.
Use Case Point Estimation (UCP) .The method takes as main input a software specification described through “Use Cases”, which is part of the notation of UML and is similar to the use of “Function Point”-based estimation models. Each use case is counted and weighted, and is adjusted for technical parameters. An expected productivity rate is provided as input. Current research in this area is typically directed at making better models, e.g., investigating when, how and how much local calibration of the models that are beneficial.
Model-based effort estimation processes may rely on expert judgment-based input. Hence, model output may also be biased towards over-optimism or be affected by the presence of irrelevant information. Further, inconsistency in effort estimates may be a problem, despite the use of models.
Effort Estimation Error Measurement:
Measuring estimation error is a fundamental activity in software estimation research. It is the basis of many activities, such as analysing whether or not an organization has an estimation problem, evaluating estimation methods, and identifying causes of estimation error. Software projects differ in size and, for aggregation purposes, most measures of estimation error are consequently based on relative estimation error. The most commonly used measure of estimation error is the Magnitude of Relative Error (MRE).
MRE is calculated by the following formula:
MRE= MOD(ACTUAL EFFORT-ESTIMATED EFFORT)/ACTUAL EFFORT.
REFERENCES:
1 .J. Li and G. Ruhe, "A comparative study of attribute weighting heuristics for effort estimation by analogy," proc. Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering, pp. 66-74, 2006.
2. C. Lokan and E. Mendes, "Cross-company and Single-company Effort Models using the ISBSG Database: a Further Replicated Study," proc. Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering, pp. 75-84, 2006.
3. S. Makridakis, S. C. Wheelwright, and R. J. Hyndman, Forecasting Methods and Applications, 3rd ed. New York: John Wiley & Sons, Inc., 1998.
Effort estimation models may be based on sophisticated analyses and dependencies between effort and other variables in sets of previously completed projects and result in, e.g., formulae of the following type: Effort = a Sizeb * Adjustment factor
Examples of well-known estimation models are these:
COCOMO . In COCOMO, the use of effort of a typical project is assumed to follow a pre-defined formula regarding the relationship between Size and Effort. To account for differences in productivity, it is possible to make a number of (to some extent subjective) adjustments to the “nominal” effort estimate, e.g., the estimate can be adjusted for level of reuse.
Use Case Point Estimation (UCP) .The method takes as main input a software specification described through “Use Cases”, which is part of the notation of UML and is similar to the use of “Function Point”-based estimation models. Each use case is counted and weighted, and is adjusted for technical parameters. An expected productivity rate is provided as input. Current research in this area is typically directed at making better models, e.g., investigating when, how and how much local calibration of the models that are beneficial.
Model-based effort estimation processes may rely on expert judgment-based input. Hence, model output may also be biased towards over-optimism or be affected by the presence of irrelevant information. Further, inconsistency in effort estimates may be a problem, despite the use of models.
Effort Estimation Error Measurement:
Measuring estimation error is a fundamental activity in software estimation research. It is the basis of many activities, such as analysing whether or not an organization has an estimation problem, evaluating estimation methods, and identifying causes of estimation error. Software projects differ in size and, for aggregation purposes, most measures of estimation error are consequently based on relative estimation error. The most commonly used measure of estimation error is the Magnitude of Relative Error (MRE).
MRE is calculated by the following formula:
MRE= MOD(ACTUAL EFFORT-ESTIMATED EFFORT)/ACTUAL EFFORT.
REFERENCES:
1 .J. Li and G. Ruhe, "A comparative study of attribute weighting heuristics for effort estimation by analogy," proc. Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering, pp. 66-74, 2006.
2. C. Lokan and E. Mendes, "Cross-company and Single-company Effort Models using the ISBSG Database: a Further Replicated Study," proc. Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering, pp. 75-84, 2006.
3. S. Makridakis, S. C. Wheelwright, and R. J. Hyndman, Forecasting Methods and Applications, 3rd ed. New York: John Wiley & Sons, Inc., 1998.
Monday, July 7, 2008
NEW MARKETING CONCEPTS
1. You see a gorgeous girl at a party. You go up to her and say:
"I am very rich. Marry me!" - That's Direct Marketing
2. You're at a party with a bunch of friends and see a gorgeous
girl. One of your friends goes up to her and pointing at you says:
He's very rich. Marry him." - That's Advertising
3. You see a gorgeous girl at a party. You go up to her and get
her telephone number. The next day, you call and say:
"Hi, I'm very rich. Marry me." - That's Telemarketing
4. You're at a party and see gorgeous girl. You get up and
Straighten your tie, you walk up to her and pour her a drink, you open
the door (of the car)for her, Pick up her bag after she drops it, offer
her ride and then say:" By the way, I'm rich. Will you marry me?" -
That's Public Relations
5. You're at a party and see gorgeous girl. She walks up to you
and says:" You are very rich! Can you marry! me?" - That's Brand
Recognition
6. You see a gorgeous girl at a party. You go up to her and say:
"I am very rich. Marry me!" She gives you a nice hard slap on your face.
- That's Customer Feedback
7. You see a gorgeous girl at a party. You go up to her and say:
"I am very rich. Marry me!" And she introduces you to her husband. -
That's demand and supply gap
8. You see a gorgeous girl at a party. You go up to her and
before you say anything, another person come and tell her: "I'm rich.
Will you marry me?" and she goes with him - That's competition eating
into your market share
9. You see a gorgeous girl at a party. You go up to her and
before you say: "I'm rich, Marry me!" your wife arrives. - That's
restriction for entering new markets
Subscribe to:
Posts (Atom)