Wednesday, May 3, 2017
Monday, March 15, 2010
World Consumer Rights Day
Today, the Consumer Rights day is being celebrating all over the world. The theme of this year Consumer Rights day is 'Our Money Our Rights' is very strong as it shows that the consumer has a right to spend his money according to his own will.
In Pakistan, the consumer is left at the mercy of shopkeepers and manufacturers. If some consumers demand something according to his right, he faces numerous hurdles.
Many of the difficulties which consumers experience arise from the lack of understanding and knowledge of how to behave as consumers. The only practical solution to the problem is to educate consumers about their duties and rights.
Many of educated people even don't know that consumer courts are established in every big cities of Pakistan. If consumer has some complaint about the shopkeeper about his/her goods/services, the only thing he/she should do is to file his/her case on plain paper and submit it to the court. There is no fee for this.
In Pakistan, the consumer is left at the mercy of shopkeepers and manufacturers. If some consumers demand something according to his right, he faces numerous hurdles.
Many of the difficulties which consumers experience arise from the lack of understanding and knowledge of how to behave as consumers. The only practical solution to the problem is to educate consumers about their duties and rights.
Many of educated people even don't know that consumer courts are established in every big cities of Pakistan. If consumer has some complaint about the shopkeeper about his/her goods/services, the only thing he/she should do is to file his/her case on plain paper and submit it to the court. There is no fee for this.
Leaders are always at the front.
As a Leader/Manager you are expected to lead from the front. And it’s very much true about your arrival or departure time in the office. One can afford slip ups during normal working days. But if you and your team have planned to work on an off day then IT’S ABSOLUTELY vital that you are there with your team. Your team will forgive you for occasional late arrivals and early departures but even the most loyal team will not forgive you if you come late or go early on off days working in the office. Trust me it will put your team off. They will feel like they have been betrayed even though they don’t discuss this publicly or among their peers but deep inside their hearts and minds it will stay like a bomb waiting for the right conditions to explode.
Job Satisfaction: How much
People often talk about job satisfaction. There seems to be another job/position somewhere else in this world which is better than the one you are currently working with and if you manage to get hold onto that job, another job/position pops up and you find yourself in the very same situation. It seems like a never ending cycle searching for job satisfaction.
How to avoid this…. well one needs to consider that every job is satisfying provided you think like that. Every job has problems and probably there is no job in this world which is problem free. The problem category might vary but problems never vanish. So one needs to be optimistic about the way a person approaches his/her job.
How to avoid this…. well one needs to consider that every job is satisfying provided you think like that. Every job has problems and probably there is no job in this world which is problem free. The problem category might vary but problems never vanish. So one needs to be optimistic about the way a person approaches his/her job.
Wednesday, February 17, 2010
PM Dinner with CJ
Finally the drama is over. The PM gate-crashed the dinner party of CJ on Tuesday evening, and their cordial huddle did away with the stupid obstinacy hitherto displayed by the Govt.The govt. reeling from the popular legitimacy for its illegitimate stance, finally realized that if it didn't swallow its own pride, then the snowballing crisis might well end up consuming it. Finally the govt. stepped back from its disastrous precipice just in time.
Thursday, November 13, 2008
Software Engineering Requirements-Part1
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]
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]
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.
Subscribe to:
Posts (Atom)