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.
Subscribe to:
Posts (Atom)