http://swebokwiki.org/api.php?action=feedcontributions&user=Daniel+Robbins&feedformat=atomSWEBOK - User contributions [en]2024-03-28T09:53:40ZUser contributionsMediaWiki 1.25.1http://swebokwiki.org/index.php?title=User_talk:Yaron_Koren&diff=877User talk:Yaron Koren2017-01-18T16:32:51Z<p>Daniel Robbins: Welcome!</p>
<hr />
<div>'''Welcome to ''SWEBOK''!'''<br />
We hope you will contribute much and well.<br />
You will probably want to read the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents help pages].<br />
Again, welcome and have fun! [[User:Daniel Robbins|Daniel Robbins]] ([[User talk:Daniel Robbins|talk]]) 16:32, 18 January 2017 (UTC)</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=875Chapter 11: Software Engineering Professional Practice2015-08-29T15:52:54Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.<br />
<br />
==Communication Skills==<br />
<br />
It is vital that a software engineer communicate<br />
well, both orally and in reading and writing. Successful<br />
attainment of software requirements and<br />
deadlines depends on developing clear understanding<br />
between the software engineer and<br />
customers, supervisors, coworkers, and suppliers.<br />
Optimal problem solving is made possible<br />
through the ability to investigate, comprehend,<br />
and summarize information. Customer product<br />
acceptance and safe product usage depend on the<br />
provision of relevant training and documentation.<br />
It follows that the software engineer’s own career<br />
success is affected by the ability to consistently<br />
provide oral and written communication effectively<br />
and on time.<br />
<br />
===Reading, Understanding, and Summarizing===<br />
{{RightSection|{{referenceLink|number=5|parts=c33}}}}<br />
<br />
Software engineers are able to read and understand<br />
technical material. Technical material<br />
includes reference books, manuals, research<br />
papers, and program source code.<br />
<br />
Reading is not only a primary way of improving<br />
skills, but also a way of gathering information<br />
necessary for the completion of engineering<br />
goals. A software engineer sifts through accumulated<br />
information, filtering out the pieces that<br />
will be most helpful. Customers may request that<br />
a software engineer summarize the results of<br />
such information gathering for them, simplifying<br />
or explaining it so that they may make the final<br />
choice between competing solutions.<br />
<br />
Reading and comprehending source code is<br />
also a component of information gathering and<br />
problem solving. When modifying, extending, or rewriting software, it is critical to understand<br />
both its implementation directly derived from the<br />
presented code and its design, which must often<br />
be inferred.<br />
<br />
===Writing===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s5}}}}<br />
<br />
Software engineers are able to produce written<br />
products as required by customer requests or generally<br />
accepted practice. These written products<br />
may include source code, software project plans,<br />
software requirement documents, risk analyses,<br />
software design documents, software test plans,<br />
user manuals, technical reports and evaluations,<br />
justifications, diagrams and charts, and so forth.<br />
<br />
Writing clearly and concisely is very important<br />
because often it is the primary method of communication<br />
among relevant parties. In all cases,<br />
written software engineering products must be<br />
written so that they are accessible, understandable<br />
and relevant for their intended audience(s).<br />
<br />
===Team and Group Communication===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s6.8}} {{referenceLink|number=4|parts=c22s3}} {{referenceLink|number=5|parts=c27s1}} {{referenceLink|number=9|parts=c10s4}}}}<br />
<br />
Effective communication among team and group<br />
members is essential to a collaborative software<br />
engineering effort. Stakeholders must be consulted,<br />
decisions must be made, and plans must<br />
be generated. The greater the number of team<br />
and group members, the greater the need to<br />
communicate.<br />
<br />
The number of communication paths, however,<br />
grows quadratically with the addition of<br />
each team member. Further, team members<br />
are unlikely to communicate with anyone perceived<br />
to be removed from them by more than<br />
two degrees (levels). This problem can be more<br />
serious when software engineering endeavors or<br />
organizations are spread across national and continental<br />
borders.<br />
<br />
Some communication can be accomplished in<br />
writing. Software documentation is a common<br />
substitute for direct interaction. Email is another<br />
but, although it is useful, it is not always enough;<br />
also, if one sends too many messages, it becomes<br />
difficult to identify the important information.<br />
Increasingly, organizations are using enterprise collaboration tools to share information. In addition,<br />
the use of electronic information stores,<br />
accessible to all team members, for organizational<br />
policies, standards, common engineering<br />
procedures, and project-specific information, can<br />
be most beneficial.<br />
<br />
Some software engineering teams focus on<br />
face-to-face interaction and promote such interaction<br />
by office space arrangement. Although<br />
private offices improve individual productivity,<br />
colocating team members in physical or virtual<br />
forms and providing communal work areas is<br />
important to collaborative efforts.<br />
<br />
===Presentation Skills===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=4|parts=c22}} {{referenceLink|number=9|parts=c10s7–c10s8}}}}<br />
<br />
Software engineers rely on their presentation<br />
skills during software life cycle processes. For<br />
example, during the software requirements phase, software engineers may walk customers<br />
and teammates through software requirements<br />
and conduct formal requirements reviews (see<br />
Requirement Reviews in the Software Requirements<br />
KA). During and after software design,<br />
software construction, and software maintenance,<br />
software engineers lead reviews, product walkthroughs<br />
(see Review and Audits in the Software<br />
Quality KA), and training. All of these require the<br />
ability to present technical information to groups<br />
and solicit ideas or feedback.<br />
<br />
The software engineer’s ability to convey<br />
concepts effectively in a presentation therefore<br />
influences product acceptance, management,<br />
and customer support; it also influences the ability<br />
of stakeholders to comprehend and assist in<br />
the product effort. This knowledge needs to be<br />
archived in the form of slides, knowledge writeup,<br />
technical whitepapers, and any other material<br />
utilized for knowledge creation.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
Gerald M. Weinberg, ''The Psychology of Computer Programming'' [10].<br />
<br />
This was the first major book to address programming<br />
as an individual and team effort and became<br />
a classic in the field.<br />
<br />
Kinney and Lange, P.A., ''Intellectual Property Law for Business Lawyers'' [11].<br />
<br />
This book covers IP laws in the US. It not only<br />
talks about what the IP law is; it also explains<br />
why it looks the way it does.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=F. Bott et al.<br />
|article=<br />
|publication=Professional Issues in Software Engineering<br />
|edition=3rd ed.<br />
|publisher=Taylor & Francis<br />
|issue=<br />
|date=2000<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=Merriam-Webster’s Collegiate Dictionary<br />
|article=<br />
|publication=<br />
|edition=11th ed<br />
|publisher=<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=G. Voland<br />
|article=<br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=4<br />
|author=I. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=IEEE CS/ACM Joint Task Force onSoftware Engineering Ethics and Professional Practices<br />
|article=Software Engineering Code of Ethics and Professional Practice (Version 5.2)<br />
|publication=<br />
|edition=<br />
|publisher=<br />
|issue=<br />
|date=1999<br />
|part=<br />
|link=www.acm.org/serving/se/code.htm<br />
}}{{reference<br />
|number=7<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=8<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=9<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=10<br />
|author=G.M. Weinberg<br />
|article=<br />
|publication=The Psychology of Computer Programming: Silver Anniversary Edition<br />
|edition=<br />
|publisher=Dorset House<br />
|issue=<br />
|date=1998<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=Kinney and Lange, P.A.<br />
|article=<br />
|publication=Intellectual Property Law for Business Lawyers<br />
|edition=<br />
|publisher=Thomson West<br />
|issue=<br />
|date=2013<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=874Chapter 11: Software Engineering Professional Practice2015-08-29T15:52:12Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.<br />
<br />
==Communication Skills==<br />
<br />
It is vital that a software engineer communicate<br />
well, both orally and in reading and writing. Successful<br />
attainment of software requirements and<br />
deadlines depends on developing clear understanding<br />
between the software engineer and<br />
customers, supervisors, coworkers, and suppliers.<br />
Optimal problem solving is made possible<br />
through the ability to investigate, comprehend,<br />
and summarize information. Customer product<br />
acceptance and safe product usage depend on the<br />
provision of relevant training and documentation.<br />
It follows that the software engineer’s own career<br />
success is affected by the ability to consistently<br />
provide oral and written communication effectively<br />
and on time.<br />
<br />
===Reading, Understanding, and Summarizing===<br />
{{RightSection|{{referenceLink|number=5|parts=c33}}}}<br />
<br />
Software engineers are able to read and understand<br />
technical material. Technical material<br />
includes reference books, manuals, research<br />
papers, and program source code.<br />
<br />
Reading is not only a primary way of improving<br />
skills, but also a way of gathering information<br />
necessary for the completion of engineering<br />
goals. A software engineer sifts through accumulated<br />
information, filtering out the pieces that<br />
will be most helpful. Customers may request that<br />
a software engineer summarize the results of<br />
such information gathering for them, simplifying<br />
or explaining it so that they may make the final<br />
choice between competing solutions.<br />
<br />
Reading and comprehending source code is<br />
also a component of information gathering and<br />
problem solving. When modifying, extending, or rewriting software, it is critical to understand<br />
both its implementation directly derived from the<br />
presented code and its design, which must often<br />
be inferred.<br />
<br />
===Writing===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s5}}}}<br />
<br />
Software engineers are able to produce written<br />
products as required by customer requests or generally<br />
accepted practice. These written products<br />
may include source code, software project plans,<br />
software requirement documents, risk analyses,<br />
software design documents, software test plans,<br />
user manuals, technical reports and evaluations,<br />
justifications, diagrams and charts, and so forth.<br />
<br />
Writing clearly and concisely is very important<br />
because often it is the primary method of communication<br />
among relevant parties. In all cases,<br />
written software engineering products must be<br />
written so that they are accessible, understandable<br />
and relevant for their intended audience(s).<br />
<br />
===Team and Group Communication===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s6.8}} {{referenceLink|number=4|parts=c22s3}} {{referenceLink|number=5|parts=c27s1}} {{referenceLink|number=9|parts=c10s4}}}}<br />
<br />
Effective communication among team and group<br />
members is essential to a collaborative software<br />
engineering effort. Stakeholders must be consulted,<br />
decisions must be made, and plans must<br />
be generated. The greater the number of team<br />
and group members, the greater the need to<br />
communicate.<br />
<br />
The number of communication paths, however,<br />
grows quadratically with the addition of<br />
each team member. Further, team members<br />
are unlikely to communicate with anyone perceived<br />
to be removed from them by more than<br />
two degrees (levels). This problem can be more<br />
serious when software engineering endeavors or<br />
organizations are spread across national and continental<br />
borders.<br />
<br />
Some communication can be accomplished in<br />
writing. Software documentation is a common<br />
substitute for direct interaction. Email is another<br />
but, although it is useful, it is not always enough;<br />
also, if one sends too many messages, it becomes<br />
difficult to identify the important information.<br />
Increasingly, organizations are using enterprise collaboration tools to share information. In addition,<br />
the use of electronic information stores,<br />
accessible to all team members, for organizational<br />
policies, standards, common engineering<br />
procedures, and project-specific information, can<br />
be most beneficial.<br />
<br />
Some software engineering teams focus on<br />
face-to-face interaction and promote such interaction<br />
by office space arrangement. Although<br />
private offices improve individual productivity,<br />
colocating team members in physical or virtual<br />
forms and providing communal work areas is<br />
important to collaborative efforts.<br />
<br />
===Presentation Skills===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=4|parts=c22}} {{referenceLink|number=9|parts=c10s7–c10s8}}}}<br />
<br />
Software engineers rely on their presentation<br />
skills during software life cycle processes. For<br />
example, during the software requirements phase, software engineers may walk customers<br />
and teammates through software requirements<br />
and conduct formal requirements reviews (see<br />
Requirement Reviews in the Software Requirements<br />
KA). During and after software design,<br />
software construction, and software maintenance,<br />
software engineers lead reviews, product walkthroughs<br />
(see Review and Audits in the Software<br />
Quality KA), and training. All of these require the<br />
ability to present technical information to groups<br />
and solicit ideas or feedback.<br />
<br />
The software engineer’s ability to convey<br />
concepts effectively in a presentation therefore<br />
influences product acceptance, management,<br />
and customer support; it also influences the ability<br />
of stakeholders to comprehend and assist in<br />
the product effort. This knowledge needs to be<br />
archived in the form of slides, knowledge writeup,<br />
technical whitepapers, and any other material<br />
utilized for knowledge creation.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
Gerald M. Weinberg, ''The Psychology of Computer Programming'' [10].<br />
<br />
This was the first major book to address programming<br />
as an individual and team effort and became<br />
a classic in the field.<br />
<br />
Kinney and Lange, P.A., ''Intellectual Property Law for Business Lawyers'' [11].<br />
<br />
This book covers IP laws in the US. It not only<br />
talks about what the IP law is; it also explains<br />
why it looks the way it does.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=F. Bott et al.<br />
|article=<br />
|publication=Professional Issues in Software Engineering<br />
|edition=3rd ed.<br />
|publisher=Taylor & Francis<br />
|issue=<br />
|date=2000<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=Merriam-Webster’s Collegiate Dictionary<br />
|article=<br />
|publication=<br />
|edition=11th ed<br />
|publisher=<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=G. Voland<br />
|article=<br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=4<br />
|author=I. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=IEEE CS/ACM Joint Task Force onSoftware Engineering Ethics and Professional Practices<br />
|article=Software Engineering Code of Ethics and Professional Practice (Version 5.2)<br />
|publication=<br />
|edition=<br />
|publisher=<br />
|issue=<br />
|date=1999<br />
|part=<br />
|link=www.acm.org/serving/se/code.htm<br />
}}{{reference<br />
|number=7<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=8<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=9<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=10<br />
|author=G.M. Weinberg<br />
|article=<br />
|publication=The Psychology of Computer Programming: Silver Anniversary Edition<br />
|edition=<br />
|publisher=Dorset House<br />
|issue=<br />
|date=1998<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=Kinney and Lange, P.A.<br />
|article=<br />
|publication=Intellectual Property Law for Business Lawyers<br />
|edition=<br />
|publisher=Thomson West<br />
|issue=<br />
|date=2013<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_10:_Software_Quality&diff=873Chapter 10: Software Quality2015-08-29T15:09:23Z<p>Daniel Robbins: /* Software Quality Tools */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}<br />
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}<br />
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}<br />
{{Acronym|name=FTA|description=Fault Tree Analysis}}<br />
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}<br />
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}<br />
{{Acronym|name=QFD|description=Quality Function Deployment}}<br />
{{Acronym|name=SPI|description=Software Process Improvement}}<br />
{{Acronym|name=SQA|description=Software Quality Assurance}}<br />
{{Acronym|name=SQC|description=Software Quality Control}}<br />
{{Acronym|name=SQM|description=Software Quality Management}}<br />
{{Acronym|name=TQM|description=Total Quality Management}}<br />
{{Acronym|name=V&V|description=Verification and Validation}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
What is software quality, and why is it so important<br />
that it is included in many knowledge areas<br />
(KAs) of the ''SWEBOK Guide''?<br />
<br />
One reason is that the term ''software quality'' is<br />
overloaded. Software quality may refer: to desirable<br />
characteristics of software products, to the<br />
extent to which a particular software product possess<br />
those characteristics, and to processes, tools,<br />
and techniques used to achieve those characteristics.<br />
Over the years, authors and organizations<br />
have defined the term quality differently. To Phil<br />
Crosby, it was “conformance to requirements”<br />
[1]. Watts Humphrey refers to it as “achieving<br />
excellent levels of “fitness for use” [2]. Meanwhile,<br />
IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”<br />
[3*, p8].<br />
<br />
More recently, software quality is defined as the<br />
“capability of software product to satisfy stated<br />
and implied needs under specified conditions” [4]<br />
and as “the degree to which a software product<br />
meets established requirements; however, quality<br />
depends upon the degree to which those established<br />
requirements accurately represent stakeholder<br />
needs, wants, and expectations” [5]. Both<br />
definitions embrace the premise of conformance<br />
to requirements. Neither refers to types of requirements<br />
(e.g., functional, reliability, performance,<br />
dependability, or any other characteristic). Significantly,<br />
however, these definitions emphasize that<br />
quality is dependent upon requirements.<br />
<br />
These definitions also illustrate another reason<br />
for the prevalence of software quality throughout<br />
this ''Guide'': a frequent ambiguity of ''software quality'' versus ''software quality requirements''<br />
(“the -''ilities''” is a common shorthand). Software<br />
quality requirements are actually attributes of (or<br />
constraints on) functional requirements (what<br />
the system does). Software requirements may<br />
also specify resource usage, a communication<br />
protocol, or many other characteristics. This KA<br />
attempts clarity by using ''software quality'' in the<br />
broadest sense from the definitions above and<br />
by using ''software quality requirements'' as constraints<br />
on functional requirements. Software<br />
quality is achieved by conformance to all requirements<br />
regardless of what characteristic is specified<br />
or how requirements are grouped or named.<br />
<br />
Software quality is also considered in many of<br />
the SWEBOK KAs because it is a basic parameter<br />
of a software engineering effort. For all engineered<br />
products, the primary goal is delivering<br />
maximum stakeholder value, while balancing the<br />
constraints of development cost and schedule;<br />
this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements.<br />
For software products, stakeholders could<br />
value price (what they pay for the product), lead<br />
time (how fast they get the product), and software<br />
quality.<br />
<br />
This KA addresses definitions and provides an<br />
overview of practices, tools, and techniques for<br />
defining software quality and for appraising the<br />
state of software quality during development,<br />
maintenance, and deployment. Cited references<br />
provide additional details.}}<br />
[[File:Breakdown of Topics for the Software Quality.jpg|thumb|300px|frame|Figure 10.1: Breakdown of Topics for the Software Quality KA]]<br />
{{IntroSection|title=Breakdown of Topics for Software Quality|body=<br />
The breakdown of topics for the Software Quality KA is presented in Figure 10.1.}}<br />
<br />
==Software Quality Fundamentals==<br />
<br />
Reaching agreement on what constitutes quality<br />
for all stakeholders and clearly communicating<br />
that agreement to software engineers require that the many aspects of quality be formally defined<br />
and discussed.<br />
<br />
A software engineer should understand quality<br />
concepts, characteristics, values, and their<br />
application to the software under development or<br />
maintenance. The important concept is that the<br />
software requirements define the required quality<br />
attributes of the software. Software requirements<br />
influence the measurement methods and acceptance<br />
criteria for assessing the degree to which<br />
the software and related documentation achieve<br />
the desired quality levels.<br />
<br />
===Software Engineering Culture and Ethics===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=6|parts=c2s3.5}}}}<br />
<br />
Software engineers are expected to share a commitment<br />
to software quality as part of their culture.<br />
A healthy software engineering culture includes<br />
many characteristics, including the understanding<br />
that tradeoffs among cost, schedule, and quality<br />
are a basic tenant of the engineering of any product.<br />
A strong software engineering ethic assumes that engineers accurately report information, conditions,<br />
and outcomes related to quality.<br />
<br />
Ethics also play a significant role in software<br />
quality, the culture, and the attitudes of software<br />
engineers. The IEEE Computer Society and the<br />
ACM have developed a code of ethics and professional<br />
practice (see Codes of Ethics and Professional<br />
Conduct in the Software Engineering<br />
Professional Practice KA).<br />
<br />
===Value and Costs of Quality===<br />
{{RightSection|{{referenceLink|number=7|parts=c17, c22}}}}<br />
<br />
Defining and then achieving software quality is<br />
not simple. Quality characteristics may or may<br />
not be required, or they may be required to a<br />
greater or lesser degree, and tradeoffs may be<br />
made among them. To help determine the level<br />
of software quality, i.e., achieving stakeholder<br />
value, this section presents cost of software quality<br />
(CoSQ): a set of measurements derived from<br />
the economic assessment of software quality<br />
development and maintenance processes. The<br />
CoSQ measurements are examples of process<br />
measurements that may be used to infer characteristics<br />
of a product.<br />
<br />
The premise underlying the CoSQ is that the<br />
level of quality in a software product can be<br />
inferred from the cost of activities related to dealing<br />
with the consequences of poor quality. Poor<br />
quality means that the software product does not<br />
fully “satisfy stated and implied needs” or “established<br />
requirements.” There are four cost of quality<br />
categories: prevention, appraisal, internal failure,<br />
and external failure.<br />
<br />
Prevention costs include investments in software<br />
process improvement efforts, quality infrastructure,<br />
quality tools, training, audits, and management<br />
reviews. These costs are usually not specific<br />
to a project; they span the organization. Appraisal<br />
costs arise from project activities that find defects.<br />
These appraisal activities can be categorized into<br />
costs of reviews (design, peer) and costs of testing<br />
(software unit testing, software integration,<br />
system level testing, acceptance testing); appraisal<br />
costs would be extended to subcontracted software<br />
suppliers. Costs of internal failures are those that<br />
are incurred to fix defects found during appraisal<br />
activities and discovered prior to delivery of the software product to the customer. External failure<br />
costs include activities to respond to software<br />
problems discovered after delivery to the customer. <br />
<br />
Software engineers should be able to use CoSQ<br />
methods to ascertain levels of software quality<br />
and should also be able to present quality alternatives<br />
and their costs so that tradeoffs between<br />
cost, schedule, and delivery of stakeholder value<br />
can be made.<br />
<br />
===Models and Quality Characteristics===<br />
{{RightSection|{{referenceLink|number=3|parts=c24s1}} {{referenceLink|number=7|parts=c2s4}} {{referenceLink|number=8|parts=c17}}}}<br />
<br />
Terminology for software quality characteristics<br />
differs from one taxonomy (or model of software<br />
quality) to another, each model perhaps having<br />
a different number of hierarchical levels and a<br />
different total number of characteristics. Various<br />
authors have produced models of software quality<br />
characteristics or attributes that can be useful<br />
for discussing, planning, and rating the quality<br />
of software products. ISO/IEC 25010: 2011 [4]<br />
defines product quality and quality in use as two<br />
related quality models. Appendix B in the SWEBOK<br />
Guide provides a list of applicable standards<br />
for each KA. Standards for this KA cover various<br />
ways of characterizing software quality.<br />
<br />
====Software Process Quality====<br />
<br />
Software quality management and software engineering<br />
process quality have a direct bearing on<br />
the quality of the software product.<br />
<br />
Models and criteria that evaluate the capabilities<br />
of software organizations are primarily project<br />
organization and management considerations<br />
and, as such, are covered in the Software Engineering<br />
Management and Software Engineering<br />
Process KAs.<br />
<br />
It is not possible to completely distinguish process<br />
quality from product quality because process<br />
outcomes include products. Determining whether<br />
a process has the capability to consistently produce<br />
products of desired quality is not simple.<br />
<br />
The software engineering process, discussed<br />
in the Software Engineering Process KA, influences<br />
the quality characteristics of software products,<br />
which in turn affect quality as perceived by<br />
stakeholders.<br />
<br />
====Software Product Quality====<br />
<br />
The software engineer, first of all, must determine<br />
the real purpose of the software. In this regard,<br />
stakeholder requirements are paramount, and they<br />
include quality requirements in addition to functional<br />
requirements. Thus, software engineers<br />
have a responsibility to elicit quality requirements<br />
that may not be explicit at the outset and to understand<br />
their importance as well as the level of difficulty<br />
in attaining them. All software development<br />
processes (e.g., eliciting requirements, designing,<br />
constructing, building, checking, improving quality)<br />
are designed with these quality requirements<br />
in mind and may carry additional development<br />
costs if attributes such as safety, security, and<br />
dependability are important. The additional development<br />
costs help ensure that quality obtained can<br />
be traded off against the anticipated benefits.<br />
<br />
The term work-product means any artifact that<br />
is the outcome of a process used to create the<br />
final software product. Examples of a work-product<br />
include a system/subsystem specification, a<br />
software requirements specification for a software<br />
component of a system, a software design<br />
description, source code, software test documentation,<br />
or reports. While some treatments of quality<br />
are described in terms of final software and<br />
system performance, sound engineering practice<br />
requires that intermediate work-products relevant<br />
to quality be evaluated throughout the software<br />
engineering process.<br />
<br />
===Software Quality Improvement===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=9|parts=c24}} {{referenceLink|number=10|parts=c11s2.4}}}}<br />
<br />
The quality of software products can be improved<br />
through preventative processes or an iterative<br />
process of continual improvement, which<br />
requires management control, coordination, and<br />
feedback from many concurrent processes: (1)<br />
the software life cycle processes, (2) the process<br />
of fault/defect detection, removal, and prevention,<br />
and (3) the quality improvement process.<br />
<br />
The theory and concepts behind quality<br />
improvement—such as building in quality<br />
through the prevention and early detection of<br />
defects, continual improvement, and stakeholder<br />
focus—are pertinent to software engineering.<br />
These concepts are based on the work of experts in quality who have stated that the quality of a<br />
product is directly linked to the quality of the<br />
process used to create it. Approaches such as the<br />
Deming improvement cycle of Plan-Do-Check-<br />
Act (PDCA), evolutionary delivery, kaizen, and<br />
quality function deployment (QFD) offer techniques<br />
to specify quality objectives and determine<br />
whether they are met. The Software Engineering<br />
Institute’s IDEAL is another method [7*]. Quality<br />
management is now recognized by the '''SWEBOK Guide'' as an important discipline.<br />
<br />
Management sponsorship supports process and<br />
product evaluations and the resulting findings.<br />
Then an improvement program is developed<br />
identifying detailed actions and improvement<br />
projects to be addressed in a feasible time frame.<br />
Management support implies that each improvement<br />
project has enough resources to achieve the<br />
goal defined for it. Management sponsorship is<br />
solicited frequently by implementing proactive<br />
communication activities.<br />
<br />
===Software Safety===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s3}}}}<br />
<br />
Safety-critical systems are those in which a system<br />
failure could harm human life, other living<br />
things, physical structures, or the environment.<br />
The software in these systems is safety-critical.<br />
There are increasing numbers of applications<br />
of safety-critical software in a growing number<br />
of industries. Examples of systems with safetycritical<br />
software include mass transit systems,<br />
chemical manufacturing plants, and medical<br />
devices. The failure of software in these systems<br />
could have catastrophic effects. There are industry<br />
standards, such as DO-178C [11], and emerging<br />
processes, tools, and techniques for developing<br />
safetycritical software. The intent of these<br />
standards, tools, and techniques is to reduce the<br />
risk of injecting faults into the software and thus<br />
improve software reliability.<br />
<br />
Safety-critical software can be categorized as<br />
direct or indirect. Direct is that software embedded<br />
in a safety-critical system, such as the flight<br />
control computer of an aircraft. Indirect includes<br />
software applications used to develop safetycritical<br />
software. Indirect software is included in<br />
software engineering environments and software<br />
test environments.<br />
<br />
Three complementary techniques for reducing<br />
the risk of failure are avoidance, detection<br />
and removal, and damage limitation. These<br />
techniques impact software functional requirements,<br />
software performance requirements, and<br />
development processes. Increasing levels of risk<br />
imply increasing levels of software quality assurance<br />
and control techniques such as inspections.<br />
Higher risk levels may necessitate more thorough<br />
inspections of requirements, design, and code<br />
or the use of more formal analytical techniques.<br />
Another technique for managing and controlling<br />
software risk is building assurance cases. An<br />
assurance case is a reasoned, auditable artifact<br />
created to support the contention that its claim<br />
or claims are satisfied. It contains the following<br />
and their relationships: one or more claims about<br />
properties; arguments that logically link the evidence<br />
and any assumptions to the claims; and a<br />
body of evidence and assumptions supporting<br />
these arguments [12].<br />
<br />
==Software Quality Management Processes==<br />
<br />
Software quality management is the collection of<br />
all processes that ensure that software products,<br />
services, and life cycle process implementations<br />
meet organizational software quality objectives<br />
and achieve stakeholder satisfaction [13, 14].<br />
SQM defines processes, process owners, requirements<br />
for the processes, measurements of the<br />
processes and their outputs, and feedback channels<br />
throughout the whole software life cycle.<br />
<br />
SQM comprises four subcategories: software<br />
quality planning, software quality assurance<br />
(SQA), software quality control (SQC), and software<br />
process improvement (SPI). Software quality<br />
planning includes determining which quality<br />
standards are to be used, defining specific quality<br />
goals, and estimating the effort and schedule of<br />
software quality activities. In some cases, software<br />
quality planning also includes defining the<br />
software quality processes to be used. SQA activities<br />
define and assess the adequacy of software<br />
processes to provide evidence that establishes<br />
confidence that the software processes are appropriate<br />
for and produce software products of suitable<br />
quality for their intended purposes [5]. SQC<br />
activities examine specific project artifacts (documents<br />
and executables) to determine whether they comply with standards established for the project<br />
(including requirements, constraints, designs,<br />
contracts, and plans). SQC evaluates intermediate<br />
products as well as the final products.<br />
<br />
The fourth SQM category dealing with improvement<br />
has various names within the software industry,<br />
including SPI, software quality improvement,<br />
and software corrective and preventive action. The<br />
activities in this category seek to improve process<br />
effectiveness, efficiency, and other characteristics<br />
with the ultimate goal of improving software<br />
quality. Although SPI could be included in any of<br />
the first three categories, an increasing number<br />
of organizations organize SPI into a separate category<br />
that may span across many projects (see the<br />
Software Engineering Process KA).<br />
<br />
Software quality processes consist of tasks<br />
and techniques to indicate how software plans<br />
(e.g., software management, development, quality<br />
management, or configuration management<br />
plans) are being implemented and how well the<br />
intermediate and final products are meeting their<br />
specified requirements. Results from these tasks<br />
are assembled in reports for management before<br />
corrective action is taken. The management of<br />
an SQM process is tasked with ensuring that the<br />
results of these reports are accurate.<br />
<br />
Risk management can also play an important<br />
role in delivering quality software. Incorporating<br />
disciplined risk analysis and management techniques<br />
into the software life cycle processes can<br />
help improve product quality (see the Software<br />
Engineering Management KA for related material<br />
on risk management).<br />
<br />
===Software Quality Assurance===<br />
{{RightSection|{{referenceLink|number=7|parts=c4–c6, c11, c12, c26–27}}}}<br />
<br />
To quell a widespread misunderstanding, software<br />
quality assurance is not testing. software<br />
quality assurance (SQA) is a set of activities that<br />
define and assess the adequacy of software processes<br />
to provide evidence that establishes confidence<br />
that the software processes are appropriate<br />
and produce software products of suitable quality<br />
for their intended purposes. A key attribute of<br />
SQA is the objectivity of the SQA function with<br />
respect to the project. The SQA function may<br />
also be organizationally independent of the project;<br />
that is, free from technical, managerial, and financial pressures from the project [5]. SQA has<br />
two aspects: product assurance and process assurance,<br />
which are explained in section 2.3.<br />
<br />
The software quality plan (in some industry<br />
sectors it is termed the software quality assurance<br />
plan) defines the activities and tasks employed<br />
to ensure that software developed for a specific<br />
product satisfies the project’s established requirements<br />
and user needs within project cost and<br />
schedule constraints and is commensurate with<br />
project risks. The SQAP first ensures that quality<br />
targets are clearly defined and understood.<br />
<br />
The SQA plan’s quality activities and tasks are<br />
specified with their costs, resource requirements,<br />
objectives, and schedule in relation to related<br />
objectives in the software engineering management,<br />
software development, and software maintenance<br />
plans. The SQA plan should be consistent<br />
with the software configuration management<br />
plan (see the Software Configuration Management<br />
KA). The SQA plan identifies documents,<br />
standards, practices, and conventions governing<br />
the project and how these items are checked and<br />
monitored to ensure adequacy and compliance.<br />
The SQA plan also identifies measures; statistical<br />
techniques; procedures for problem reporting and<br />
corrective action; resources such as tools, techniques,<br />
and methodologies; security for physical<br />
media; training; and SQA reporting and documentation.<br />
Moreover, the SQA plan addresses<br />
the software quality assurance activities of any<br />
other type of activity described in the software<br />
plans—such as procurement of supplier software<br />
for the project, commercial off-the-shelf software<br />
(COTS) installation, and service after delivery of<br />
the software. It can also contain acceptance criteria<br />
as well as reporting and management activities<br />
that are critical to software quality.<br />
<br />
===Verification & Validation===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s2.3, c8, c15s1.1, c21s3.3}}}}<br />
<br />
As stated in [15],<br />
<br />
* The purpose of V&V is to help the development organization build quality into the system during the life cycle. V&V processes provide an objective assessment of products and processes throughout the life cycle. This assessment demonstrates whether the requirements are correct, complete, accurate, consistent, and testable. The V&V processes determine whether the development products of a given activity<br />
conform to the requirements of that activity and whether the product satisfies its intended use and user needs.<br />
<br />
Verification is an attempt to ensure that the<br />
product is built correctly, in the sense that the<br />
output products of an activity meet the specifications<br />
imposed on them in previous activities.<br />
Validation is an attempt to ensure that the right<br />
product is built—that is, the product fulfills its<br />
specific intended purpose. Both the verification<br />
process and the validation process begin early<br />
in the development or maintenance phase. They<br />
provide an examination of key product features<br />
in relation to both the product’s immediate predecessor<br />
and the specifications to be met.<br />
<br />
The purpose of planning V&V is to ensure that<br />
each resource, role, and responsibility is clearly<br />
assigned. The resulting V&V plan documents<br />
describe the various resources and their roles and<br />
activities, as well as the techniques and tools to be<br />
used. An understanding of the different purposes of<br />
each V&V activity helps in the careful planning of<br />
the techniques and resources needed to fulfill their<br />
purposes. The plan also addresses the management,<br />
communication, policies, and procedures of<br />
the V&V activities and their interaction, as well as<br />
defect reporting and documentation requirements.<br />
<br />
===Reviews and Audits===<br />
{{RightSection|{{referenceLink|number=9|parts=c24s3}} {{referenceLink|number=16}}}}<br />
<br />
Reviews and audit processes are broadly defined<br />
as static—meaning that no software programs or<br />
models are executed—examination of software<br />
engineering artifacts with respect to standards that<br />
have been established by the organization or project<br />
for those artifacts. Different types of reviews<br />
and audits are distinguished by their purpose, levels<br />
of independence, tools and techniques, roles,<br />
and by the subject of the activity. Product assurance<br />
and process assurance audits are typically<br />
conducted by software quality assurance (SQA)<br />
personnel who are independent of development teams. Management reviews are conducted by<br />
organizational or project management. The engineering<br />
staff conducts technical reviews.<br />
<br />
* Management reviews evaluate actual project results with respect to plans.<br />
* Technical reviews (including inspections, walkthrough, and desk checking) examine engineering work-products.<br />
* Process assurance audits. SQA process assurance activities make certain that the processes used to develop, install, operate, and maintain software conform to contracts, comply with any imposed laws, rules, and regulations and are adequate, efficient and effective for their intended purpose [5].<br />
* Product assurance audits. SQA product assurance activities make certain to provide evidence that software products and related documentation are identified in and comply with contracts; and ensure that nonconformances are identified and addressed [5].<br />
<br />
====Management Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a management review is to monitor progress, determine the status of plans and schedules, and evaluate the effectiveness<br />
of management processes, tools and techniques. Management reviews compare actual project results against plans to determine the status of projects or maintenance efforts. The main parameters of management reviews are project cost, schedule, scope, and quality. Management reviews evaluate decisions about corrective actions, changes in the allocation of resources, or changes to the scope of the project.<br />
<br />
Inputs to management reviews may include<br />
audit reports, progress reports, V&V reports, and<br />
plans of many types, including risk management,<br />
project management, software configuration<br />
management, software safety, and risk assessment,<br />
among others. (Refer to the Software Engineering<br />
Management and the Software Configuration<br />
Management KAs for related material.)<br />
<br />
====Technical Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a technical review is to evaluate a software product by a team of qualified personnel to determine its suitability for its intended use and identify discrepancies from specifications and standards. It provides management with evidence to confirm the technical status of the project.<br />
<br />
Although any work-product can be reviewed,<br />
technical reviews are performed on the main<br />
software engineering work-products of software<br />
requirements and software design.<br />
<br />
Purpose, roles, activities, and most importantly<br />
the level of formality distinguish different types<br />
of technical reviews. Inspections are the most formal,<br />
walkthroughs less, and pair reviews or desk<br />
checks are the least formal.<br />
<br />
Examples of specific roles include a decision<br />
maker (i.e., software lead), a review leader, a<br />
recorder, and checkers (technical staff members<br />
who examine the work-products). Reviews are<br />
also distinguished by whether meetings (face to<br />
face or electronic) are included in the process. In<br />
some review methods checkers solitarily examine<br />
work-products and send their results back to<br />
a coordinator. In other methods checkers work<br />
cooperatively in meetings. A technical review<br />
may require that mandatory inputs be in place in<br />
order to proceed:<br />
<br />
* Statement of objectives<br />
* Specific software product<br />
* Specific project management plan<br />
* Issues list associated with this product<br />
* Technical review procedure.<br />
<br />
The team follows the documented review procedure.<br />
The technical review is completed once<br />
all the activities listed in the examination have<br />
been completed.<br />
<br />
Technical reviews of source code may include a<br />
wide variety of concerns such as analysis of algorithms,<br />
utilization of critical computer resources,<br />
adherence to coding standards, structure and organization of code for testability, and safetycritical<br />
considerations.<br />
<br />
Note that technical reviews of source code or<br />
design models such as UML are also termed static<br />
analysis (see topic 3, Practical Considerations).<br />
<br />
====Inspections====<br />
<br />
“The purpose of an inspection is to detect and<br />
identify software product anomalies” [16*].<br />
Some important differentiators of inspections as<br />
compared to other types of technical reviews are<br />
these:<br />
<br />
* 1. Rules. Inspections are based upon examining a work-product with respect to a defined set of criteria specified by the organization. Sets of rules can be defined for different types of workproducts (e.g., rules for requirements,architecture descriptions, source code).<br />
* 2. Sampling. Rather that attempt to examine every word and figure in a document, the inspection process allows checkers to evaluate defined subsets (samples) of the documents under review.<br />
* 3. Peer. Individuals holding management positions over members of the inspection team do not participate in the inspection. This is<br />
a key distinction between peer review and management review.<br />
* 4. Led. An impartial moderator who is trained in inspection techniques leads inspection meetings.<br />
* 5. Meeting. The inspection process includes meetings (face to face or electronic) conducted by a moderator according to a formal procedure in which inspection team members report the anomalies they have found and other issues.<br />
<br />
Software inspections always involve the author<br />
of an intermediate or final product; other reviews<br />
might not. Inspections also include an inspection<br />
leader, a recorder, a reader, and a few (two to five)<br />
checkers (inspectors). The members of an inspection<br />
team may possess different expertise, such as<br />
domain expertise, software design method expertise,<br />
or programming language expertise. Inspections<br />
are usually conducted on one relatively small section of the product at a time (samples).<br />
Each team member examines the software product<br />
and other review inputs prior to the review<br />
meeting, perhaps by applying an analytical technique<br />
(see section 3.3.3) to a small section of<br />
the product or to the entire product with a focus<br />
on only one aspect—e.g., interfaces. During the<br />
inspection, the moderator conducts the session<br />
and verifies that everyone has prepared for the<br />
inspection and conducts the session. The inspection<br />
recorder documents anomalies found. A set<br />
of rules, with criteria and questions germane to<br />
the issues of interest, is a common tool used in<br />
inspections. The resulting list often classifies the<br />
anomalies (see section 3.2, Defect Characterization)<br />
and is reviewed for completeness and accuracy<br />
by the team. The inspection exit decision<br />
corresponds to one of the following options:<br />
<br />
* 1. Accept with no or, at most, minor reworking<br />
* 2. Accept with rework verification<br />
* 3. Reinspect.<br />
<br />
====Walkthroughs====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a systematic walk-through is to evaluate a software product. A walkthrough may be conducted for the purpose of educating an audience regarding a software product.<br />
<br />
Walkthroughs are distinguished from inspections.<br />
The main difference is that the author presents<br />
the work-product to the other participants in<br />
a meeting (face to face or electronic). Unlike an<br />
inspection, the meeting participants may not have<br />
necessarily seen the material prior to the meeting.<br />
The meetings may be conducted less formally.<br />
The author takes the role of explaining and<br />
showing the material to participants and solicits<br />
feedback. Like inspections, walkthroughs may be<br />
conducted on any type of work-product including<br />
project plan, requirements, design, source code,<br />
and test reports.<br />
<br />
====Process Assurance and Product Assurance Audits====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes<br />
to applicable regulations, standards, guidelines, plans, and procedures.<br />
<br />
Process assurance audits determine the adequacy<br />
of plans, schedules, and requirements to achieve<br />
project objectives [5]. The audit is a formally<br />
organized activity with participants having specific<br />
roles—such as lead auditor, another auditor, a<br />
recorder, or an initiator—and including a representative<br />
of the audited organization. Audits identify<br />
instances of nonconformance and produce a report<br />
requiring the team to take corrective action.<br />
<br />
While there may be many formal names for<br />
reviews and audits, such as those identified in the<br />
standard [16*], the important point is that they<br />
can occur on almost any product at any stage of<br />
the development or maintenance process.<br />
<br />
==Practical Considerations==<br />
===Software Quality Requirements===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s1}} {{referenceLink|number=18|parts=c12}} {{referenceLink|number=17|parts=c15s3.2.2, c15s3.3.1, c16s9.10}}}}<br />
====Influence Factors====<br />
Various factors influence planning, management,<br />
and selection of SQM activities and techniques,<br />
including<br />
<br />
* the domain of the system in which the software resides; the system functions could be safety-critical, mission-critical, businesscritical,security-critical<br />
* the physical environment in which the software system resides<br />
* system and software functional (what the system does) and quality (how well the system performs its functions) requirements<br />
* the commercial (external) or standard (internal) components to be used in the system<br />
* the specific software engineering standards applicable<br />
* the methods and software tools to be used for development and maintenance and for quality evaluation and improvement<br />
* the budget, staff, project organization, plans, and scheduling of all processes<br />
* the intended users and use of the system<br />
* the integrity level of the system.<br />
<br />
Information on these factors influences how<br />
the SQM processes are organized and documented,<br />
how specific SQM activities are selected,<br />
what resources are needed, and which of those<br />
resources impose bounds on the efforts.<br />
<br />
====Dependability====<br />
<br />
In cases where system failure may have extremely<br />
severe consequences, overall dependability (hardware,<br />
software, and human or operational) is the<br />
main quality requirement over and above basic<br />
functionality. This is the case for the following<br />
reasons: system failures affect a large number of<br />
people; users often reject systems that are unreliable,<br />
unsafe, or insecure; system failure costs<br />
may be enormous; and undependable systems<br />
may cause information loss. System and software<br />
dependability include such characteristics<br />
as availability, reliability, safety, and security.<br />
When developing dependable software, tools and<br />
techniques can be applied to reduce the risk of<br />
injecting faults into the intermediate deliverables<br />
or the final software product. Verification, validation,<br />
and testing processes, techniques, methods,<br />
and tools identify faults that impact dependability<br />
as early as possible in the life cycle. Additionally,<br />
mechanisms may need to be in place in the<br />
software to guard against external attacks and to<br />
tolerate faults.<br />
<br />
====Integrity Levels of Software====<br />
<br />
Defining integrity levels is a method of risk<br />
management.<br />
<br />
* Software integrity levels are a range of values that represent software complexity, criticality, risk, safety level, security level, desired performance, reliability, or other project-unique characteristics that define the importance of the software to the user and acquirer. The characteristics used to determine software integrity level vary depending on the intended application and use of the system. The software is a part of the system, and its integrity level is to be determined as a part of that system.<br />
<br />
The assigned software integrity levels may<br />
change as the software evolves. Design, coding,<br />
procedural, and technology features implemented<br />
in the system or software can raise or lower the<br />
assigned software integrity levels. The software<br />
integrity levels established for a project result<br />
from agreements among the acquirer, supplier,<br />
developer, and independent assurance authorities.<br />
A software integrity level scheme is a tool used in<br />
determining software integrity levels. [5]<br />
<br />
As noted in [17*], “the integrity levels can be<br />
applied during development to allocate additional<br />
verification and validation efforts to high-integrity<br />
components.”<br />
<br />
===Defect Characterization===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s3, c8s8, c10s2}}}}<br />
<br />
Software quality evaluation (i.e., software quality<br />
control) techniques find defects, faults and failures.<br />
Characterizing these techniques leads to an<br />
understanding of the product, facilitates corrections<br />
to the process or the product, and informs<br />
management and other stakeholders of the status<br />
of the process or product. Many taxonomies<br />
exist and, while attempts have been made to gain<br />
consensus, the literature indicates that there are<br />
quite a few in use. Defect characterization is also<br />
used in audits and reviews, with the review leader<br />
often presenting a list of issues provided by team<br />
members for consideration at a review meeting.<br />
<br />
As new design methods and languages evolve,<br />
along with advances in overall software technologies,<br />
new classes of defects appear, and a great<br />
deal of effort is required to interpret previously<br />
defined classes. When tracking defects, the software<br />
engineer is interested in not only the number<br />
of defects but also the types. Information alone,<br />
without some classification, may not be sufficient<br />
to identify the underlying causes of the defects.<br />
Specific types of problems need to be grouped to<br />
identify trends over time. The point is to establish<br />
a defect taxonomy that is meaningful to the organization<br />
and to software engineers.<br />
<br />
Software quality control activities discover information<br />
at all stages of software development and<br />
maintenance. In some cases, the word ''defect'' is<br />
overloaded to refer to different types of anomalies.<br />
However, different engineering cultures and standards<br />
may use somewhat different meanings for<br />
these terms. The variety of terms prompts this section<br />
to provide a widely used set of definitions [19]:<br />
<br />
* ''Computational Error'': “the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.”<br />
* ''Error'': “A human action that produces an incorrect result.” A slip or mistake that a person makes. Also called human error.<br />
* ''Defect'': An “imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced.” A defect is caused by a person committing an error.<br />
* ''Fault'': A defect in source code. An “incorrect step, process, or data definition in computer program.” The encoding of a human error in source code. Fault is the formal name of a bug.<br />
* ''Failure'': An “event in which a system or system component does not perform a required function within specified limits.” A failure is<br />
produced when a fault is encountered by the processor under specified conditions.<br />
<br />
Using these definitions three widely used software<br />
quality measurements are defect density<br />
(number of defects per unit size of documents),<br />
fault density (number of faults per 1K lines of<br />
code), and failure intensity (failures per use-hour<br />
or per test-hour). Reliability models are built<br />
from failure data collected during software testing<br />
or from software in service and thus can be<br />
used to estimate the probability of future failures<br />
and to assist in decisions on when to stop testing.<br />
<br />
One probable action resulting from SQM findings<br />
is to remove the defects from the product<br />
under examination (e.g., find and fix bugs, create<br />
new build). Other activities attempt to eliminate the causes of the defects—for example, root cause<br />
analysis (RCA). RCA activities include analyzing<br />
and summarizing the findings to find root causes<br />
and using measurement techniques to improve<br />
the product and the process as well as to track the<br />
defects and their removal. Process improvement<br />
is primarily discussed in the Software Engineering<br />
Process KA, with the SQM process being a<br />
source of information.<br />
<br />
Data on inadequacies and defects found by<br />
software quality control techniques may be lost<br />
unless they are recorded. For some techniques<br />
(e.g., technical reviews, audits, inspections),<br />
recorders are present to set down such information,<br />
along with issues and decisions. When automated<br />
tools are used (see topic 4, Software Quality<br />
Tools), the tool output may provide the defect<br />
information. Reports about defects are provided<br />
to the management of the organization.<br />
<br />
===Software Quality Management Techniques===<br />
{{RightSection|{{referenceLink|number=7|parts=c7s3}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=c12s5, c15s1, p417}}{{referenceLink|number=16}}}}<br />
<br />
Software quality control techniques can be categorized<br />
in many ways, but a straightforward<br />
approach uses just two categories: static and<br />
dynamic. Dynamic techniques involve executing<br />
the software; static techniques involve analyzing<br />
documents<br />
<br />
====Static Techniques====<br />
<br />
Static techniques examine software documentation<br />
(including requirements, interface specifications,<br />
designs, and models) and software source<br />
code without executing the code. There are many<br />
tools and techniques for statically examining software<br />
work-products (see section 2.3.2). In addition,<br />
tools that analyze source code control flow<br />
and search for dead code are considered to be<br />
static analysis tools because they do not involve<br />
executing the software code.<br />
<br />
Other, more formal, types of analytical techniques<br />
are known as formal methods. They are<br />
notably used to verify software requirements and<br />
designs. They have mostly been used in the verification<br />
of crucial parts of critical systems, such<br />
as specific security and safety requirements. (See also Formal Methods in the Software Engineering<br />
Models and Methods KA.)<br />
<br />
====Dynamic Techniques====<br />
<br />
Dynamic techniques involve executing the software<br />
code. Different kinds of dynamic techniques<br />
are performed throughout the development and<br />
maintenance of software. Generally, these are<br />
testing techniques, but techniques such as simulation<br />
and model analysis may be considered<br />
dynamic (see the Software Engineering Models<br />
and Methods KA). Code reading is considered a<br />
static technique, but experienced software engineers<br />
may execute the code as they read through<br />
it. Code reading may utilize dynamic techniques.<br />
This discrepancy in categorizing indicates that<br />
people with different roles and experience in the<br />
organization may consider and apply these techniques<br />
differently.<br />
<br />
Different groups may perform testing during<br />
software development, including groups independent<br />
of the development team. The Software<br />
Testing KA is devoted entirely to this subject.<br />
<br />
====Testing====<br />
<br />
Two types of testing may fall under V&V because<br />
of their responsibility for the quality of the materials<br />
used in the project:<br />
<br />
* Evaluation and tests of tools to be used on the project<br />
* Conformance tests (or review of conformance tests) of components and COTS products to be used in the product<br />
<br />
Sometimes an independent (third-party or<br />
IV&V) organization may be tasked to perform<br />
testing or to monitor the test process V&V may<br />
be called upon to evaluate the testing itself: adequacy<br />
of plans, processes, and procedures, and<br />
adequacy and accuracy of results.<br />
<br />
The third party is not the developer, nor is it<br />
associated with the development of the product.<br />
Instead, the third party is an independent facility,<br />
usually accredited by some body of authority.<br />
Their purpose is to test a product for conformance<br />
to a specific set of requirements (see the Software Testing KA).<br />
<br />
===Software Quality Measurement===<br />
{{RightSection|{{referenceLink|number=3|parts=c4}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=p90}}}}<br />
<br />
Software quality measurements are used to<br />
support decision-making. With the increasing<br />
sophistication of software, questions of quality<br />
go beyond whether or not the software works to<br />
how well it achieves measurable quality goals.<br />
<br />
Decisions supported by software quality measurement<br />
include determining levels of software<br />
quality (notably because models of software<br />
product quality include measures to determine<br />
the degree to which the software product achieves<br />
quality goals); managerial questions about effort,<br />
cost, and schedule; determining when to stop testing<br />
and release a product (see Termination under<br />
section 5.1, Practical Considerations, in the Software<br />
Testing KA); and determining the efficacy<br />
of process improvement efforts.<br />
<br />
The cost of SQM processes is an issue frequently<br />
raised in deciding how a project or a software<br />
development and maintenance group should<br />
be organized. Often, generic models of cost are<br />
used, which are based on when a defect is found<br />
and how much effort it takes to fix the defect relative<br />
to finding the defect earlier in the development<br />
process. Software quality measurement data<br />
collected internally may give a better picture of<br />
cost within this project or organization.<br />
<br />
While the software quality measurement data<br />
may be useful in itself (e.g., the number of defective<br />
requirements or the proportion of defective<br />
requirements), mathematical and graphical techniques<br />
can be applied to aid in the interpretation<br />
of the measures (see the Engineering Foundations<br />
KA). These techniques include<br />
<br />
* descriptive statistics based (e.g., Pareto analysis, run charts, scatter plots, normal distribution)<br />
* statistical tests (e.g., the binomial test, chisquared test)<br />
* trend analysis (e.g., control charts; see''The Quality Toolbox'' in the list of further readings)<br />
* prediction (e.g., reliability models).<br />
<br />
Descriptive statistics-based techniques and<br />
tests often provide a snapshot of the more troublesome areas of the software product under<br />
examination. The resulting charts and graphs<br />
are visualization aids, which the decision makers<br />
can use to focus resources and conduct process<br />
improvements where they appear to be most<br />
needed. Results from trend analysis may indicate<br />
that a schedule is being met, such as in testing, or<br />
that certain classes of faults may become more<br />
likely to occur unless some corrective action is<br />
taken in development. The predictive techniques<br />
assist in estimating testing effort and schedule<br />
and in predicting failures. More discussion on<br />
measurement in general appears in the Software<br />
Engineering Process and Software Engineering<br />
Management KAs. More specific information on<br />
testing measurement is presented in the Software<br />
Testing KA.<br />
<br />
Software quality measurement includes measuring<br />
defect occurrences and applying statistical<br />
methods to understand the types of defects that<br />
occur most frequently. This information may be<br />
used by software process improvement for determining<br />
methods to prevent, reduce, or eliminate<br />
their recurrence. They also aid in understanding<br />
trends, how well detection and containment techniques<br />
are working, and how well the development<br />
and maintenance processes are progressing.<br />
<br />
From these measurement methods, defect<br />
profiles can be developed for a specific application<br />
domain. Then, for the next software project<br />
within that organization, the profiles can be used<br />
to guide the SQM processes—that is, to expend<br />
the effort where problems are most likely to occur.<br />
Similarly, benchmarks, or defect counts typical of<br />
that domain, may serve as one aid in determining<br />
when the product is ready for delivery. Discussion<br />
on using data from SQM to improve development<br />
and maintenance processes appears in the<br />
Software Engineering Management and Software<br />
Engineering Process KAs.<br />
<br />
==Software Quality Tools==<br />
<br />
Software quality tools include static and dynamic<br />
analysis tools. Static analysis tools input source<br />
code, perform syntactical and semantic analysis<br />
without executing the code, and present results to<br />
users. There is a large variety in the depth, thoroughness,<br />
and scope of static analysis tools that can be applied to artifacts including models, in<br />
addition to source code. (See the Software Construction,<br />
Software Testing, and Software Maintenance<br />
KAs for descriptions of dynamic analysis<br />
tools.)<br />
<br />
Categories of static analysis tools include the<br />
following:<br />
<br />
* Tools that facilitate and partially automate reviews and inspections of documents and code. These tools can route work to different participants in order to partially automate and control a review process. They allow users to enter defects found during inspections and reviews for later removal.<br />
* Some tools help organizations perform software safety hazard analysis. These tools provide, e.g., automated support for failure mode and effects analysis (FMEA) and fault tree analysis (FTA).<br />
* Tools that support tracking of software problems provide for entry of anomalies discovered during software testing and subsequent analysis, disposition, and resolution. Some tools include support for workflow and for tracking the status of problem resolution.<br />
* Tools that analyze data captured from software engineering environments and software test environments and produce visual displays of quantified data in the form of graphs, charts, and tables. These tools sometimes include the functionality to perform statistical analysis on data sets (for the purpose of discerning trends and making forecasts). Some of these tools provide defect and removal injection rates; defect densities; yields; distribution of defect injection and removal for each of the life cycle phases.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
N. Leveson, ''Safeware: System Safety and Computers'' [20]<br />
<br />
This book describes the importance of software<br />
safety practices and how these practices can be<br />
incorporated into software development projects.<br />
<br />
T. Gilb, ''Principles of Software Engineering Management'' [21].<br />
<br />
This is one of the first books on iterative and<br />
incremental development techniques. The Evo<br />
Method defines quantified goals, frequent timeboxed<br />
iterations, measurements of progress<br />
toward goals, and adaptation of plans based on<br />
actual results.<br />
<br />
T. Gilb and D. Graham, ''Software Inspection'' [22].<br />
<br />
This book introduces measurement and statistical<br />
sampling for reviews and defects. It presents<br />
techniques that produce quantified results for<br />
reducing defects, improving productivity, tracking<br />
projects, and creating documentation.<br />
<br />
K.E. Wiegers, ''Peer Reviews in Software: APractical Guide'' [23].<br />
<br />
This book provides clear, succinct explanations<br />
of different peer review methods distinguished by<br />
level of formality and effectiveness. Pragmatic<br />
guidance for implementing the methods and how<br />
to select which methods are appropriate for given<br />
circumstances is provided.<br />
<br />
N.R. Tague, ''The Quality Toolbox'', 2nd ed., [24].<br />
<br />
Provides a pragmatic how-to explanation of a<br />
comprehensive set of methods, tools, and techniques<br />
for solving quality improvement problems.<br />
Includes the seven basic quality control<br />
tools and many others.<br />
<br />
''IEEE Std. P730-2013 Draft Standard for<br />
Software Quality Assurance Processes'' [5].<br />
<br />
This draft standard expands the SQA processes<br />
identified in IEEE/ISO/IEC 12207-2008. P730<br />
establishes standards for initiating, planning,<br />
controlling, and executing the software quality<br />
assurance processes of a software development<br />
or maintenance project. Approval of this draft<br />
standard is expected in 2014.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=P.B. Crosby<br />
|article=<br />
|publication=Quality Is Free<br />
|edition=<br />
|publisher=McGraw-Hill<br />
|issue=<br />
|date=1979<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=W. Humphrey<br />
|article=<br />
|publication=Managing the Software Process<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=1989<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=S.H. Kan<br />
|article=<br />
|publication=Metrics and Models in Software Quality Engineering<br />
|edition=2nd ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2002<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=4<br />
|author=ISO/IEC<br />
|article=<br />
|publication=25010:2011 Systems and SoftwareEngineering—Systems and Software Quality Requirements and Evaluation(SQuaRE)—Systems and Software Quality<br />
Models<br />
|edition=<br />
|publisher=ISO/IEC<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=IEEE<br />
|article=<br />
|publication=P730™/D8 Draft Standard for Software Quality Assurance Processes<br />
|edition=<br />
|publisher=IEEE<br />
|issue=<br />
|date=2012<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=F. Bott et al<br />
|article=<br />
|publication=Professional Issues in Software Engineering<br />
|edition=3rd ed.<br />
|publisher=Taylor & Francis<br />
|issue=<br />
|date=2002<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=7<br />
|author=D. Galin<br />
|article=<br />
|publication=Software Quality Assurance: From Theory to Implementation<br />
|edition=<br />
|publisher=Pearson Education Limited<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=8<br />
|author=S. Naik and P. Tripathy<br />
|article=<br />
|publication=Software Testing and Quality Assurance: Theory and Practice<br />
|edition=<br />
|publisher=Wiley-Spektrum<br />
|issue=<br />
|date=2008<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=9<br />
|author=P. Clements et al<br />
|article=<br />
|publication=Documenting Software Architectures: Views and Beyond<br />
|edition=2nd ed.<br />
|publisher=Pearson Education<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=10<br />
|author=G. Voland<br />
|article=<br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=RTCA<br />
|article=<br />
|publication=DO-178C, Software Considerations in Airborne Systems and Equipment Certification<br />
|edition=<br />
|publisher=Radio Technical Commission for Aeronautics<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=12<br />
|author=IEEE Std.<br />
|article=<br />
|publication=15026.1-2011 Trial-Use Standard Adoption of ISO/IEC TR 15026-1:2010 Systems and Software Engineering—Systems and Software Assurance—Part 1:<br />
Concepts and Vocabulary<br />
|edition=<br />
|publisher=IEEE<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=13<br />
|author=IEEE Std.<br />
|article=<br />
|publication=12207-2008 (a.k.a. ISO/IEC 12207:2008) Standard for Systems and Software Engineering—Software Life Cycle Processes<br />
|edition=<br />
|publisher=IEEE<br />
|issue=<br />
|date=2008<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=14<br />
|author=ISO<br />
|article=<br />
|publication=9000:2005 Quality Management Systems—Fundamentals and Vocabulary<br />
|edition=<br />
|publisher=ISO<br />
|issue=<br />
|date=2005<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=15<br />
|author=IEEE Std.<br />
|article=<br />
|publication=IEEE Std. 1012-2012 Standard for System and Software Verification and Validation<br />
|edition=<br />
|publisher=IEEE<br />
|issue=<br />
|date=2012<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=16<br />
|author=IEEE Std.<br />
|article=<br />
|publication=1028-2008, Software Reviews and Audits <br />
|edition=<br />
|publisher=IEEE<br />
|issue=<br />
|date=2008<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=17<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide <br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=18<br />
|author=K.E. Wiegers<br />
|article=<br />
|publication=Software Requirements <br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=19<br />
|author=ISO/IEC/IEEE<br />
|article=<br />
|publication=24765:2010 Systems and Software Engineering—Vocabulary <br />
|edition=<br />
|publisher=ISO/IEC/IEEE<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=20<br />
|author=N. Leveson<br />
|article=<br />
|publication=Safeware: System Safety and Computers<br />
|edition=<br />
|publisher=Addison-Wesley Professional<br />
|issue=<br />
|date=1995<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=21<br />
|author=T. Gilb<br />
|article=<br />
|publication=Principles of Software Engineering Management <br />
|edition=<br />
|publisher=Addison-Wesley Professional<br />
|issue=<br />
|date=1988<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=22<br />
|author=T. Gilb and D. Graham<br />
|article=<br />
|publication=Software Inspection <br />
|edition=<br />
|publisher=Addison-Wesley Professional<br />
|issue=<br />
|date=1993<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=23<br />
|author=K. Wiegers<br />
|article=<br />
|publication=Peer Reviews in Software: A Practical Guide<br />
|edition=<br />
|publisher=Addison-Wesley Professional<br />
|issue=<br />
|date=2001<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=24<br />
|author=N.R. Tague<br />
|article=<br />
|publication=The Quality Toolbox<br />
|edition=2nd ed.<br />
|publisher=ASQ Quality Press<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_10:_Software_Quality&diff=872Chapter 10: Software Quality2015-08-29T14:35:07Z<p>Daniel Robbins: /* Software Quality Tools */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}<br />
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}<br />
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}<br />
{{Acronym|name=FTA|description=Fault Tree Analysis}}<br />
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}<br />
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}<br />
{{Acronym|name=QFD|description=Quality Function Deployment}}<br />
{{Acronym|name=SPI|description=Software Process Improvement}}<br />
{{Acronym|name=SQA|description=Software Quality Assurance}}<br />
{{Acronym|name=SQC|description=Software Quality Control}}<br />
{{Acronym|name=SQM|description=Software Quality Management}}<br />
{{Acronym|name=TQM|description=Total Quality Management}}<br />
{{Acronym|name=V&V|description=Verification and Validation}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
What is software quality, and why is it so important<br />
that it is included in many knowledge areas<br />
(KAs) of the ''SWEBOK Guide''?<br />
<br />
One reason is that the term ''software quality'' is<br />
overloaded. Software quality may refer: to desirable<br />
characteristics of software products, to the<br />
extent to which a particular software product possess<br />
those characteristics, and to processes, tools,<br />
and techniques used to achieve those characteristics.<br />
Over the years, authors and organizations<br />
have defined the term quality differently. To Phil<br />
Crosby, it was “conformance to requirements”<br />
[1]. Watts Humphrey refers to it as “achieving<br />
excellent levels of “fitness for use” [2]. Meanwhile,<br />
IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”<br />
[3*, p8].<br />
<br />
More recently, software quality is defined as the<br />
“capability of software product to satisfy stated<br />
and implied needs under specified conditions” [4]<br />
and as “the degree to which a software product<br />
meets established requirements; however, quality<br />
depends upon the degree to which those established<br />
requirements accurately represent stakeholder<br />
needs, wants, and expectations” [5]. Both<br />
definitions embrace the premise of conformance<br />
to requirements. Neither refers to types of requirements<br />
(e.g., functional, reliability, performance,<br />
dependability, or any other characteristic). Significantly,<br />
however, these definitions emphasize that<br />
quality is dependent upon requirements.<br />
<br />
These definitions also illustrate another reason<br />
for the prevalence of software quality throughout<br />
this ''Guide'': a frequent ambiguity of ''software quality'' versus ''software quality requirements''<br />
(“the -''ilities''” is a common shorthand). Software<br />
quality requirements are actually attributes of (or<br />
constraints on) functional requirements (what<br />
the system does). Software requirements may<br />
also specify resource usage, a communication<br />
protocol, or many other characteristics. This KA<br />
attempts clarity by using ''software quality'' in the<br />
broadest sense from the definitions above and<br />
by using ''software quality requirements'' as constraints<br />
on functional requirements. Software<br />
quality is achieved by conformance to all requirements<br />
regardless of what characteristic is specified<br />
or how requirements are grouped or named.<br />
<br />
Software quality is also considered in many of<br />
the SWEBOK KAs because it is a basic parameter<br />
of a software engineering effort. For all engineered<br />
products, the primary goal is delivering<br />
maximum stakeholder value, while balancing the<br />
constraints of development cost and schedule;<br />
this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements.<br />
For software products, stakeholders could<br />
value price (what they pay for the product), lead<br />
time (how fast they get the product), and software<br />
quality.<br />
<br />
This KA addresses definitions and provides an<br />
overview of practices, tools, and techniques for<br />
defining software quality and for appraising the<br />
state of software quality during development,<br />
maintenance, and deployment. Cited references<br />
provide additional details.}}<br />
[[File:Breakdown of Topics for the Software Quality.jpg|thumb|300px|frame|Figure 10.1: Breakdown of Topics for the Software Quality KA]]<br />
{{IntroSection|title=Breakdown of Topics for Software Quality|body=<br />
The breakdown of topics for the Software Quality KA is presented in Figure 10.1.}}<br />
<br />
==Software Quality Fundamentals==<br />
<br />
Reaching agreement on what constitutes quality<br />
for all stakeholders and clearly communicating<br />
that agreement to software engineers require that the many aspects of quality be formally defined<br />
and discussed.<br />
<br />
A software engineer should understand quality<br />
concepts, characteristics, values, and their<br />
application to the software under development or<br />
maintenance. The important concept is that the<br />
software requirements define the required quality<br />
attributes of the software. Software requirements<br />
influence the measurement methods and acceptance<br />
criteria for assessing the degree to which<br />
the software and related documentation achieve<br />
the desired quality levels.<br />
<br />
===Software Engineering Culture and Ethics===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=6|parts=c2s3.5}}}}<br />
<br />
Software engineers are expected to share a commitment<br />
to software quality as part of their culture.<br />
A healthy software engineering culture includes<br />
many characteristics, including the understanding<br />
that tradeoffs among cost, schedule, and quality<br />
are a basic tenant of the engineering of any product.<br />
A strong software engineering ethic assumes that engineers accurately report information, conditions,<br />
and outcomes related to quality.<br />
<br />
Ethics also play a significant role in software<br />
quality, the culture, and the attitudes of software<br />
engineers. The IEEE Computer Society and the<br />
ACM have developed a code of ethics and professional<br />
practice (see Codes of Ethics and Professional<br />
Conduct in the Software Engineering<br />
Professional Practice KA).<br />
<br />
===Value and Costs of Quality===<br />
{{RightSection|{{referenceLink|number=7|parts=c17, c22}}}}<br />
<br />
Defining and then achieving software quality is<br />
not simple. Quality characteristics may or may<br />
not be required, or they may be required to a<br />
greater or lesser degree, and tradeoffs may be<br />
made among them. To help determine the level<br />
of software quality, i.e., achieving stakeholder<br />
value, this section presents cost of software quality<br />
(CoSQ): a set of measurements derived from<br />
the economic assessment of software quality<br />
development and maintenance processes. The<br />
CoSQ measurements are examples of process<br />
measurements that may be used to infer characteristics<br />
of a product.<br />
<br />
The premise underlying the CoSQ is that the<br />
level of quality in a software product can be<br />
inferred from the cost of activities related to dealing<br />
with the consequences of poor quality. Poor<br />
quality means that the software product does not<br />
fully “satisfy stated and implied needs” or “established<br />
requirements.” There are four cost of quality<br />
categories: prevention, appraisal, internal failure,<br />
and external failure.<br />
<br />
Prevention costs include investments in software<br />
process improvement efforts, quality infrastructure,<br />
quality tools, training, audits, and management<br />
reviews. These costs are usually not specific<br />
to a project; they span the organization. Appraisal<br />
costs arise from project activities that find defects.<br />
These appraisal activities can be categorized into<br />
costs of reviews (design, peer) and costs of testing<br />
(software unit testing, software integration,<br />
system level testing, acceptance testing); appraisal<br />
costs would be extended to subcontracted software<br />
suppliers. Costs of internal failures are those that<br />
are incurred to fix defects found during appraisal<br />
activities and discovered prior to delivery of the software product to the customer. External failure<br />
costs include activities to respond to software<br />
problems discovered after delivery to the customer. <br />
<br />
Software engineers should be able to use CoSQ<br />
methods to ascertain levels of software quality<br />
and should also be able to present quality alternatives<br />
and their costs so that tradeoffs between<br />
cost, schedule, and delivery of stakeholder value<br />
can be made.<br />
<br />
===Models and Quality Characteristics===<br />
{{RightSection|{{referenceLink|number=3|parts=c24s1}} {{referenceLink|number=7|parts=c2s4}} {{referenceLink|number=8|parts=c17}}}}<br />
<br />
Terminology for software quality characteristics<br />
differs from one taxonomy (or model of software<br />
quality) to another, each model perhaps having<br />
a different number of hierarchical levels and a<br />
different total number of characteristics. Various<br />
authors have produced models of software quality<br />
characteristics or attributes that can be useful<br />
for discussing, planning, and rating the quality<br />
of software products. ISO/IEC 25010: 2011 [4]<br />
defines product quality and quality in use as two<br />
related quality models. Appendix B in the SWEBOK<br />
Guide provides a list of applicable standards<br />
for each KA. Standards for this KA cover various<br />
ways of characterizing software quality.<br />
<br />
====Software Process Quality====<br />
<br />
Software quality management and software engineering<br />
process quality have a direct bearing on<br />
the quality of the software product.<br />
<br />
Models and criteria that evaluate the capabilities<br />
of software organizations are primarily project<br />
organization and management considerations<br />
and, as such, are covered in the Software Engineering<br />
Management and Software Engineering<br />
Process KAs.<br />
<br />
It is not possible to completely distinguish process<br />
quality from product quality because process<br />
outcomes include products. Determining whether<br />
a process has the capability to consistently produce<br />
products of desired quality is not simple.<br />
<br />
The software engineering process, discussed<br />
in the Software Engineering Process KA, influences<br />
the quality characteristics of software products,<br />
which in turn affect quality as perceived by<br />
stakeholders.<br />
<br />
====Software Product Quality====<br />
<br />
The software engineer, first of all, must determine<br />
the real purpose of the software. In this regard,<br />
stakeholder requirements are paramount, and they<br />
include quality requirements in addition to functional<br />
requirements. Thus, software engineers<br />
have a responsibility to elicit quality requirements<br />
that may not be explicit at the outset and to understand<br />
their importance as well as the level of difficulty<br />
in attaining them. All software development<br />
processes (e.g., eliciting requirements, designing,<br />
constructing, building, checking, improving quality)<br />
are designed with these quality requirements<br />
in mind and may carry additional development<br />
costs if attributes such as safety, security, and<br />
dependability are important. The additional development<br />
costs help ensure that quality obtained can<br />
be traded off against the anticipated benefits.<br />
<br />
The term work-product means any artifact that<br />
is the outcome of a process used to create the<br />
final software product. Examples of a work-product<br />
include a system/subsystem specification, a<br />
software requirements specification for a software<br />
component of a system, a software design<br />
description, source code, software test documentation,<br />
or reports. While some treatments of quality<br />
are described in terms of final software and<br />
system performance, sound engineering practice<br />
requires that intermediate work-products relevant<br />
to quality be evaluated throughout the software<br />
engineering process.<br />
<br />
===Software Quality Improvement===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=9|parts=c24}} {{referenceLink|number=10|parts=c11s2.4}}}}<br />
<br />
The quality of software products can be improved<br />
through preventative processes or an iterative<br />
process of continual improvement, which<br />
requires management control, coordination, and<br />
feedback from many concurrent processes: (1)<br />
the software life cycle processes, (2) the process<br />
of fault/defect detection, removal, and prevention,<br />
and (3) the quality improvement process.<br />
<br />
The theory and concepts behind quality<br />
improvement—such as building in quality<br />
through the prevention and early detection of<br />
defects, continual improvement, and stakeholder<br />
focus—are pertinent to software engineering.<br />
These concepts are based on the work of experts in quality who have stated that the quality of a<br />
product is directly linked to the quality of the<br />
process used to create it. Approaches such as the<br />
Deming improvement cycle of Plan-Do-Check-<br />
Act (PDCA), evolutionary delivery, kaizen, and<br />
quality function deployment (QFD) offer techniques<br />
to specify quality objectives and determine<br />
whether they are met. The Software Engineering<br />
Institute’s IDEAL is another method [7*]. Quality<br />
management is now recognized by the '''SWEBOK Guide'' as an important discipline.<br />
<br />
Management sponsorship supports process and<br />
product evaluations and the resulting findings.<br />
Then an improvement program is developed<br />
identifying detailed actions and improvement<br />
projects to be addressed in a feasible time frame.<br />
Management support implies that each improvement<br />
project has enough resources to achieve the<br />
goal defined for it. Management sponsorship is<br />
solicited frequently by implementing proactive<br />
communication activities.<br />
<br />
===Software Safety===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s3}}}}<br />
<br />
Safety-critical systems are those in which a system<br />
failure could harm human life, other living<br />
things, physical structures, or the environment.<br />
The software in these systems is safety-critical.<br />
There are increasing numbers of applications<br />
of safety-critical software in a growing number<br />
of industries. Examples of systems with safetycritical<br />
software include mass transit systems,<br />
chemical manufacturing plants, and medical<br />
devices. The failure of software in these systems<br />
could have catastrophic effects. There are industry<br />
standards, such as DO-178C [11], and emerging<br />
processes, tools, and techniques for developing<br />
safetycritical software. The intent of these<br />
standards, tools, and techniques is to reduce the<br />
risk of injecting faults into the software and thus<br />
improve software reliability.<br />
<br />
Safety-critical software can be categorized as<br />
direct or indirect. Direct is that software embedded<br />
in a safety-critical system, such as the flight<br />
control computer of an aircraft. Indirect includes<br />
software applications used to develop safetycritical<br />
software. Indirect software is included in<br />
software engineering environments and software<br />
test environments.<br />
<br />
Three complementary techniques for reducing<br />
the risk of failure are avoidance, detection<br />
and removal, and damage limitation. These<br />
techniques impact software functional requirements,<br />
software performance requirements, and<br />
development processes. Increasing levels of risk<br />
imply increasing levels of software quality assurance<br />
and control techniques such as inspections.<br />
Higher risk levels may necessitate more thorough<br />
inspections of requirements, design, and code<br />
or the use of more formal analytical techniques.<br />
Another technique for managing and controlling<br />
software risk is building assurance cases. An<br />
assurance case is a reasoned, auditable artifact<br />
created to support the contention that its claim<br />
or claims are satisfied. It contains the following<br />
and their relationships: one or more claims about<br />
properties; arguments that logically link the evidence<br />
and any assumptions to the claims; and a<br />
body of evidence and assumptions supporting<br />
these arguments [12].<br />
<br />
==Software Quality Management Processes==<br />
<br />
Software quality management is the collection of<br />
all processes that ensure that software products,<br />
services, and life cycle process implementations<br />
meet organizational software quality objectives<br />
and achieve stakeholder satisfaction [13, 14].<br />
SQM defines processes, process owners, requirements<br />
for the processes, measurements of the<br />
processes and their outputs, and feedback channels<br />
throughout the whole software life cycle.<br />
<br />
SQM comprises four subcategories: software<br />
quality planning, software quality assurance<br />
(SQA), software quality control (SQC), and software<br />
process improvement (SPI). Software quality<br />
planning includes determining which quality<br />
standards are to be used, defining specific quality<br />
goals, and estimating the effort and schedule of<br />
software quality activities. In some cases, software<br />
quality planning also includes defining the<br />
software quality processes to be used. SQA activities<br />
define and assess the adequacy of software<br />
processes to provide evidence that establishes<br />
confidence that the software processes are appropriate<br />
for and produce software products of suitable<br />
quality for their intended purposes [5]. SQC<br />
activities examine specific project artifacts (documents<br />
and executables) to determine whether they comply with standards established for the project<br />
(including requirements, constraints, designs,<br />
contracts, and plans). SQC evaluates intermediate<br />
products as well as the final products.<br />
<br />
The fourth SQM category dealing with improvement<br />
has various names within the software industry,<br />
including SPI, software quality improvement,<br />
and software corrective and preventive action. The<br />
activities in this category seek to improve process<br />
effectiveness, efficiency, and other characteristics<br />
with the ultimate goal of improving software<br />
quality. Although SPI could be included in any of<br />
the first three categories, an increasing number<br />
of organizations organize SPI into a separate category<br />
that may span across many projects (see the<br />
Software Engineering Process KA).<br />
<br />
Software quality processes consist of tasks<br />
and techniques to indicate how software plans<br />
(e.g., software management, development, quality<br />
management, or configuration management<br />
plans) are being implemented and how well the<br />
intermediate and final products are meeting their<br />
specified requirements. Results from these tasks<br />
are assembled in reports for management before<br />
corrective action is taken. The management of<br />
an SQM process is tasked with ensuring that the<br />
results of these reports are accurate.<br />
<br />
Risk management can also play an important<br />
role in delivering quality software. Incorporating<br />
disciplined risk analysis and management techniques<br />
into the software life cycle processes can<br />
help improve product quality (see the Software<br />
Engineering Management KA for related material<br />
on risk management).<br />
<br />
===Software Quality Assurance===<br />
{{RightSection|{{referenceLink|number=7|parts=c4–c6, c11, c12, c26–27}}}}<br />
<br />
To quell a widespread misunderstanding, software<br />
quality assurance is not testing. software<br />
quality assurance (SQA) is a set of activities that<br />
define and assess the adequacy of software processes<br />
to provide evidence that establishes confidence<br />
that the software processes are appropriate<br />
and produce software products of suitable quality<br />
for their intended purposes. A key attribute of<br />
SQA is the objectivity of the SQA function with<br />
respect to the project. The SQA function may<br />
also be organizationally independent of the project;<br />
that is, free from technical, managerial, and financial pressures from the project [5]. SQA has<br />
two aspects: product assurance and process assurance,<br />
which are explained in section 2.3.<br />
<br />
The software quality plan (in some industry<br />
sectors it is termed the software quality assurance<br />
plan) defines the activities and tasks employed<br />
to ensure that software developed for a specific<br />
product satisfies the project’s established requirements<br />
and user needs within project cost and<br />
schedule constraints and is commensurate with<br />
project risks. The SQAP first ensures that quality<br />
targets are clearly defined and understood.<br />
<br />
The SQA plan’s quality activities and tasks are<br />
specified with their costs, resource requirements,<br />
objectives, and schedule in relation to related<br />
objectives in the software engineering management,<br />
software development, and software maintenance<br />
plans. The SQA plan should be consistent<br />
with the software configuration management<br />
plan (see the Software Configuration Management<br />
KA). The SQA plan identifies documents,<br />
standards, practices, and conventions governing<br />
the project and how these items are checked and<br />
monitored to ensure adequacy and compliance.<br />
The SQA plan also identifies measures; statistical<br />
techniques; procedures for problem reporting and<br />
corrective action; resources such as tools, techniques,<br />
and methodologies; security for physical<br />
media; training; and SQA reporting and documentation.<br />
Moreover, the SQA plan addresses<br />
the software quality assurance activities of any<br />
other type of activity described in the software<br />
plans—such as procurement of supplier software<br />
for the project, commercial off-the-shelf software<br />
(COTS) installation, and service after delivery of<br />
the software. It can also contain acceptance criteria<br />
as well as reporting and management activities<br />
that are critical to software quality.<br />
<br />
===Verification & Validation===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s2.3, c8, c15s1.1, c21s3.3}}}}<br />
<br />
As stated in [15],<br />
<br />
* The purpose of V&V is to help the development organization build quality into the system during the life cycle. V&V processes provide an objective assessment of products and processes throughout the life cycle. This assessment demonstrates whether the requirements are correct, complete, accurate, consistent, and testable. The V&V processes determine whether the development products of a given activity<br />
conform to the requirements of that activity and whether the product satisfies its intended use and user needs.<br />
<br />
Verification is an attempt to ensure that the<br />
product is built correctly, in the sense that the<br />
output products of an activity meet the specifications<br />
imposed on them in previous activities.<br />
Validation is an attempt to ensure that the right<br />
product is built—that is, the product fulfills its<br />
specific intended purpose. Both the verification<br />
process and the validation process begin early<br />
in the development or maintenance phase. They<br />
provide an examination of key product features<br />
in relation to both the product’s immediate predecessor<br />
and the specifications to be met.<br />
<br />
The purpose of planning V&V is to ensure that<br />
each resource, role, and responsibility is clearly<br />
assigned. The resulting V&V plan documents<br />
describe the various resources and their roles and<br />
activities, as well as the techniques and tools to be<br />
used. An understanding of the different purposes of<br />
each V&V activity helps in the careful planning of<br />
the techniques and resources needed to fulfill their<br />
purposes. The plan also addresses the management,<br />
communication, policies, and procedures of<br />
the V&V activities and their interaction, as well as<br />
defect reporting and documentation requirements.<br />
<br />
===Reviews and Audits===<br />
{{RightSection|{{referenceLink|number=9|parts=c24s3}} {{referenceLink|number=16}}}}<br />
<br />
Reviews and audit processes are broadly defined<br />
as static—meaning that no software programs or<br />
models are executed—examination of software<br />
engineering artifacts with respect to standards that<br />
have been established by the organization or project<br />
for those artifacts. Different types of reviews<br />
and audits are distinguished by their purpose, levels<br />
of independence, tools and techniques, roles,<br />
and by the subject of the activity. Product assurance<br />
and process assurance audits are typically<br />
conducted by software quality assurance (SQA)<br />
personnel who are independent of development teams. Management reviews are conducted by<br />
organizational or project management. The engineering<br />
staff conducts technical reviews.<br />
<br />
* Management reviews evaluate actual project results with respect to plans.<br />
* Technical reviews (including inspections, walkthrough, and desk checking) examine engineering work-products.<br />
* Process assurance audits. SQA process assurance activities make certain that the processes used to develop, install, operate, and maintain software conform to contracts, comply with any imposed laws, rules, and regulations and are adequate, efficient and effective for their intended purpose [5].<br />
* Product assurance audits. SQA product assurance activities make certain to provide evidence that software products and related documentation are identified in and comply with contracts; and ensure that nonconformances are identified and addressed [5].<br />
<br />
====Management Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a management review is to monitor progress, determine the status of plans and schedules, and evaluate the effectiveness<br />
of management processes, tools and techniques. Management reviews compare actual project results against plans to determine the status of projects or maintenance efforts. The main parameters of management reviews are project cost, schedule, scope, and quality. Management reviews evaluate decisions about corrective actions, changes in the allocation of resources, or changes to the scope of the project.<br />
<br />
Inputs to management reviews may include<br />
audit reports, progress reports, V&V reports, and<br />
plans of many types, including risk management,<br />
project management, software configuration<br />
management, software safety, and risk assessment,<br />
among others. (Refer to the Software Engineering<br />
Management and the Software Configuration<br />
Management KAs for related material.)<br />
<br />
====Technical Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a technical review is to evaluate a software product by a team of qualified personnel to determine its suitability for its intended use and identify discrepancies from specifications and standards. It provides management with evidence to confirm the technical status of the project.<br />
<br />
Although any work-product can be reviewed,<br />
technical reviews are performed on the main<br />
software engineering work-products of software<br />
requirements and software design.<br />
<br />
Purpose, roles, activities, and most importantly<br />
the level of formality distinguish different types<br />
of technical reviews. Inspections are the most formal,<br />
walkthroughs less, and pair reviews or desk<br />
checks are the least formal.<br />
<br />
Examples of specific roles include a decision<br />
maker (i.e., software lead), a review leader, a<br />
recorder, and checkers (technical staff members<br />
who examine the work-products). Reviews are<br />
also distinguished by whether meetings (face to<br />
face or electronic) are included in the process. In<br />
some review methods checkers solitarily examine<br />
work-products and send their results back to<br />
a coordinator. In other methods checkers work<br />
cooperatively in meetings. A technical review<br />
may require that mandatory inputs be in place in<br />
order to proceed:<br />
<br />
* Statement of objectives<br />
* Specific software product<br />
* Specific project management plan<br />
* Issues list associated with this product<br />
* Technical review procedure.<br />
<br />
The team follows the documented review procedure.<br />
The technical review is completed once<br />
all the activities listed in the examination have<br />
been completed.<br />
<br />
Technical reviews of source code may include a<br />
wide variety of concerns such as analysis of algorithms,<br />
utilization of critical computer resources,<br />
adherence to coding standards, structure and organization of code for testability, and safetycritical<br />
considerations.<br />
<br />
Note that technical reviews of source code or<br />
design models such as UML are also termed static<br />
analysis (see topic 3, Practical Considerations).<br />
<br />
====Inspections====<br />
<br />
“The purpose of an inspection is to detect and<br />
identify software product anomalies” [16*].<br />
Some important differentiators of inspections as<br />
compared to other types of technical reviews are<br />
these:<br />
<br />
* 1. Rules. Inspections are based upon examining a work-product with respect to a defined set of criteria specified by the organization. Sets of rules can be defined for different types of workproducts (e.g., rules for requirements,architecture descriptions, source code).<br />
* 2. Sampling. Rather that attempt to examine every word and figure in a document, the inspection process allows checkers to evaluate defined subsets (samples) of the documents under review.<br />
* 3. Peer. Individuals holding management positions over members of the inspection team do not participate in the inspection. This is<br />
a key distinction between peer review and management review.<br />
* 4. Led. An impartial moderator who is trained in inspection techniques leads inspection meetings.<br />
* 5. Meeting. The inspection process includes meetings (face to face or electronic) conducted by a moderator according to a formal procedure in which inspection team members report the anomalies they have found and other issues.<br />
<br />
Software inspections always involve the author<br />
of an intermediate or final product; other reviews<br />
might not. Inspections also include an inspection<br />
leader, a recorder, a reader, and a few (two to five)<br />
checkers (inspectors). The members of an inspection<br />
team may possess different expertise, such as<br />
domain expertise, software design method expertise,<br />
or programming language expertise. Inspections<br />
are usually conducted on one relatively small section of the product at a time (samples).<br />
Each team member examines the software product<br />
and other review inputs prior to the review<br />
meeting, perhaps by applying an analytical technique<br />
(see section 3.3.3) to a small section of<br />
the product or to the entire product with a focus<br />
on only one aspect—e.g., interfaces. During the<br />
inspection, the moderator conducts the session<br />
and verifies that everyone has prepared for the<br />
inspection and conducts the session. The inspection<br />
recorder documents anomalies found. A set<br />
of rules, with criteria and questions germane to<br />
the issues of interest, is a common tool used in<br />
inspections. The resulting list often classifies the<br />
anomalies (see section 3.2, Defect Characterization)<br />
and is reviewed for completeness and accuracy<br />
by the team. The inspection exit decision<br />
corresponds to one of the following options:<br />
<br />
* 1. Accept with no or, at most, minor reworking<br />
* 2. Accept with rework verification<br />
* 3. Reinspect.<br />
<br />
====Walkthroughs====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a systematic walk-through is to evaluate a software product. A walkthrough may be conducted for the purpose of educating an audience regarding a software product.<br />
<br />
Walkthroughs are distinguished from inspections.<br />
The main difference is that the author presents<br />
the work-product to the other participants in<br />
a meeting (face to face or electronic). Unlike an<br />
inspection, the meeting participants may not have<br />
necessarily seen the material prior to the meeting.<br />
The meetings may be conducted less formally.<br />
The author takes the role of explaining and<br />
showing the material to participants and solicits<br />
feedback. Like inspections, walkthroughs may be<br />
conducted on any type of work-product including<br />
project plan, requirements, design, source code,<br />
and test reports.<br />
<br />
====Process Assurance and Product Assurance Audits====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes<br />
to applicable regulations, standards, guidelines, plans, and procedures.<br />
<br />
Process assurance audits determine the adequacy<br />
of plans, schedules, and requirements to achieve<br />
project objectives [5]. The audit is a formally<br />
organized activity with participants having specific<br />
roles—such as lead auditor, another auditor, a<br />
recorder, or an initiator—and including a representative<br />
of the audited organization. Audits identify<br />
instances of nonconformance and produce a report<br />
requiring the team to take corrective action.<br />
<br />
While there may be many formal names for<br />
reviews and audits, such as those identified in the<br />
standard [16*], the important point is that they<br />
can occur on almost any product at any stage of<br />
the development or maintenance process.<br />
<br />
==Practical Considerations==<br />
===Software Quality Requirements===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s1}} {{referenceLink|number=18|parts=c12}} {{referenceLink|number=17|parts=c15s3.2.2, c15s3.3.1, c16s9.10}}}}<br />
====Influence Factors====<br />
Various factors influence planning, management,<br />
and selection of SQM activities and techniques,<br />
including<br />
<br />
* the domain of the system in which the software resides; the system functions could be safety-critical, mission-critical, businesscritical,security-critical<br />
* the physical environment in which the software system resides<br />
* system and software functional (what the system does) and quality (how well the system performs its functions) requirements<br />
* the commercial (external) or standard (internal) components to be used in the system<br />
* the specific software engineering standards applicable<br />
* the methods and software tools to be used for development and maintenance and for quality evaluation and improvement<br />
* the budget, staff, project organization, plans, and scheduling of all processes<br />
* the intended users and use of the system<br />
* the integrity level of the system.<br />
<br />
Information on these factors influences how<br />
the SQM processes are organized and documented,<br />
how specific SQM activities are selected,<br />
what resources are needed, and which of those<br />
resources impose bounds on the efforts.<br />
<br />
====Dependability====<br />
<br />
In cases where system failure may have extremely<br />
severe consequences, overall dependability (hardware,<br />
software, and human or operational) is the<br />
main quality requirement over and above basic<br />
functionality. This is the case for the following<br />
reasons: system failures affect a large number of<br />
people; users often reject systems that are unreliable,<br />
unsafe, or insecure; system failure costs<br />
may be enormous; and undependable systems<br />
may cause information loss. System and software<br />
dependability include such characteristics<br />
as availability, reliability, safety, and security.<br />
When developing dependable software, tools and<br />
techniques can be applied to reduce the risk of<br />
injecting faults into the intermediate deliverables<br />
or the final software product. Verification, validation,<br />
and testing processes, techniques, methods,<br />
and tools identify faults that impact dependability<br />
as early as possible in the life cycle. Additionally,<br />
mechanisms may need to be in place in the<br />
software to guard against external attacks and to<br />
tolerate faults.<br />
<br />
====Integrity Levels of Software====<br />
<br />
Defining integrity levels is a method of risk<br />
management.<br />
<br />
* Software integrity levels are a range of values that represent software complexity, criticality, risk, safety level, security level, desired performance, reliability, or other project-unique characteristics that define the importance of the software to the user and acquirer. The characteristics used to determine software integrity level vary depending on the intended application and use of the system. The software is a part of the system, and its integrity level is to be determined as a part of that system.<br />
<br />
The assigned software integrity levels may<br />
change as the software evolves. Design, coding,<br />
procedural, and technology features implemented<br />
in the system or software can raise or lower the<br />
assigned software integrity levels. The software<br />
integrity levels established for a project result<br />
from agreements among the acquirer, supplier,<br />
developer, and independent assurance authorities.<br />
A software integrity level scheme is a tool used in<br />
determining software integrity levels. [5]<br />
<br />
As noted in [17*], “the integrity levels can be<br />
applied during development to allocate additional<br />
verification and validation efforts to high-integrity<br />
components.”<br />
<br />
===Defect Characterization===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s3, c8s8, c10s2}}}}<br />
<br />
Software quality evaluation (i.e., software quality<br />
control) techniques find defects, faults and failures.<br />
Characterizing these techniques leads to an<br />
understanding of the product, facilitates corrections<br />
to the process or the product, and informs<br />
management and other stakeholders of the status<br />
of the process or product. Many taxonomies<br />
exist and, while attempts have been made to gain<br />
consensus, the literature indicates that there are<br />
quite a few in use. Defect characterization is also<br />
used in audits and reviews, with the review leader<br />
often presenting a list of issues provided by team<br />
members for consideration at a review meeting.<br />
<br />
As new design methods and languages evolve,<br />
along with advances in overall software technologies,<br />
new classes of defects appear, and a great<br />
deal of effort is required to interpret previously<br />
defined classes. When tracking defects, the software<br />
engineer is interested in not only the number<br />
of defects but also the types. Information alone,<br />
without some classification, may not be sufficient<br />
to identify the underlying causes of the defects.<br />
Specific types of problems need to be grouped to<br />
identify trends over time. The point is to establish<br />
a defect taxonomy that is meaningful to the organization<br />
and to software engineers.<br />
<br />
Software quality control activities discover information<br />
at all stages of software development and<br />
maintenance. In some cases, the word ''defect'' is<br />
overloaded to refer to different types of anomalies.<br />
However, different engineering cultures and standards<br />
may use somewhat different meanings for<br />
these terms. The variety of terms prompts this section<br />
to provide a widely used set of definitions [19]:<br />
<br />
* ''Computational Error'': “the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.”<br />
* ''Error'': “A human action that produces an incorrect result.” A slip or mistake that a person makes. Also called human error.<br />
* ''Defect'': An “imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced.” A defect is caused by a person committing an error.<br />
* ''Fault'': A defect in source code. An “incorrect step, process, or data definition in computer program.” The encoding of a human error in source code. Fault is the formal name of a bug.<br />
* ''Failure'': An “event in which a system or system component does not perform a required function within specified limits.” A failure is<br />
produced when a fault is encountered by the processor under specified conditions.<br />
<br />
Using these definitions three widely used software<br />
quality measurements are defect density<br />
(number of defects per unit size of documents),<br />
fault density (number of faults per 1K lines of<br />
code), and failure intensity (failures per use-hour<br />
or per test-hour). Reliability models are built<br />
from failure data collected during software testing<br />
or from software in service and thus can be<br />
used to estimate the probability of future failures<br />
and to assist in decisions on when to stop testing.<br />
<br />
One probable action resulting from SQM findings<br />
is to remove the defects from the product<br />
under examination (e.g., find and fix bugs, create<br />
new build). Other activities attempt to eliminate the causes of the defects—for example, root cause<br />
analysis (RCA). RCA activities include analyzing<br />
and summarizing the findings to find root causes<br />
and using measurement techniques to improve<br />
the product and the process as well as to track the<br />
defects and their removal. Process improvement<br />
is primarily discussed in the Software Engineering<br />
Process KA, with the SQM process being a<br />
source of information.<br />
<br />
Data on inadequacies and defects found by<br />
software quality control techniques may be lost<br />
unless they are recorded. For some techniques<br />
(e.g., technical reviews, audits, inspections),<br />
recorders are present to set down such information,<br />
along with issues and decisions. When automated<br />
tools are used (see topic 4, Software Quality<br />
Tools), the tool output may provide the defect<br />
information. Reports about defects are provided<br />
to the management of the organization.<br />
<br />
===Software Quality Management Techniques===<br />
{{RightSection|{{referenceLink|number=7|parts=c7s3}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=c12s5, c15s1, p417}}{{referenceLink|number=16}}}}<br />
<br />
Software quality control techniques can be categorized<br />
in many ways, but a straightforward<br />
approach uses just two categories: static and<br />
dynamic. Dynamic techniques involve executing<br />
the software; static techniques involve analyzing<br />
documents<br />
<br />
====Static Techniques====<br />
<br />
Static techniques examine software documentation<br />
(including requirements, interface specifications,<br />
designs, and models) and software source<br />
code without executing the code. There are many<br />
tools and techniques for statically examining software<br />
work-products (see section 2.3.2). In addition,<br />
tools that analyze source code control flow<br />
and search for dead code are considered to be<br />
static analysis tools because they do not involve<br />
executing the software code.<br />
<br />
Other, more formal, types of analytical techniques<br />
are known as formal methods. They are<br />
notably used to verify software requirements and<br />
designs. They have mostly been used in the verification<br />
of crucial parts of critical systems, such<br />
as specific security and safety requirements. (See also Formal Methods in the Software Engineering<br />
Models and Methods KA.)<br />
<br />
====Dynamic Techniques====<br />
<br />
Dynamic techniques involve executing the software<br />
code. Different kinds of dynamic techniques<br />
are performed throughout the development and<br />
maintenance of software. Generally, these are<br />
testing techniques, but techniques such as simulation<br />
and model analysis may be considered<br />
dynamic (see the Software Engineering Models<br />
and Methods KA). Code reading is considered a<br />
static technique, but experienced software engineers<br />
may execute the code as they read through<br />
it. Code reading may utilize dynamic techniques.<br />
This discrepancy in categorizing indicates that<br />
people with different roles and experience in the<br />
organization may consider and apply these techniques<br />
differently.<br />
<br />
Different groups may perform testing during<br />
software development, including groups independent<br />
of the development team. The Software<br />
Testing KA is devoted entirely to this subject.<br />
<br />
====Testing====<br />
<br />
Two types of testing may fall under V&V because<br />
of their responsibility for the quality of the materials<br />
used in the project:<br />
<br />
* Evaluation and tests of tools to be used on the project<br />
* Conformance tests (or review of conformance tests) of components and COTS products to be used in the product<br />
<br />
Sometimes an independent (third-party or<br />
IV&V) organization may be tasked to perform<br />
testing or to monitor the test process V&V may<br />
be called upon to evaluate the testing itself: adequacy<br />
of plans, processes, and procedures, and<br />
adequacy and accuracy of results.<br />
<br />
The third party is not the developer, nor is it<br />
associated with the development of the product.<br />
Instead, the third party is an independent facility,<br />
usually accredited by some body of authority.<br />
Their purpose is to test a product for conformance<br />
to a specific set of requirements (see the Software Testing KA).<br />
<br />
===Software Quality Measurement===<br />
{{RightSection|{{referenceLink|number=3|parts=c4}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=p90}}}}<br />
<br />
Software quality measurements are used to<br />
support decision-making. With the increasing<br />
sophistication of software, questions of quality<br />
go beyond whether or not the software works to<br />
how well it achieves measurable quality goals.<br />
<br />
Decisions supported by software quality measurement<br />
include determining levels of software<br />
quality (notably because models of software<br />
product quality include measures to determine<br />
the degree to which the software product achieves<br />
quality goals); managerial questions about effort,<br />
cost, and schedule; determining when to stop testing<br />
and release a product (see Termination under<br />
section 5.1, Practical Considerations, in the Software<br />
Testing KA); and determining the efficacy<br />
of process improvement efforts.<br />
<br />
The cost of SQM processes is an issue frequently<br />
raised in deciding how a project or a software<br />
development and maintenance group should<br />
be organized. Often, generic models of cost are<br />
used, which are based on when a defect is found<br />
and how much effort it takes to fix the defect relative<br />
to finding the defect earlier in the development<br />
process. Software quality measurement data<br />
collected internally may give a better picture of<br />
cost within this project or organization.<br />
<br />
While the software quality measurement data<br />
may be useful in itself (e.g., the number of defective<br />
requirements or the proportion of defective<br />
requirements), mathematical and graphical techniques<br />
can be applied to aid in the interpretation<br />
of the measures (see the Engineering Foundations<br />
KA). These techniques include<br />
<br />
* descriptive statistics based (e.g., Pareto analysis, run charts, scatter plots, normal distribution)<br />
* statistical tests (e.g., the binomial test, chisquared test)<br />
* trend analysis (e.g., control charts; see''The Quality Toolbox'' in the list of further readings)<br />
* prediction (e.g., reliability models).<br />
<br />
Descriptive statistics-based techniques and<br />
tests often provide a snapshot of the more troublesome areas of the software product under<br />
examination. The resulting charts and graphs<br />
are visualization aids, which the decision makers<br />
can use to focus resources and conduct process<br />
improvements where they appear to be most<br />
needed. Results from trend analysis may indicate<br />
that a schedule is being met, such as in testing, or<br />
that certain classes of faults may become more<br />
likely to occur unless some corrective action is<br />
taken in development. The predictive techniques<br />
assist in estimating testing effort and schedule<br />
and in predicting failures. More discussion on<br />
measurement in general appears in the Software<br />
Engineering Process and Software Engineering<br />
Management KAs. More specific information on<br />
testing measurement is presented in the Software<br />
Testing KA.<br />
<br />
Software quality measurement includes measuring<br />
defect occurrences and applying statistical<br />
methods to understand the types of defects that<br />
occur most frequently. This information may be<br />
used by software process improvement for determining<br />
methods to prevent, reduce, or eliminate<br />
their recurrence. They also aid in understanding<br />
trends, how well detection and containment techniques<br />
are working, and how well the development<br />
and maintenance processes are progressing.<br />
<br />
From these measurement methods, defect<br />
profiles can be developed for a specific application<br />
domain. Then, for the next software project<br />
within that organization, the profiles can be used<br />
to guide the SQM processes—that is, to expend<br />
the effort where problems are most likely to occur.<br />
Similarly, benchmarks, or defect counts typical of<br />
that domain, may serve as one aid in determining<br />
when the product is ready for delivery. Discussion<br />
on using data from SQM to improve development<br />
and maintenance processes appears in the<br />
Software Engineering Management and Software<br />
Engineering Process KAs.<br />
<br />
==Software Quality Tools==<br />
<br />
Software quality tools include static and dynamic<br />
analysis tools. Static analysis tools input source<br />
code, perform syntactical and semantic analysis<br />
without executing the code, and present results to<br />
users. There is a large variety in the depth, thoroughness,<br />
and scope of static analysis tools that can be applied to artifacts including models, in<br />
addition to source code. (See the Software Construction,<br />
Software Testing, and Software Maintenance<br />
KAs for descriptions of dynamic analysis<br />
tools.)<br />
<br />
Categories of static analysis tools include the<br />
following:<br />
<br />
* Tools that facilitate and partially automate reviews and inspections of documents and code. These tools can route work to different participants in order to partially automate and control a review process. They allow users to enter defects found during inspections and reviews for later removal.<br />
* Some tools help organizations perform software safety hazard analysis. These tools provide, e.g., automated support for failure mode and effects analysis (FMEA) and fault tree analysis (FTA).<br />
* Tools that support tracking of software problems provide for entry of anomalies discovered during software testing and subsequent analysis, disposition, and resolution. Some tools include support for workflow and for tracking the status of problem resolution.<br />
* Tools that analyze data captured from software engineering environments and software test environments and produce visual displays of quantified data in the form of graphs, charts, and tables. These tools sometimes include the functionality to perform statistical analysis on data sets (for the purpose of discerning trends and making forecasts). Some of these tools provide defect and removal injection rates; defect densities; yields; distribution of defect injection and removal for each of the life cycle phases.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
N. Leveson, ''Safeware: System Safety and Computers'' [20]<br />
<br />
This book describes the importance of software<br />
safety practices and how these practices can be<br />
incorporated into software development projects.<br />
<br />
T. Gilb, ''Principles of Software Engineering Management'' [21].<br />
<br />
This is one of the first books on iterative and<br />
incremental development techniques. The Evo<br />
Method defines quantified goals, frequent timeboxed<br />
iterations, measurements of progress<br />
toward goals, and adaptation of plans based on<br />
actual results.<br />
<br />
T. Gilb and D. Graham, ''Software Inspection'' [22].<br />
<br />
This book introduces measurement and statistical<br />
sampling for reviews and defects. It presents<br />
techniques that produce quantified results for<br />
reducing defects, improving productivity, tracking<br />
projects, and creating documentation.<br />
<br />
K.E. Wiegers, ''Peer Reviews in Software: APractical Guide'' [23].<br />
<br />
This book provides clear, succinct explanations<br />
of different peer review methods distinguished by<br />
level of formality and effectiveness. Pragmatic<br />
guidance for implementing the methods and how<br />
to select which methods are appropriate for given<br />
circumstances is provided.<br />
<br />
N.R. Tague, ''The Quality Toolbox'', 2nd ed., [24].<br />
<br />
Provides a pragmatic how-to explanation of a<br />
comprehensive set of methods, tools, and techniques<br />
for solving quality improvement problems.<br />
Includes the seven basic quality control<br />
tools and many others.<br />
<br />
''IEEE Std. P730-2013 Draft Standard for<br />
Software Quality Assurance Processes'' [5].<br />
<br />
This draft standard expands the SQA processes<br />
identified in IEEE/ISO/IEC 12207-2008. P730<br />
establishes standards for initiating, planning,<br />
controlling, and executing the software quality<br />
assurance processes of a software development<br />
or maintenance project. Approval of this draft<br />
standard is expected in 2014.}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_10:_Software_Quality&diff=871Chapter 10: Software Quality2015-08-29T14:26:53Z<p>Daniel Robbins: /* Software Quality Measurement */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}<br />
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}<br />
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}<br />
{{Acronym|name=FTA|description=Fault Tree Analysis}}<br />
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}<br />
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}<br />
{{Acronym|name=QFD|description=Quality Function Deployment}}<br />
{{Acronym|name=SPI|description=Software Process Improvement}}<br />
{{Acronym|name=SQA|description=Software Quality Assurance}}<br />
{{Acronym|name=SQC|description=Software Quality Control}}<br />
{{Acronym|name=SQM|description=Software Quality Management}}<br />
{{Acronym|name=TQM|description=Total Quality Management}}<br />
{{Acronym|name=V&V|description=Verification and Validation}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
What is software quality, and why is it so important<br />
that it is included in many knowledge areas<br />
(KAs) of the ''SWEBOK Guide''?<br />
<br />
One reason is that the term ''software quality'' is<br />
overloaded. Software quality may refer: to desirable<br />
characteristics of software products, to the<br />
extent to which a particular software product possess<br />
those characteristics, and to processes, tools,<br />
and techniques used to achieve those characteristics.<br />
Over the years, authors and organizations<br />
have defined the term quality differently. To Phil<br />
Crosby, it was “conformance to requirements”<br />
[1]. Watts Humphrey refers to it as “achieving<br />
excellent levels of “fitness for use” [2]. Meanwhile,<br />
IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”<br />
[3*, p8].<br />
<br />
More recently, software quality is defined as the<br />
“capability of software product to satisfy stated<br />
and implied needs under specified conditions” [4]<br />
and as “the degree to which a software product<br />
meets established requirements; however, quality<br />
depends upon the degree to which those established<br />
requirements accurately represent stakeholder<br />
needs, wants, and expectations” [5]. Both<br />
definitions embrace the premise of conformance<br />
to requirements. Neither refers to types of requirements<br />
(e.g., functional, reliability, performance,<br />
dependability, or any other characteristic). Significantly,<br />
however, these definitions emphasize that<br />
quality is dependent upon requirements.<br />
<br />
These definitions also illustrate another reason<br />
for the prevalence of software quality throughout<br />
this ''Guide'': a frequent ambiguity of ''software quality'' versus ''software quality requirements''<br />
(“the -''ilities''” is a common shorthand). Software<br />
quality requirements are actually attributes of (or<br />
constraints on) functional requirements (what<br />
the system does). Software requirements may<br />
also specify resource usage, a communication<br />
protocol, or many other characteristics. This KA<br />
attempts clarity by using ''software quality'' in the<br />
broadest sense from the definitions above and<br />
by using ''software quality requirements'' as constraints<br />
on functional requirements. Software<br />
quality is achieved by conformance to all requirements<br />
regardless of what characteristic is specified<br />
or how requirements are grouped or named.<br />
<br />
Software quality is also considered in many of<br />
the SWEBOK KAs because it is a basic parameter<br />
of a software engineering effort. For all engineered<br />
products, the primary goal is delivering<br />
maximum stakeholder value, while balancing the<br />
constraints of development cost and schedule;<br />
this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements.<br />
For software products, stakeholders could<br />
value price (what they pay for the product), lead<br />
time (how fast they get the product), and software<br />
quality.<br />
<br />
This KA addresses definitions and provides an<br />
overview of practices, tools, and techniques for<br />
defining software quality and for appraising the<br />
state of software quality during development,<br />
maintenance, and deployment. Cited references<br />
provide additional details.}}<br />
[[File:Breakdown of Topics for the Software Quality.jpg|thumb|300px|frame|Figure 10.1: Breakdown of Topics for the Software Quality KA]]<br />
{{IntroSection|title=Breakdown of Topics for Software Quality|body=<br />
The breakdown of topics for the Software Quality KA is presented in Figure 10.1.}}<br />
<br />
==Software Quality Fundamentals==<br />
<br />
Reaching agreement on what constitutes quality<br />
for all stakeholders and clearly communicating<br />
that agreement to software engineers require that the many aspects of quality be formally defined<br />
and discussed.<br />
<br />
A software engineer should understand quality<br />
concepts, characteristics, values, and their<br />
application to the software under development or<br />
maintenance. The important concept is that the<br />
software requirements define the required quality<br />
attributes of the software. Software requirements<br />
influence the measurement methods and acceptance<br />
criteria for assessing the degree to which<br />
the software and related documentation achieve<br />
the desired quality levels.<br />
<br />
===Software Engineering Culture and Ethics===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=6|parts=c2s3.5}}}}<br />
<br />
Software engineers are expected to share a commitment<br />
to software quality as part of their culture.<br />
A healthy software engineering culture includes<br />
many characteristics, including the understanding<br />
that tradeoffs among cost, schedule, and quality<br />
are a basic tenant of the engineering of any product.<br />
A strong software engineering ethic assumes that engineers accurately report information, conditions,<br />
and outcomes related to quality.<br />
<br />
Ethics also play a significant role in software<br />
quality, the culture, and the attitudes of software<br />
engineers. The IEEE Computer Society and the<br />
ACM have developed a code of ethics and professional<br />
practice (see Codes of Ethics and Professional<br />
Conduct in the Software Engineering<br />
Professional Practice KA).<br />
<br />
===Value and Costs of Quality===<br />
{{RightSection|{{referenceLink|number=7|parts=c17, c22}}}}<br />
<br />
Defining and then achieving software quality is<br />
not simple. Quality characteristics may or may<br />
not be required, or they may be required to a<br />
greater or lesser degree, and tradeoffs may be<br />
made among them. To help determine the level<br />
of software quality, i.e., achieving stakeholder<br />
value, this section presents cost of software quality<br />
(CoSQ): a set of measurements derived from<br />
the economic assessment of software quality<br />
development and maintenance processes. The<br />
CoSQ measurements are examples of process<br />
measurements that may be used to infer characteristics<br />
of a product.<br />
<br />
The premise underlying the CoSQ is that the<br />
level of quality in a software product can be<br />
inferred from the cost of activities related to dealing<br />
with the consequences of poor quality. Poor<br />
quality means that the software product does not<br />
fully “satisfy stated and implied needs” or “established<br />
requirements.” There are four cost of quality<br />
categories: prevention, appraisal, internal failure,<br />
and external failure.<br />
<br />
Prevention costs include investments in software<br />
process improvement efforts, quality infrastructure,<br />
quality tools, training, audits, and management<br />
reviews. These costs are usually not specific<br />
to a project; they span the organization. Appraisal<br />
costs arise from project activities that find defects.<br />
These appraisal activities can be categorized into<br />
costs of reviews (design, peer) and costs of testing<br />
(software unit testing, software integration,<br />
system level testing, acceptance testing); appraisal<br />
costs would be extended to subcontracted software<br />
suppliers. Costs of internal failures are those that<br />
are incurred to fix defects found during appraisal<br />
activities and discovered prior to delivery of the software product to the customer. External failure<br />
costs include activities to respond to software<br />
problems discovered after delivery to the customer. <br />
<br />
Software engineers should be able to use CoSQ<br />
methods to ascertain levels of software quality<br />
and should also be able to present quality alternatives<br />
and their costs so that tradeoffs between<br />
cost, schedule, and delivery of stakeholder value<br />
can be made.<br />
<br />
===Models and Quality Characteristics===<br />
{{RightSection|{{referenceLink|number=3|parts=c24s1}} {{referenceLink|number=7|parts=c2s4}} {{referenceLink|number=8|parts=c17}}}}<br />
<br />
Terminology for software quality characteristics<br />
differs from one taxonomy (or model of software<br />
quality) to another, each model perhaps having<br />
a different number of hierarchical levels and a<br />
different total number of characteristics. Various<br />
authors have produced models of software quality<br />
characteristics or attributes that can be useful<br />
for discussing, planning, and rating the quality<br />
of software products. ISO/IEC 25010: 2011 [4]<br />
defines product quality and quality in use as two<br />
related quality models. Appendix B in the SWEBOK<br />
Guide provides a list of applicable standards<br />
for each KA. Standards for this KA cover various<br />
ways of characterizing software quality.<br />
<br />
====Software Process Quality====<br />
<br />
Software quality management and software engineering<br />
process quality have a direct bearing on<br />
the quality of the software product.<br />
<br />
Models and criteria that evaluate the capabilities<br />
of software organizations are primarily project<br />
organization and management considerations<br />
and, as such, are covered in the Software Engineering<br />
Management and Software Engineering<br />
Process KAs.<br />
<br />
It is not possible to completely distinguish process<br />
quality from product quality because process<br />
outcomes include products. Determining whether<br />
a process has the capability to consistently produce<br />
products of desired quality is not simple.<br />
<br />
The software engineering process, discussed<br />
in the Software Engineering Process KA, influences<br />
the quality characteristics of software products,<br />
which in turn affect quality as perceived by<br />
stakeholders.<br />
<br />
====Software Product Quality====<br />
<br />
The software engineer, first of all, must determine<br />
the real purpose of the software. In this regard,<br />
stakeholder requirements are paramount, and they<br />
include quality requirements in addition to functional<br />
requirements. Thus, software engineers<br />
have a responsibility to elicit quality requirements<br />
that may not be explicit at the outset and to understand<br />
their importance as well as the level of difficulty<br />
in attaining them. All software development<br />
processes (e.g., eliciting requirements, designing,<br />
constructing, building, checking, improving quality)<br />
are designed with these quality requirements<br />
in mind and may carry additional development<br />
costs if attributes such as safety, security, and<br />
dependability are important. The additional development<br />
costs help ensure that quality obtained can<br />
be traded off against the anticipated benefits.<br />
<br />
The term work-product means any artifact that<br />
is the outcome of a process used to create the<br />
final software product. Examples of a work-product<br />
include a system/subsystem specification, a<br />
software requirements specification for a software<br />
component of a system, a software design<br />
description, source code, software test documentation,<br />
or reports. While some treatments of quality<br />
are described in terms of final software and<br />
system performance, sound engineering practice<br />
requires that intermediate work-products relevant<br />
to quality be evaluated throughout the software<br />
engineering process.<br />
<br />
===Software Quality Improvement===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=9|parts=c24}} {{referenceLink|number=10|parts=c11s2.4}}}}<br />
<br />
The quality of software products can be improved<br />
through preventative processes or an iterative<br />
process of continual improvement, which<br />
requires management control, coordination, and<br />
feedback from many concurrent processes: (1)<br />
the software life cycle processes, (2) the process<br />
of fault/defect detection, removal, and prevention,<br />
and (3) the quality improvement process.<br />
<br />
The theory and concepts behind quality<br />
improvement—such as building in quality<br />
through the prevention and early detection of<br />
defects, continual improvement, and stakeholder<br />
focus—are pertinent to software engineering.<br />
These concepts are based on the work of experts in quality who have stated that the quality of a<br />
product is directly linked to the quality of the<br />
process used to create it. Approaches such as the<br />
Deming improvement cycle of Plan-Do-Check-<br />
Act (PDCA), evolutionary delivery, kaizen, and<br />
quality function deployment (QFD) offer techniques<br />
to specify quality objectives and determine<br />
whether they are met. The Software Engineering<br />
Institute’s IDEAL is another method [7*]. Quality<br />
management is now recognized by the '''SWEBOK Guide'' as an important discipline.<br />
<br />
Management sponsorship supports process and<br />
product evaluations and the resulting findings.<br />
Then an improvement program is developed<br />
identifying detailed actions and improvement<br />
projects to be addressed in a feasible time frame.<br />
Management support implies that each improvement<br />
project has enough resources to achieve the<br />
goal defined for it. Management sponsorship is<br />
solicited frequently by implementing proactive<br />
communication activities.<br />
<br />
===Software Safety===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s3}}}}<br />
<br />
Safety-critical systems are those in which a system<br />
failure could harm human life, other living<br />
things, physical structures, or the environment.<br />
The software in these systems is safety-critical.<br />
There are increasing numbers of applications<br />
of safety-critical software in a growing number<br />
of industries. Examples of systems with safetycritical<br />
software include mass transit systems,<br />
chemical manufacturing plants, and medical<br />
devices. The failure of software in these systems<br />
could have catastrophic effects. There are industry<br />
standards, such as DO-178C [11], and emerging<br />
processes, tools, and techniques for developing<br />
safetycritical software. The intent of these<br />
standards, tools, and techniques is to reduce the<br />
risk of injecting faults into the software and thus<br />
improve software reliability.<br />
<br />
Safety-critical software can be categorized as<br />
direct or indirect. Direct is that software embedded<br />
in a safety-critical system, such as the flight<br />
control computer of an aircraft. Indirect includes<br />
software applications used to develop safetycritical<br />
software. Indirect software is included in<br />
software engineering environments and software<br />
test environments.<br />
<br />
Three complementary techniques for reducing<br />
the risk of failure are avoidance, detection<br />
and removal, and damage limitation. These<br />
techniques impact software functional requirements,<br />
software performance requirements, and<br />
development processes. Increasing levels of risk<br />
imply increasing levels of software quality assurance<br />
and control techniques such as inspections.<br />
Higher risk levels may necessitate more thorough<br />
inspections of requirements, design, and code<br />
or the use of more formal analytical techniques.<br />
Another technique for managing and controlling<br />
software risk is building assurance cases. An<br />
assurance case is a reasoned, auditable artifact<br />
created to support the contention that its claim<br />
or claims are satisfied. It contains the following<br />
and their relationships: one or more claims about<br />
properties; arguments that logically link the evidence<br />
and any assumptions to the claims; and a<br />
body of evidence and assumptions supporting<br />
these arguments [12].<br />
<br />
==Software Quality Management Processes==<br />
<br />
Software quality management is the collection of<br />
all processes that ensure that software products,<br />
services, and life cycle process implementations<br />
meet organizational software quality objectives<br />
and achieve stakeholder satisfaction [13, 14].<br />
SQM defines processes, process owners, requirements<br />
for the processes, measurements of the<br />
processes and their outputs, and feedback channels<br />
throughout the whole software life cycle.<br />
<br />
SQM comprises four subcategories: software<br />
quality planning, software quality assurance<br />
(SQA), software quality control (SQC), and software<br />
process improvement (SPI). Software quality<br />
planning includes determining which quality<br />
standards are to be used, defining specific quality<br />
goals, and estimating the effort and schedule of<br />
software quality activities. In some cases, software<br />
quality planning also includes defining the<br />
software quality processes to be used. SQA activities<br />
define and assess the adequacy of software<br />
processes to provide evidence that establishes<br />
confidence that the software processes are appropriate<br />
for and produce software products of suitable<br />
quality for their intended purposes [5]. SQC<br />
activities examine specific project artifacts (documents<br />
and executables) to determine whether they comply with standards established for the project<br />
(including requirements, constraints, designs,<br />
contracts, and plans). SQC evaluates intermediate<br />
products as well as the final products.<br />
<br />
The fourth SQM category dealing with improvement<br />
has various names within the software industry,<br />
including SPI, software quality improvement,<br />
and software corrective and preventive action. The<br />
activities in this category seek to improve process<br />
effectiveness, efficiency, and other characteristics<br />
with the ultimate goal of improving software<br />
quality. Although SPI could be included in any of<br />
the first three categories, an increasing number<br />
of organizations organize SPI into a separate category<br />
that may span across many projects (see the<br />
Software Engineering Process KA).<br />
<br />
Software quality processes consist of tasks<br />
and techniques to indicate how software plans<br />
(e.g., software management, development, quality<br />
management, or configuration management<br />
plans) are being implemented and how well the<br />
intermediate and final products are meeting their<br />
specified requirements. Results from these tasks<br />
are assembled in reports for management before<br />
corrective action is taken. The management of<br />
an SQM process is tasked with ensuring that the<br />
results of these reports are accurate.<br />
<br />
Risk management can also play an important<br />
role in delivering quality software. Incorporating<br />
disciplined risk analysis and management techniques<br />
into the software life cycle processes can<br />
help improve product quality (see the Software<br />
Engineering Management KA for related material<br />
on risk management).<br />
<br />
===Software Quality Assurance===<br />
{{RightSection|{{referenceLink|number=7|parts=c4–c6, c11, c12, c26–27}}}}<br />
<br />
To quell a widespread misunderstanding, software<br />
quality assurance is not testing. software<br />
quality assurance (SQA) is a set of activities that<br />
define and assess the adequacy of software processes<br />
to provide evidence that establishes confidence<br />
that the software processes are appropriate<br />
and produce software products of suitable quality<br />
for their intended purposes. A key attribute of<br />
SQA is the objectivity of the SQA function with<br />
respect to the project. The SQA function may<br />
also be organizationally independent of the project;<br />
that is, free from technical, managerial, and financial pressures from the project [5]. SQA has<br />
two aspects: product assurance and process assurance,<br />
which are explained in section 2.3.<br />
<br />
The software quality plan (in some industry<br />
sectors it is termed the software quality assurance<br />
plan) defines the activities and tasks employed<br />
to ensure that software developed for a specific<br />
product satisfies the project’s established requirements<br />
and user needs within project cost and<br />
schedule constraints and is commensurate with<br />
project risks. The SQAP first ensures that quality<br />
targets are clearly defined and understood.<br />
<br />
The SQA plan’s quality activities and tasks are<br />
specified with their costs, resource requirements,<br />
objectives, and schedule in relation to related<br />
objectives in the software engineering management,<br />
software development, and software maintenance<br />
plans. The SQA plan should be consistent<br />
with the software configuration management<br />
plan (see the Software Configuration Management<br />
KA). The SQA plan identifies documents,<br />
standards, practices, and conventions governing<br />
the project and how these items are checked and<br />
monitored to ensure adequacy and compliance.<br />
The SQA plan also identifies measures; statistical<br />
techniques; procedures for problem reporting and<br />
corrective action; resources such as tools, techniques,<br />
and methodologies; security for physical<br />
media; training; and SQA reporting and documentation.<br />
Moreover, the SQA plan addresses<br />
the software quality assurance activities of any<br />
other type of activity described in the software<br />
plans—such as procurement of supplier software<br />
for the project, commercial off-the-shelf software<br />
(COTS) installation, and service after delivery of<br />
the software. It can also contain acceptance criteria<br />
as well as reporting and management activities<br />
that are critical to software quality.<br />
<br />
===Verification & Validation===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s2.3, c8, c15s1.1, c21s3.3}}}}<br />
<br />
As stated in [15],<br />
<br />
* The purpose of V&V is to help the development organization build quality into the system during the life cycle. V&V processes provide an objective assessment of products and processes throughout the life cycle. This assessment demonstrates whether the requirements are correct, complete, accurate, consistent, and testable. The V&V processes determine whether the development products of a given activity<br />
conform to the requirements of that activity and whether the product satisfies its intended use and user needs.<br />
<br />
Verification is an attempt to ensure that the<br />
product is built correctly, in the sense that the<br />
output products of an activity meet the specifications<br />
imposed on them in previous activities.<br />
Validation is an attempt to ensure that the right<br />
product is built—that is, the product fulfills its<br />
specific intended purpose. Both the verification<br />
process and the validation process begin early<br />
in the development or maintenance phase. They<br />
provide an examination of key product features<br />
in relation to both the product’s immediate predecessor<br />
and the specifications to be met.<br />
<br />
The purpose of planning V&V is to ensure that<br />
each resource, role, and responsibility is clearly<br />
assigned. The resulting V&V plan documents<br />
describe the various resources and their roles and<br />
activities, as well as the techniques and tools to be<br />
used. An understanding of the different purposes of<br />
each V&V activity helps in the careful planning of<br />
the techniques and resources needed to fulfill their<br />
purposes. The plan also addresses the management,<br />
communication, policies, and procedures of<br />
the V&V activities and their interaction, as well as<br />
defect reporting and documentation requirements.<br />
<br />
===Reviews and Audits===<br />
{{RightSection|{{referenceLink|number=9|parts=c24s3}} {{referenceLink|number=16}}}}<br />
<br />
Reviews and audit processes are broadly defined<br />
as static—meaning that no software programs or<br />
models are executed—examination of software<br />
engineering artifacts with respect to standards that<br />
have been established by the organization or project<br />
for those artifacts. Different types of reviews<br />
and audits are distinguished by their purpose, levels<br />
of independence, tools and techniques, roles,<br />
and by the subject of the activity. Product assurance<br />
and process assurance audits are typically<br />
conducted by software quality assurance (SQA)<br />
personnel who are independent of development teams. Management reviews are conducted by<br />
organizational or project management. The engineering<br />
staff conducts technical reviews.<br />
<br />
* Management reviews evaluate actual project results with respect to plans.<br />
* Technical reviews (including inspections, walkthrough, and desk checking) examine engineering work-products.<br />
* Process assurance audits. SQA process assurance activities make certain that the processes used to develop, install, operate, and maintain software conform to contracts, comply with any imposed laws, rules, and regulations and are adequate, efficient and effective for their intended purpose [5].<br />
* Product assurance audits. SQA product assurance activities make certain to provide evidence that software products and related documentation are identified in and comply with contracts; and ensure that nonconformances are identified and addressed [5].<br />
<br />
====Management Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a management review is to monitor progress, determine the status of plans and schedules, and evaluate the effectiveness<br />
of management processes, tools and techniques. Management reviews compare actual project results against plans to determine the status of projects or maintenance efforts. The main parameters of management reviews are project cost, schedule, scope, and quality. Management reviews evaluate decisions about corrective actions, changes in the allocation of resources, or changes to the scope of the project.<br />
<br />
Inputs to management reviews may include<br />
audit reports, progress reports, V&V reports, and<br />
plans of many types, including risk management,<br />
project management, software configuration<br />
management, software safety, and risk assessment,<br />
among others. (Refer to the Software Engineering<br />
Management and the Software Configuration<br />
Management KAs for related material.)<br />
<br />
====Technical Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a technical review is to evaluate a software product by a team of qualified personnel to determine its suitability for its intended use and identify discrepancies from specifications and standards. It provides management with evidence to confirm the technical status of the project.<br />
<br />
Although any work-product can be reviewed,<br />
technical reviews are performed on the main<br />
software engineering work-products of software<br />
requirements and software design.<br />
<br />
Purpose, roles, activities, and most importantly<br />
the level of formality distinguish different types<br />
of technical reviews. Inspections are the most formal,<br />
walkthroughs less, and pair reviews or desk<br />
checks are the least formal.<br />
<br />
Examples of specific roles include a decision<br />
maker (i.e., software lead), a review leader, a<br />
recorder, and checkers (technical staff members<br />
who examine the work-products). Reviews are<br />
also distinguished by whether meetings (face to<br />
face or electronic) are included in the process. In<br />
some review methods checkers solitarily examine<br />
work-products and send their results back to<br />
a coordinator. In other methods checkers work<br />
cooperatively in meetings. A technical review<br />
may require that mandatory inputs be in place in<br />
order to proceed:<br />
<br />
* Statement of objectives<br />
* Specific software product<br />
* Specific project management plan<br />
* Issues list associated with this product<br />
* Technical review procedure.<br />
<br />
The team follows the documented review procedure.<br />
The technical review is completed once<br />
all the activities listed in the examination have<br />
been completed.<br />
<br />
Technical reviews of source code may include a<br />
wide variety of concerns such as analysis of algorithms,<br />
utilization of critical computer resources,<br />
adherence to coding standards, structure and organization of code for testability, and safetycritical<br />
considerations.<br />
<br />
Note that technical reviews of source code or<br />
design models such as UML are also termed static<br />
analysis (see topic 3, Practical Considerations).<br />
<br />
====Inspections====<br />
<br />
“The purpose of an inspection is to detect and<br />
identify software product anomalies” [16*].<br />
Some important differentiators of inspections as<br />
compared to other types of technical reviews are<br />
these:<br />
<br />
* 1. Rules. Inspections are based upon examining a work-product with respect to a defined set of criteria specified by the organization. Sets of rules can be defined for different types of workproducts (e.g., rules for requirements,architecture descriptions, source code).<br />
* 2. Sampling. Rather that attempt to examine every word and figure in a document, the inspection process allows checkers to evaluate defined subsets (samples) of the documents under review.<br />
* 3. Peer. Individuals holding management positions over members of the inspection team do not participate in the inspection. This is<br />
a key distinction between peer review and management review.<br />
* 4. Led. An impartial moderator who is trained in inspection techniques leads inspection meetings.<br />
* 5. Meeting. The inspection process includes meetings (face to face or electronic) conducted by a moderator according to a formal procedure in which inspection team members report the anomalies they have found and other issues.<br />
<br />
Software inspections always involve the author<br />
of an intermediate or final product; other reviews<br />
might not. Inspections also include an inspection<br />
leader, a recorder, a reader, and a few (two to five)<br />
checkers (inspectors). The members of an inspection<br />
team may possess different expertise, such as<br />
domain expertise, software design method expertise,<br />
or programming language expertise. Inspections<br />
are usually conducted on one relatively small section of the product at a time (samples).<br />
Each team member examines the software product<br />
and other review inputs prior to the review<br />
meeting, perhaps by applying an analytical technique<br />
(see section 3.3.3) to a small section of<br />
the product or to the entire product with a focus<br />
on only one aspect—e.g., interfaces. During the<br />
inspection, the moderator conducts the session<br />
and verifies that everyone has prepared for the<br />
inspection and conducts the session. The inspection<br />
recorder documents anomalies found. A set<br />
of rules, with criteria and questions germane to<br />
the issues of interest, is a common tool used in<br />
inspections. The resulting list often classifies the<br />
anomalies (see section 3.2, Defect Characterization)<br />
and is reviewed for completeness and accuracy<br />
by the team. The inspection exit decision<br />
corresponds to one of the following options:<br />
<br />
* 1. Accept with no or, at most, minor reworking<br />
* 2. Accept with rework verification<br />
* 3. Reinspect.<br />
<br />
====Walkthroughs====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a systematic walk-through is to evaluate a software product. A walkthrough may be conducted for the purpose of educating an audience regarding a software product.<br />
<br />
Walkthroughs are distinguished from inspections.<br />
The main difference is that the author presents<br />
the work-product to the other participants in<br />
a meeting (face to face or electronic). Unlike an<br />
inspection, the meeting participants may not have<br />
necessarily seen the material prior to the meeting.<br />
The meetings may be conducted less formally.<br />
The author takes the role of explaining and<br />
showing the material to participants and solicits<br />
feedback. Like inspections, walkthroughs may be<br />
conducted on any type of work-product including<br />
project plan, requirements, design, source code,<br />
and test reports.<br />
<br />
====Process Assurance and Product Assurance Audits====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes<br />
to applicable regulations, standards, guidelines, plans, and procedures.<br />
<br />
Process assurance audits determine the adequacy<br />
of plans, schedules, and requirements to achieve<br />
project objectives [5]. The audit is a formally<br />
organized activity with participants having specific<br />
roles—such as lead auditor, another auditor, a<br />
recorder, or an initiator—and including a representative<br />
of the audited organization. Audits identify<br />
instances of nonconformance and produce a report<br />
requiring the team to take corrective action.<br />
<br />
While there may be many formal names for<br />
reviews and audits, such as those identified in the<br />
standard [16*], the important point is that they<br />
can occur on almost any product at any stage of<br />
the development or maintenance process.<br />
<br />
==Practical Considerations==<br />
===Software Quality Requirements===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s1}} {{referenceLink|number=18|parts=c12}} {{referenceLink|number=17|parts=c15s3.2.2, c15s3.3.1, c16s9.10}}}}<br />
====Influence Factors====<br />
Various factors influence planning, management,<br />
and selection of SQM activities and techniques,<br />
including<br />
<br />
* the domain of the system in which the software resides; the system functions could be safety-critical, mission-critical, businesscritical,security-critical<br />
* the physical environment in which the software system resides<br />
* system and software functional (what the system does) and quality (how well the system performs its functions) requirements<br />
* the commercial (external) or standard (internal) components to be used in the system<br />
* the specific software engineering standards applicable<br />
* the methods and software tools to be used for development and maintenance and for quality evaluation and improvement<br />
* the budget, staff, project organization, plans, and scheduling of all processes<br />
* the intended users and use of the system<br />
* the integrity level of the system.<br />
<br />
Information on these factors influences how<br />
the SQM processes are organized and documented,<br />
how specific SQM activities are selected,<br />
what resources are needed, and which of those<br />
resources impose bounds on the efforts.<br />
<br />
====Dependability====<br />
<br />
In cases where system failure may have extremely<br />
severe consequences, overall dependability (hardware,<br />
software, and human or operational) is the<br />
main quality requirement over and above basic<br />
functionality. This is the case for the following<br />
reasons: system failures affect a large number of<br />
people; users often reject systems that are unreliable,<br />
unsafe, or insecure; system failure costs<br />
may be enormous; and undependable systems<br />
may cause information loss. System and software<br />
dependability include such characteristics<br />
as availability, reliability, safety, and security.<br />
When developing dependable software, tools and<br />
techniques can be applied to reduce the risk of<br />
injecting faults into the intermediate deliverables<br />
or the final software product. Verification, validation,<br />
and testing processes, techniques, methods,<br />
and tools identify faults that impact dependability<br />
as early as possible in the life cycle. Additionally,<br />
mechanisms may need to be in place in the<br />
software to guard against external attacks and to<br />
tolerate faults.<br />
<br />
====Integrity Levels of Software====<br />
<br />
Defining integrity levels is a method of risk<br />
management.<br />
<br />
* Software integrity levels are a range of values that represent software complexity, criticality, risk, safety level, security level, desired performance, reliability, or other project-unique characteristics that define the importance of the software to the user and acquirer. The characteristics used to determine software integrity level vary depending on the intended application and use of the system. The software is a part of the system, and its integrity level is to be determined as a part of that system.<br />
<br />
The assigned software integrity levels may<br />
change as the software evolves. Design, coding,<br />
procedural, and technology features implemented<br />
in the system or software can raise or lower the<br />
assigned software integrity levels. The software<br />
integrity levels established for a project result<br />
from agreements among the acquirer, supplier,<br />
developer, and independent assurance authorities.<br />
A software integrity level scheme is a tool used in<br />
determining software integrity levels. [5]<br />
<br />
As noted in [17*], “the integrity levels can be<br />
applied during development to allocate additional<br />
verification and validation efforts to high-integrity<br />
components.”<br />
<br />
===Defect Characterization===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s3, c8s8, c10s2}}}}<br />
<br />
Software quality evaluation (i.e., software quality<br />
control) techniques find defects, faults and failures.<br />
Characterizing these techniques leads to an<br />
understanding of the product, facilitates corrections<br />
to the process or the product, and informs<br />
management and other stakeholders of the status<br />
of the process or product. Many taxonomies<br />
exist and, while attempts have been made to gain<br />
consensus, the literature indicates that there are<br />
quite a few in use. Defect characterization is also<br />
used in audits and reviews, with the review leader<br />
often presenting a list of issues provided by team<br />
members for consideration at a review meeting.<br />
<br />
As new design methods and languages evolve,<br />
along with advances in overall software technologies,<br />
new classes of defects appear, and a great<br />
deal of effort is required to interpret previously<br />
defined classes. When tracking defects, the software<br />
engineer is interested in not only the number<br />
of defects but also the types. Information alone,<br />
without some classification, may not be sufficient<br />
to identify the underlying causes of the defects.<br />
Specific types of problems need to be grouped to<br />
identify trends over time. The point is to establish<br />
a defect taxonomy that is meaningful to the organization<br />
and to software engineers.<br />
<br />
Software quality control activities discover information<br />
at all stages of software development and<br />
maintenance. In some cases, the word ''defect'' is<br />
overloaded to refer to different types of anomalies.<br />
However, different engineering cultures and standards<br />
may use somewhat different meanings for<br />
these terms. The variety of terms prompts this section<br />
to provide a widely used set of definitions [19]:<br />
<br />
* ''Computational Error'': “the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.”<br />
* ''Error'': “A human action that produces an incorrect result.” A slip or mistake that a person makes. Also called human error.<br />
* ''Defect'': An “imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced.” A defect is caused by a person committing an error.<br />
* ''Fault'': A defect in source code. An “incorrect step, process, or data definition in computer program.” The encoding of a human error in source code. Fault is the formal name of a bug.<br />
* ''Failure'': An “event in which a system or system component does not perform a required function within specified limits.” A failure is<br />
produced when a fault is encountered by the processor under specified conditions.<br />
<br />
Using these definitions three widely used software<br />
quality measurements are defect density<br />
(number of defects per unit size of documents),<br />
fault density (number of faults per 1K lines of<br />
code), and failure intensity (failures per use-hour<br />
or per test-hour). Reliability models are built<br />
from failure data collected during software testing<br />
or from software in service and thus can be<br />
used to estimate the probability of future failures<br />
and to assist in decisions on when to stop testing.<br />
<br />
One probable action resulting from SQM findings<br />
is to remove the defects from the product<br />
under examination (e.g., find and fix bugs, create<br />
new build). Other activities attempt to eliminate the causes of the defects—for example, root cause<br />
analysis (RCA). RCA activities include analyzing<br />
and summarizing the findings to find root causes<br />
and using measurement techniques to improve<br />
the product and the process as well as to track the<br />
defects and their removal. Process improvement<br />
is primarily discussed in the Software Engineering<br />
Process KA, with the SQM process being a<br />
source of information.<br />
<br />
Data on inadequacies and defects found by<br />
software quality control techniques may be lost<br />
unless they are recorded. For some techniques<br />
(e.g., technical reviews, audits, inspections),<br />
recorders are present to set down such information,<br />
along with issues and decisions. When automated<br />
tools are used (see topic 4, Software Quality<br />
Tools), the tool output may provide the defect<br />
information. Reports about defects are provided<br />
to the management of the organization.<br />
<br />
===Software Quality Management Techniques===<br />
{{RightSection|{{referenceLink|number=7|parts=c7s3}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=c12s5, c15s1, p417}}{{referenceLink|number=16}}}}<br />
<br />
Software quality control techniques can be categorized<br />
in many ways, but a straightforward<br />
approach uses just two categories: static and<br />
dynamic. Dynamic techniques involve executing<br />
the software; static techniques involve analyzing<br />
documents<br />
<br />
====Static Techniques====<br />
<br />
Static techniques examine software documentation<br />
(including requirements, interface specifications,<br />
designs, and models) and software source<br />
code without executing the code. There are many<br />
tools and techniques for statically examining software<br />
work-products (see section 2.3.2). In addition,<br />
tools that analyze source code control flow<br />
and search for dead code are considered to be<br />
static analysis tools because they do not involve<br />
executing the software code.<br />
<br />
Other, more formal, types of analytical techniques<br />
are known as formal methods. They are<br />
notably used to verify software requirements and<br />
designs. They have mostly been used in the verification<br />
of crucial parts of critical systems, such<br />
as specific security and safety requirements. (See also Formal Methods in the Software Engineering<br />
Models and Methods KA.)<br />
<br />
====Dynamic Techniques====<br />
<br />
Dynamic techniques involve executing the software<br />
code. Different kinds of dynamic techniques<br />
are performed throughout the development and<br />
maintenance of software. Generally, these are<br />
testing techniques, but techniques such as simulation<br />
and model analysis may be considered<br />
dynamic (see the Software Engineering Models<br />
and Methods KA). Code reading is considered a<br />
static technique, but experienced software engineers<br />
may execute the code as they read through<br />
it. Code reading may utilize dynamic techniques.<br />
This discrepancy in categorizing indicates that<br />
people with different roles and experience in the<br />
organization may consider and apply these techniques<br />
differently.<br />
<br />
Different groups may perform testing during<br />
software development, including groups independent<br />
of the development team. The Software<br />
Testing KA is devoted entirely to this subject.<br />
<br />
====Testing====<br />
<br />
Two types of testing may fall under V&V because<br />
of their responsibility for the quality of the materials<br />
used in the project:<br />
<br />
* Evaluation and tests of tools to be used on the project<br />
* Conformance tests (or review of conformance tests) of components and COTS products to be used in the product<br />
<br />
Sometimes an independent (third-party or<br />
IV&V) organization may be tasked to perform<br />
testing or to monitor the test process V&V may<br />
be called upon to evaluate the testing itself: adequacy<br />
of plans, processes, and procedures, and<br />
adequacy and accuracy of results.<br />
<br />
The third party is not the developer, nor is it<br />
associated with the development of the product.<br />
Instead, the third party is an independent facility,<br />
usually accredited by some body of authority.<br />
Their purpose is to test a product for conformance<br />
to a specific set of requirements (see the Software Testing KA).<br />
<br />
===Software Quality Measurement===<br />
{{RightSection|{{referenceLink|number=3|parts=c4}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=p90}}}}<br />
<br />
Software quality measurements are used to<br />
support decision-making. With the increasing<br />
sophistication of software, questions of quality<br />
go beyond whether or not the software works to<br />
how well it achieves measurable quality goals.<br />
<br />
Decisions supported by software quality measurement<br />
include determining levels of software<br />
quality (notably because models of software<br />
product quality include measures to determine<br />
the degree to which the software product achieves<br />
quality goals); managerial questions about effort,<br />
cost, and schedule; determining when to stop testing<br />
and release a product (see Termination under<br />
section 5.1, Practical Considerations, in the Software<br />
Testing KA); and determining the efficacy<br />
of process improvement efforts.<br />
<br />
The cost of SQM processes is an issue frequently<br />
raised in deciding how a project or a software<br />
development and maintenance group should<br />
be organized. Often, generic models of cost are<br />
used, which are based on when a defect is found<br />
and how much effort it takes to fix the defect relative<br />
to finding the defect earlier in the development<br />
process. Software quality measurement data<br />
collected internally may give a better picture of<br />
cost within this project or organization.<br />
<br />
While the software quality measurement data<br />
may be useful in itself (e.g., the number of defective<br />
requirements or the proportion of defective<br />
requirements), mathematical and graphical techniques<br />
can be applied to aid in the interpretation<br />
of the measures (see the Engineering Foundations<br />
KA). These techniques include<br />
<br />
* descriptive statistics based (e.g., Pareto analysis, run charts, scatter plots, normal distribution)<br />
* statistical tests (e.g., the binomial test, chisquared test)<br />
* trend analysis (e.g., control charts; see''The Quality Toolbox'' in the list of further readings)<br />
* prediction (e.g., reliability models).<br />
<br />
Descriptive statistics-based techniques and<br />
tests often provide a snapshot of the more troublesome areas of the software product under<br />
examination. The resulting charts and graphs<br />
are visualization aids, which the decision makers<br />
can use to focus resources and conduct process<br />
improvements where they appear to be most<br />
needed. Results from trend analysis may indicate<br />
that a schedule is being met, such as in testing, or<br />
that certain classes of faults may become more<br />
likely to occur unless some corrective action is<br />
taken in development. The predictive techniques<br />
assist in estimating testing effort and schedule<br />
and in predicting failures. More discussion on<br />
measurement in general appears in the Software<br />
Engineering Process and Software Engineering<br />
Management KAs. More specific information on<br />
testing measurement is presented in the Software<br />
Testing KA.<br />
<br />
Software quality measurement includes measuring<br />
defect occurrences and applying statistical<br />
methods to understand the types of defects that<br />
occur most frequently. This information may be<br />
used by software process improvement for determining<br />
methods to prevent, reduce, or eliminate<br />
their recurrence. They also aid in understanding<br />
trends, how well detection and containment techniques<br />
are working, and how well the development<br />
and maintenance processes are progressing.<br />
<br />
From these measurement methods, defect<br />
profiles can be developed for a specific application<br />
domain. Then, for the next software project<br />
within that organization, the profiles can be used<br />
to guide the SQM processes—that is, to expend<br />
the effort where problems are most likely to occur.<br />
Similarly, benchmarks, or defect counts typical of<br />
that domain, may serve as one aid in determining<br />
when the product is ready for delivery. Discussion<br />
on using data from SQM to improve development<br />
and maintenance processes appears in the<br />
Software Engineering Management and Software<br />
Engineering Process KAs.<br />
<br />
==Software Quality Tools==<br />
<br />
Software quality tools include static and dynamic<br />
analysis tools. Static analysis tools input source<br />
code, perform syntactical and semantic analysis<br />
without executing the code, and present results to<br />
users. There is a large variety in the depth, thoroughness,<br />
and scope of static analysis tools that can be applied to artifacts including models, in<br />
addition to source code. (See the Software Construction,<br />
Software Testing, and Software Maintenance<br />
KAs for descriptions of dynamic analysis<br />
tools.)<br />
<br />
Categories of static analysis tools include the<br />
following:<br />
<br />
* Tools that facilitate and partially automate reviews and inspections of documents and code. These tools can route work to different participants in order to partially automate and control a review process. They allow users to enter defects found during inspections and reviews for later removal.<br />
* Some tools help organizations perform software safety hazard analysis. These tools provide, e.g., automated support for failure mode and effects analysis (FMEA) and fault tree analysis (FTA).<br />
* Tools that support tracking of software problems provide for entry of anomalies discovered during software testing and subsequent analysis, disposition, and resolution. Some tools include support for workflow and for tracking the status of problem resolution.<br />
* Tools that analyze data captured from software engineering environments and software test environments and produce visual displays of quantified data in the form of graphs, charts, and tables. These tools sometimes include the functionality to perform statistical analysis on data sets (for the purpose of discerning trends and making forecasts). Some of these tools provide defect and removal injection rates; defect densities; yields; distribution of defect injection and removal for each of the life cycle phases.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_10:_Software_Quality&diff=870Chapter 10: Software Quality2015-08-29T14:18:23Z<p>Daniel Robbins: /* Process Assurance and Product Assurance Audits */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}<br />
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}<br />
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}<br />
{{Acronym|name=FTA|description=Fault Tree Analysis}}<br />
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}<br />
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}<br />
{{Acronym|name=QFD|description=Quality Function Deployment}}<br />
{{Acronym|name=SPI|description=Software Process Improvement}}<br />
{{Acronym|name=SQA|description=Software Quality Assurance}}<br />
{{Acronym|name=SQC|description=Software Quality Control}}<br />
{{Acronym|name=SQM|description=Software Quality Management}}<br />
{{Acronym|name=TQM|description=Total Quality Management}}<br />
{{Acronym|name=V&V|description=Verification and Validation}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
What is software quality, and why is it so important<br />
that it is included in many knowledge areas<br />
(KAs) of the ''SWEBOK Guide''?<br />
<br />
One reason is that the term ''software quality'' is<br />
overloaded. Software quality may refer: to desirable<br />
characteristics of software products, to the<br />
extent to which a particular software product possess<br />
those characteristics, and to processes, tools,<br />
and techniques used to achieve those characteristics.<br />
Over the years, authors and organizations<br />
have defined the term quality differently. To Phil<br />
Crosby, it was “conformance to requirements”<br />
[1]. Watts Humphrey refers to it as “achieving<br />
excellent levels of “fitness for use” [2]. Meanwhile,<br />
IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”<br />
[3*, p8].<br />
<br />
More recently, software quality is defined as the<br />
“capability of software product to satisfy stated<br />
and implied needs under specified conditions” [4]<br />
and as “the degree to which a software product<br />
meets established requirements; however, quality<br />
depends upon the degree to which those established<br />
requirements accurately represent stakeholder<br />
needs, wants, and expectations” [5]. Both<br />
definitions embrace the premise of conformance<br />
to requirements. Neither refers to types of requirements<br />
(e.g., functional, reliability, performance,<br />
dependability, or any other characteristic). Significantly,<br />
however, these definitions emphasize that<br />
quality is dependent upon requirements.<br />
<br />
These definitions also illustrate another reason<br />
for the prevalence of software quality throughout<br />
this ''Guide'': a frequent ambiguity of ''software quality'' versus ''software quality requirements''<br />
(“the -''ilities''” is a common shorthand). Software<br />
quality requirements are actually attributes of (or<br />
constraints on) functional requirements (what<br />
the system does). Software requirements may<br />
also specify resource usage, a communication<br />
protocol, or many other characteristics. This KA<br />
attempts clarity by using ''software quality'' in the<br />
broadest sense from the definitions above and<br />
by using ''software quality requirements'' as constraints<br />
on functional requirements. Software<br />
quality is achieved by conformance to all requirements<br />
regardless of what characteristic is specified<br />
or how requirements are grouped or named.<br />
<br />
Software quality is also considered in many of<br />
the SWEBOK KAs because it is a basic parameter<br />
of a software engineering effort. For all engineered<br />
products, the primary goal is delivering<br />
maximum stakeholder value, while balancing the<br />
constraints of development cost and schedule;<br />
this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements.<br />
For software products, stakeholders could<br />
value price (what they pay for the product), lead<br />
time (how fast they get the product), and software<br />
quality.<br />
<br />
This KA addresses definitions and provides an<br />
overview of practices, tools, and techniques for<br />
defining software quality and for appraising the<br />
state of software quality during development,<br />
maintenance, and deployment. Cited references<br />
provide additional details.}}<br />
[[File:Breakdown of Topics for the Software Quality.jpg|thumb|300px|frame|Figure 10.1: Breakdown of Topics for the Software Quality KA]]<br />
{{IntroSection|title=Breakdown of Topics for Software Quality|body=<br />
The breakdown of topics for the Software Quality KA is presented in Figure 10.1.}}<br />
<br />
==Software Quality Fundamentals==<br />
<br />
Reaching agreement on what constitutes quality<br />
for all stakeholders and clearly communicating<br />
that agreement to software engineers require that the many aspects of quality be formally defined<br />
and discussed.<br />
<br />
A software engineer should understand quality<br />
concepts, characteristics, values, and their<br />
application to the software under development or<br />
maintenance. The important concept is that the<br />
software requirements define the required quality<br />
attributes of the software. Software requirements<br />
influence the measurement methods and acceptance<br />
criteria for assessing the degree to which<br />
the software and related documentation achieve<br />
the desired quality levels.<br />
<br />
===Software Engineering Culture and Ethics===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=6|parts=c2s3.5}}}}<br />
<br />
Software engineers are expected to share a commitment<br />
to software quality as part of their culture.<br />
A healthy software engineering culture includes<br />
many characteristics, including the understanding<br />
that tradeoffs among cost, schedule, and quality<br />
are a basic tenant of the engineering of any product.<br />
A strong software engineering ethic assumes that engineers accurately report information, conditions,<br />
and outcomes related to quality.<br />
<br />
Ethics also play a significant role in software<br />
quality, the culture, and the attitudes of software<br />
engineers. The IEEE Computer Society and the<br />
ACM have developed a code of ethics and professional<br />
practice (see Codes of Ethics and Professional<br />
Conduct in the Software Engineering<br />
Professional Practice KA).<br />
<br />
===Value and Costs of Quality===<br />
{{RightSection|{{referenceLink|number=7|parts=c17, c22}}}}<br />
<br />
Defining and then achieving software quality is<br />
not simple. Quality characteristics may or may<br />
not be required, or they may be required to a<br />
greater or lesser degree, and tradeoffs may be<br />
made among them. To help determine the level<br />
of software quality, i.e., achieving stakeholder<br />
value, this section presents cost of software quality<br />
(CoSQ): a set of measurements derived from<br />
the economic assessment of software quality<br />
development and maintenance processes. The<br />
CoSQ measurements are examples of process<br />
measurements that may be used to infer characteristics<br />
of a product.<br />
<br />
The premise underlying the CoSQ is that the<br />
level of quality in a software product can be<br />
inferred from the cost of activities related to dealing<br />
with the consequences of poor quality. Poor<br />
quality means that the software product does not<br />
fully “satisfy stated and implied needs” or “established<br />
requirements.” There are four cost of quality<br />
categories: prevention, appraisal, internal failure,<br />
and external failure.<br />
<br />
Prevention costs include investments in software<br />
process improvement efforts, quality infrastructure,<br />
quality tools, training, audits, and management<br />
reviews. These costs are usually not specific<br />
to a project; they span the organization. Appraisal<br />
costs arise from project activities that find defects.<br />
These appraisal activities can be categorized into<br />
costs of reviews (design, peer) and costs of testing<br />
(software unit testing, software integration,<br />
system level testing, acceptance testing); appraisal<br />
costs would be extended to subcontracted software<br />
suppliers. Costs of internal failures are those that<br />
are incurred to fix defects found during appraisal<br />
activities and discovered prior to delivery of the software product to the customer. External failure<br />
costs include activities to respond to software<br />
problems discovered after delivery to the customer. <br />
<br />
Software engineers should be able to use CoSQ<br />
methods to ascertain levels of software quality<br />
and should also be able to present quality alternatives<br />
and their costs so that tradeoffs between<br />
cost, schedule, and delivery of stakeholder value<br />
can be made.<br />
<br />
===Models and Quality Characteristics===<br />
{{RightSection|{{referenceLink|number=3|parts=c24s1}} {{referenceLink|number=7|parts=c2s4}} {{referenceLink|number=8|parts=c17}}}}<br />
<br />
Terminology for software quality characteristics<br />
differs from one taxonomy (or model of software<br />
quality) to another, each model perhaps having<br />
a different number of hierarchical levels and a<br />
different total number of characteristics. Various<br />
authors have produced models of software quality<br />
characteristics or attributes that can be useful<br />
for discussing, planning, and rating the quality<br />
of software products. ISO/IEC 25010: 2011 [4]<br />
defines product quality and quality in use as two<br />
related quality models. Appendix B in the SWEBOK<br />
Guide provides a list of applicable standards<br />
for each KA. Standards for this KA cover various<br />
ways of characterizing software quality.<br />
<br />
====Software Process Quality====<br />
<br />
Software quality management and software engineering<br />
process quality have a direct bearing on<br />
the quality of the software product.<br />
<br />
Models and criteria that evaluate the capabilities<br />
of software organizations are primarily project<br />
organization and management considerations<br />
and, as such, are covered in the Software Engineering<br />
Management and Software Engineering<br />
Process KAs.<br />
<br />
It is not possible to completely distinguish process<br />
quality from product quality because process<br />
outcomes include products. Determining whether<br />
a process has the capability to consistently produce<br />
products of desired quality is not simple.<br />
<br />
The software engineering process, discussed<br />
in the Software Engineering Process KA, influences<br />
the quality characteristics of software products,<br />
which in turn affect quality as perceived by<br />
stakeholders.<br />
<br />
====Software Product Quality====<br />
<br />
The software engineer, first of all, must determine<br />
the real purpose of the software. In this regard,<br />
stakeholder requirements are paramount, and they<br />
include quality requirements in addition to functional<br />
requirements. Thus, software engineers<br />
have a responsibility to elicit quality requirements<br />
that may not be explicit at the outset and to understand<br />
their importance as well as the level of difficulty<br />
in attaining them. All software development<br />
processes (e.g., eliciting requirements, designing,<br />
constructing, building, checking, improving quality)<br />
are designed with these quality requirements<br />
in mind and may carry additional development<br />
costs if attributes such as safety, security, and<br />
dependability are important. The additional development<br />
costs help ensure that quality obtained can<br />
be traded off against the anticipated benefits.<br />
<br />
The term work-product means any artifact that<br />
is the outcome of a process used to create the<br />
final software product. Examples of a work-product<br />
include a system/subsystem specification, a<br />
software requirements specification for a software<br />
component of a system, a software design<br />
description, source code, software test documentation,<br />
or reports. While some treatments of quality<br />
are described in terms of final software and<br />
system performance, sound engineering practice<br />
requires that intermediate work-products relevant<br />
to quality be evaluated throughout the software<br />
engineering process.<br />
<br />
===Software Quality Improvement===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=9|parts=c24}} {{referenceLink|number=10|parts=c11s2.4}}}}<br />
<br />
The quality of software products can be improved<br />
through preventative processes or an iterative<br />
process of continual improvement, which<br />
requires management control, coordination, and<br />
feedback from many concurrent processes: (1)<br />
the software life cycle processes, (2) the process<br />
of fault/defect detection, removal, and prevention,<br />
and (3) the quality improvement process.<br />
<br />
The theory and concepts behind quality<br />
improvement—such as building in quality<br />
through the prevention and early detection of<br />
defects, continual improvement, and stakeholder<br />
focus—are pertinent to software engineering.<br />
These concepts are based on the work of experts in quality who have stated that the quality of a<br />
product is directly linked to the quality of the<br />
process used to create it. Approaches such as the<br />
Deming improvement cycle of Plan-Do-Check-<br />
Act (PDCA), evolutionary delivery, kaizen, and<br />
quality function deployment (QFD) offer techniques<br />
to specify quality objectives and determine<br />
whether they are met. The Software Engineering<br />
Institute’s IDEAL is another method [7*]. Quality<br />
management is now recognized by the '''SWEBOK Guide'' as an important discipline.<br />
<br />
Management sponsorship supports process and<br />
product evaluations and the resulting findings.<br />
Then an improvement program is developed<br />
identifying detailed actions and improvement<br />
projects to be addressed in a feasible time frame.<br />
Management support implies that each improvement<br />
project has enough resources to achieve the<br />
goal defined for it. Management sponsorship is<br />
solicited frequently by implementing proactive<br />
communication activities.<br />
<br />
===Software Safety===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s3}}}}<br />
<br />
Safety-critical systems are those in which a system<br />
failure could harm human life, other living<br />
things, physical structures, or the environment.<br />
The software in these systems is safety-critical.<br />
There are increasing numbers of applications<br />
of safety-critical software in a growing number<br />
of industries. Examples of systems with safetycritical<br />
software include mass transit systems,<br />
chemical manufacturing plants, and medical<br />
devices. The failure of software in these systems<br />
could have catastrophic effects. There are industry<br />
standards, such as DO-178C [11], and emerging<br />
processes, tools, and techniques for developing<br />
safetycritical software. The intent of these<br />
standards, tools, and techniques is to reduce the<br />
risk of injecting faults into the software and thus<br />
improve software reliability.<br />
<br />
Safety-critical software can be categorized as<br />
direct or indirect. Direct is that software embedded<br />
in a safety-critical system, such as the flight<br />
control computer of an aircraft. Indirect includes<br />
software applications used to develop safetycritical<br />
software. Indirect software is included in<br />
software engineering environments and software<br />
test environments.<br />
<br />
Three complementary techniques for reducing<br />
the risk of failure are avoidance, detection<br />
and removal, and damage limitation. These<br />
techniques impact software functional requirements,<br />
software performance requirements, and<br />
development processes. Increasing levels of risk<br />
imply increasing levels of software quality assurance<br />
and control techniques such as inspections.<br />
Higher risk levels may necessitate more thorough<br />
inspections of requirements, design, and code<br />
or the use of more formal analytical techniques.<br />
Another technique for managing and controlling<br />
software risk is building assurance cases. An<br />
assurance case is a reasoned, auditable artifact<br />
created to support the contention that its claim<br />
or claims are satisfied. It contains the following<br />
and their relationships: one or more claims about<br />
properties; arguments that logically link the evidence<br />
and any assumptions to the claims; and a<br />
body of evidence and assumptions supporting<br />
these arguments [12].<br />
<br />
==Software Quality Management Processes==<br />
<br />
Software quality management is the collection of<br />
all processes that ensure that software products,<br />
services, and life cycle process implementations<br />
meet organizational software quality objectives<br />
and achieve stakeholder satisfaction [13, 14].<br />
SQM defines processes, process owners, requirements<br />
for the processes, measurements of the<br />
processes and their outputs, and feedback channels<br />
throughout the whole software life cycle.<br />
<br />
SQM comprises four subcategories: software<br />
quality planning, software quality assurance<br />
(SQA), software quality control (SQC), and software<br />
process improvement (SPI). Software quality<br />
planning includes determining which quality<br />
standards are to be used, defining specific quality<br />
goals, and estimating the effort and schedule of<br />
software quality activities. In some cases, software<br />
quality planning also includes defining the<br />
software quality processes to be used. SQA activities<br />
define and assess the adequacy of software<br />
processes to provide evidence that establishes<br />
confidence that the software processes are appropriate<br />
for and produce software products of suitable<br />
quality for their intended purposes [5]. SQC<br />
activities examine specific project artifacts (documents<br />
and executables) to determine whether they comply with standards established for the project<br />
(including requirements, constraints, designs,<br />
contracts, and plans). SQC evaluates intermediate<br />
products as well as the final products.<br />
<br />
The fourth SQM category dealing with improvement<br />
has various names within the software industry,<br />
including SPI, software quality improvement,<br />
and software corrective and preventive action. The<br />
activities in this category seek to improve process<br />
effectiveness, efficiency, and other characteristics<br />
with the ultimate goal of improving software<br />
quality. Although SPI could be included in any of<br />
the first three categories, an increasing number<br />
of organizations organize SPI into a separate category<br />
that may span across many projects (see the<br />
Software Engineering Process KA).<br />
<br />
Software quality processes consist of tasks<br />
and techniques to indicate how software plans<br />
(e.g., software management, development, quality<br />
management, or configuration management<br />
plans) are being implemented and how well the<br />
intermediate and final products are meeting their<br />
specified requirements. Results from these tasks<br />
are assembled in reports for management before<br />
corrective action is taken. The management of<br />
an SQM process is tasked with ensuring that the<br />
results of these reports are accurate.<br />
<br />
Risk management can also play an important<br />
role in delivering quality software. Incorporating<br />
disciplined risk analysis and management techniques<br />
into the software life cycle processes can<br />
help improve product quality (see the Software<br />
Engineering Management KA for related material<br />
on risk management).<br />
<br />
===Software Quality Assurance===<br />
{{RightSection|{{referenceLink|number=7|parts=c4–c6, c11, c12, c26–27}}}}<br />
<br />
To quell a widespread misunderstanding, software<br />
quality assurance is not testing. software<br />
quality assurance (SQA) is a set of activities that<br />
define and assess the adequacy of software processes<br />
to provide evidence that establishes confidence<br />
that the software processes are appropriate<br />
and produce software products of suitable quality<br />
for their intended purposes. A key attribute of<br />
SQA is the objectivity of the SQA function with<br />
respect to the project. The SQA function may<br />
also be organizationally independent of the project;<br />
that is, free from technical, managerial, and financial pressures from the project [5]. SQA has<br />
two aspects: product assurance and process assurance,<br />
which are explained in section 2.3.<br />
<br />
The software quality plan (in some industry<br />
sectors it is termed the software quality assurance<br />
plan) defines the activities and tasks employed<br />
to ensure that software developed for a specific<br />
product satisfies the project’s established requirements<br />
and user needs within project cost and<br />
schedule constraints and is commensurate with<br />
project risks. The SQAP first ensures that quality<br />
targets are clearly defined and understood.<br />
<br />
The SQA plan’s quality activities and tasks are<br />
specified with their costs, resource requirements,<br />
objectives, and schedule in relation to related<br />
objectives in the software engineering management,<br />
software development, and software maintenance<br />
plans. The SQA plan should be consistent<br />
with the software configuration management<br />
plan (see the Software Configuration Management<br />
KA). The SQA plan identifies documents,<br />
standards, practices, and conventions governing<br />
the project and how these items are checked and<br />
monitored to ensure adequacy and compliance.<br />
The SQA plan also identifies measures; statistical<br />
techniques; procedures for problem reporting and<br />
corrective action; resources such as tools, techniques,<br />
and methodologies; security for physical<br />
media; training; and SQA reporting and documentation.<br />
Moreover, the SQA plan addresses<br />
the software quality assurance activities of any<br />
other type of activity described in the software<br />
plans—such as procurement of supplier software<br />
for the project, commercial off-the-shelf software<br />
(COTS) installation, and service after delivery of<br />
the software. It can also contain acceptance criteria<br />
as well as reporting and management activities<br />
that are critical to software quality.<br />
<br />
===Verification & Validation===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s2.3, c8, c15s1.1, c21s3.3}}}}<br />
<br />
As stated in [15],<br />
<br />
* The purpose of V&V is to help the development organization build quality into the system during the life cycle. V&V processes provide an objective assessment of products and processes throughout the life cycle. This assessment demonstrates whether the requirements are correct, complete, accurate, consistent, and testable. The V&V processes determine whether the development products of a given activity<br />
conform to the requirements of that activity and whether the product satisfies its intended use and user needs.<br />
<br />
Verification is an attempt to ensure that the<br />
product is built correctly, in the sense that the<br />
output products of an activity meet the specifications<br />
imposed on them in previous activities.<br />
Validation is an attempt to ensure that the right<br />
product is built—that is, the product fulfills its<br />
specific intended purpose. Both the verification<br />
process and the validation process begin early<br />
in the development or maintenance phase. They<br />
provide an examination of key product features<br />
in relation to both the product’s immediate predecessor<br />
and the specifications to be met.<br />
<br />
The purpose of planning V&V is to ensure that<br />
each resource, role, and responsibility is clearly<br />
assigned. The resulting V&V plan documents<br />
describe the various resources and their roles and<br />
activities, as well as the techniques and tools to be<br />
used. An understanding of the different purposes of<br />
each V&V activity helps in the careful planning of<br />
the techniques and resources needed to fulfill their<br />
purposes. The plan also addresses the management,<br />
communication, policies, and procedures of<br />
the V&V activities and their interaction, as well as<br />
defect reporting and documentation requirements.<br />
<br />
===Reviews and Audits===<br />
{{RightSection|{{referenceLink|number=9|parts=c24s3}} {{referenceLink|number=16}}}}<br />
<br />
Reviews and audit processes are broadly defined<br />
as static—meaning that no software programs or<br />
models are executed—examination of software<br />
engineering artifacts with respect to standards that<br />
have been established by the organization or project<br />
for those artifacts. Different types of reviews<br />
and audits are distinguished by their purpose, levels<br />
of independence, tools and techniques, roles,<br />
and by the subject of the activity. Product assurance<br />
and process assurance audits are typically<br />
conducted by software quality assurance (SQA)<br />
personnel who are independent of development teams. Management reviews are conducted by<br />
organizational or project management. The engineering<br />
staff conducts technical reviews.<br />
<br />
* Management reviews evaluate actual project results with respect to plans.<br />
* Technical reviews (including inspections, walkthrough, and desk checking) examine engineering work-products.<br />
* Process assurance audits. SQA process assurance activities make certain that the processes used to develop, install, operate, and maintain software conform to contracts, comply with any imposed laws, rules, and regulations and are adequate, efficient and effective for their intended purpose [5].<br />
* Product assurance audits. SQA product assurance activities make certain to provide evidence that software products and related documentation are identified in and comply with contracts; and ensure that nonconformances are identified and addressed [5].<br />
<br />
====Management Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a management review is to monitor progress, determine the status of plans and schedules, and evaluate the effectiveness<br />
of management processes, tools and techniques. Management reviews compare actual project results against plans to determine the status of projects or maintenance efforts. The main parameters of management reviews are project cost, schedule, scope, and quality. Management reviews evaluate decisions about corrective actions, changes in the allocation of resources, or changes to the scope of the project.<br />
<br />
Inputs to management reviews may include<br />
audit reports, progress reports, V&V reports, and<br />
plans of many types, including risk management,<br />
project management, software configuration<br />
management, software safety, and risk assessment,<br />
among others. (Refer to the Software Engineering<br />
Management and the Software Configuration<br />
Management KAs for related material.)<br />
<br />
====Technical Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a technical review is to evaluate a software product by a team of qualified personnel to determine its suitability for its intended use and identify discrepancies from specifications and standards. It provides management with evidence to confirm the technical status of the project.<br />
<br />
Although any work-product can be reviewed,<br />
technical reviews are performed on the main<br />
software engineering work-products of software<br />
requirements and software design.<br />
<br />
Purpose, roles, activities, and most importantly<br />
the level of formality distinguish different types<br />
of technical reviews. Inspections are the most formal,<br />
walkthroughs less, and pair reviews or desk<br />
checks are the least formal.<br />
<br />
Examples of specific roles include a decision<br />
maker (i.e., software lead), a review leader, a<br />
recorder, and checkers (technical staff members<br />
who examine the work-products). Reviews are<br />
also distinguished by whether meetings (face to<br />
face or electronic) are included in the process. In<br />
some review methods checkers solitarily examine<br />
work-products and send their results back to<br />
a coordinator. In other methods checkers work<br />
cooperatively in meetings. A technical review<br />
may require that mandatory inputs be in place in<br />
order to proceed:<br />
<br />
* Statement of objectives<br />
* Specific software product<br />
* Specific project management plan<br />
* Issues list associated with this product<br />
* Technical review procedure.<br />
<br />
The team follows the documented review procedure.<br />
The technical review is completed once<br />
all the activities listed in the examination have<br />
been completed.<br />
<br />
Technical reviews of source code may include a<br />
wide variety of concerns such as analysis of algorithms,<br />
utilization of critical computer resources,<br />
adherence to coding standards, structure and organization of code for testability, and safetycritical<br />
considerations.<br />
<br />
Note that technical reviews of source code or<br />
design models such as UML are also termed static<br />
analysis (see topic 3, Practical Considerations).<br />
<br />
====Inspections====<br />
<br />
“The purpose of an inspection is to detect and<br />
identify software product anomalies” [16*].<br />
Some important differentiators of inspections as<br />
compared to other types of technical reviews are<br />
these:<br />
<br />
* 1. Rules. Inspections are based upon examining a work-product with respect to a defined set of criteria specified by the organization. Sets of rules can be defined for different types of workproducts (e.g., rules for requirements,architecture descriptions, source code).<br />
* 2. Sampling. Rather that attempt to examine every word and figure in a document, the inspection process allows checkers to evaluate defined subsets (samples) of the documents under review.<br />
* 3. Peer. Individuals holding management positions over members of the inspection team do not participate in the inspection. This is<br />
a key distinction between peer review and management review.<br />
* 4. Led. An impartial moderator who is trained in inspection techniques leads inspection meetings.<br />
* 5. Meeting. The inspection process includes meetings (face to face or electronic) conducted by a moderator according to a formal procedure in which inspection team members report the anomalies they have found and other issues.<br />
<br />
Software inspections always involve the author<br />
of an intermediate or final product; other reviews<br />
might not. Inspections also include an inspection<br />
leader, a recorder, a reader, and a few (two to five)<br />
checkers (inspectors). The members of an inspection<br />
team may possess different expertise, such as<br />
domain expertise, software design method expertise,<br />
or programming language expertise. Inspections<br />
are usually conducted on one relatively small section of the product at a time (samples).<br />
Each team member examines the software product<br />
and other review inputs prior to the review<br />
meeting, perhaps by applying an analytical technique<br />
(see section 3.3.3) to a small section of<br />
the product or to the entire product with a focus<br />
on only one aspect—e.g., interfaces. During the<br />
inspection, the moderator conducts the session<br />
and verifies that everyone has prepared for the<br />
inspection and conducts the session. The inspection<br />
recorder documents anomalies found. A set<br />
of rules, with criteria and questions germane to<br />
the issues of interest, is a common tool used in<br />
inspections. The resulting list often classifies the<br />
anomalies (see section 3.2, Defect Characterization)<br />
and is reviewed for completeness and accuracy<br />
by the team. The inspection exit decision<br />
corresponds to one of the following options:<br />
<br />
* 1. Accept with no or, at most, minor reworking<br />
* 2. Accept with rework verification<br />
* 3. Reinspect.<br />
<br />
====Walkthroughs====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a systematic walk-through is to evaluate a software product. A walkthrough may be conducted for the purpose of educating an audience regarding a software product.<br />
<br />
Walkthroughs are distinguished from inspections.<br />
The main difference is that the author presents<br />
the work-product to the other participants in<br />
a meeting (face to face or electronic). Unlike an<br />
inspection, the meeting participants may not have<br />
necessarily seen the material prior to the meeting.<br />
The meetings may be conducted less formally.<br />
The author takes the role of explaining and<br />
showing the material to participants and solicits<br />
feedback. Like inspections, walkthroughs may be<br />
conducted on any type of work-product including<br />
project plan, requirements, design, source code,<br />
and test reports.<br />
<br />
====Process Assurance and Product Assurance Audits====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes<br />
to applicable regulations, standards, guidelines, plans, and procedures.<br />
<br />
Process assurance audits determine the adequacy<br />
of plans, schedules, and requirements to achieve<br />
project objectives [5]. The audit is a formally<br />
organized activity with participants having specific<br />
roles—such as lead auditor, another auditor, a<br />
recorder, or an initiator—and including a representative<br />
of the audited organization. Audits identify<br />
instances of nonconformance and produce a report<br />
requiring the team to take corrective action.<br />
<br />
While there may be many formal names for<br />
reviews and audits, such as those identified in the<br />
standard [16*], the important point is that they<br />
can occur on almost any product at any stage of<br />
the development or maintenance process.<br />
<br />
==Practical Considerations==<br />
===Software Quality Requirements===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s1}} {{referenceLink|number=18|parts=c12}} {{referenceLink|number=17|parts=c15s3.2.2, c15s3.3.1, c16s9.10}}}}<br />
====Influence Factors====<br />
Various factors influence planning, management,<br />
and selection of SQM activities and techniques,<br />
including<br />
<br />
* the domain of the system in which the software resides; the system functions could be safety-critical, mission-critical, businesscritical,security-critical<br />
* the physical environment in which the software system resides<br />
* system and software functional (what the system does) and quality (how well the system performs its functions) requirements<br />
* the commercial (external) or standard (internal) components to be used in the system<br />
* the specific software engineering standards applicable<br />
* the methods and software tools to be used for development and maintenance and for quality evaluation and improvement<br />
* the budget, staff, project organization, plans, and scheduling of all processes<br />
* the intended users and use of the system<br />
* the integrity level of the system.<br />
<br />
Information on these factors influences how<br />
the SQM processes are organized and documented,<br />
how specific SQM activities are selected,<br />
what resources are needed, and which of those<br />
resources impose bounds on the efforts.<br />
<br />
====Dependability====<br />
<br />
In cases where system failure may have extremely<br />
severe consequences, overall dependability (hardware,<br />
software, and human or operational) is the<br />
main quality requirement over and above basic<br />
functionality. This is the case for the following<br />
reasons: system failures affect a large number of<br />
people; users often reject systems that are unreliable,<br />
unsafe, or insecure; system failure costs<br />
may be enormous; and undependable systems<br />
may cause information loss. System and software<br />
dependability include such characteristics<br />
as availability, reliability, safety, and security.<br />
When developing dependable software, tools and<br />
techniques can be applied to reduce the risk of<br />
injecting faults into the intermediate deliverables<br />
or the final software product. Verification, validation,<br />
and testing processes, techniques, methods,<br />
and tools identify faults that impact dependability<br />
as early as possible in the life cycle. Additionally,<br />
mechanisms may need to be in place in the<br />
software to guard against external attacks and to<br />
tolerate faults.<br />
<br />
====Integrity Levels of Software====<br />
<br />
Defining integrity levels is a method of risk<br />
management.<br />
<br />
* Software integrity levels are a range of values that represent software complexity, criticality, risk, safety level, security level, desired performance, reliability, or other project-unique characteristics that define the importance of the software to the user and acquirer. The characteristics used to determine software integrity level vary depending on the intended application and use of the system. The software is a part of the system, and its integrity level is to be determined as a part of that system.<br />
<br />
The assigned software integrity levels may<br />
change as the software evolves. Design, coding,<br />
procedural, and technology features implemented<br />
in the system or software can raise or lower the<br />
assigned software integrity levels. The software<br />
integrity levels established for a project result<br />
from agreements among the acquirer, supplier,<br />
developer, and independent assurance authorities.<br />
A software integrity level scheme is a tool used in<br />
determining software integrity levels. [5]<br />
<br />
As noted in [17*], “the integrity levels can be<br />
applied during development to allocate additional<br />
verification and validation efforts to high-integrity<br />
components.”<br />
<br />
===Defect Characterization===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s3, c8s8, c10s2}}}}<br />
<br />
Software quality evaluation (i.e., software quality<br />
control) techniques find defects, faults and failures.<br />
Characterizing these techniques leads to an<br />
understanding of the product, facilitates corrections<br />
to the process or the product, and informs<br />
management and other stakeholders of the status<br />
of the process or product. Many taxonomies<br />
exist and, while attempts have been made to gain<br />
consensus, the literature indicates that there are<br />
quite a few in use. Defect characterization is also<br />
used in audits and reviews, with the review leader<br />
often presenting a list of issues provided by team<br />
members for consideration at a review meeting.<br />
<br />
As new design methods and languages evolve,<br />
along with advances in overall software technologies,<br />
new classes of defects appear, and a great<br />
deal of effort is required to interpret previously<br />
defined classes. When tracking defects, the software<br />
engineer is interested in not only the number<br />
of defects but also the types. Information alone,<br />
without some classification, may not be sufficient<br />
to identify the underlying causes of the defects.<br />
Specific types of problems need to be grouped to<br />
identify trends over time. The point is to establish<br />
a defect taxonomy that is meaningful to the organization<br />
and to software engineers.<br />
<br />
Software quality control activities discover information<br />
at all stages of software development and<br />
maintenance. In some cases, the word ''defect'' is<br />
overloaded to refer to different types of anomalies.<br />
However, different engineering cultures and standards<br />
may use somewhat different meanings for<br />
these terms. The variety of terms prompts this section<br />
to provide a widely used set of definitions [19]:<br />
<br />
* ''Computational Error'': “the difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.”<br />
* ''Error'': “A human action that produces an incorrect result.” A slip or mistake that a person makes. Also called human error.<br />
* ''Defect'': An “imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced.” A defect is caused by a person committing an error.<br />
* ''Fault'': A defect in source code. An “incorrect step, process, or data definition in computer program.” The encoding of a human error in source code. Fault is the formal name of a bug.<br />
* ''Failure'': An “event in which a system or system component does not perform a required function within specified limits.” A failure is<br />
produced when a fault is encountered by the processor under specified conditions.<br />
<br />
Using these definitions three widely used software<br />
quality measurements are defect density<br />
(number of defects per unit size of documents),<br />
fault density (number of faults per 1K lines of<br />
code), and failure intensity (failures per use-hour<br />
or per test-hour). Reliability models are built<br />
from failure data collected during software testing<br />
or from software in service and thus can be<br />
used to estimate the probability of future failures<br />
and to assist in decisions on when to stop testing.<br />
<br />
One probable action resulting from SQM findings<br />
is to remove the defects from the product<br />
under examination (e.g., find and fix bugs, create<br />
new build). Other activities attempt to eliminate the causes of the defects—for example, root cause<br />
analysis (RCA). RCA activities include analyzing<br />
and summarizing the findings to find root causes<br />
and using measurement techniques to improve<br />
the product and the process as well as to track the<br />
defects and their removal. Process improvement<br />
is primarily discussed in the Software Engineering<br />
Process KA, with the SQM process being a<br />
source of information.<br />
<br />
Data on inadequacies and defects found by<br />
software quality control techniques may be lost<br />
unless they are recorded. For some techniques<br />
(e.g., technical reviews, audits, inspections),<br />
recorders are present to set down such information,<br />
along with issues and decisions. When automated<br />
tools are used (see topic 4, Software Quality<br />
Tools), the tool output may provide the defect<br />
information. Reports about defects are provided<br />
to the management of the organization.<br />
<br />
===Software Quality Management Techniques===<br />
{{RightSection|{{referenceLink|number=7|parts=c7s3}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=c12s5, c15s1, p417}}{{referenceLink|number=16}}}}<br />
<br />
Software quality control techniques can be categorized<br />
in many ways, but a straightforward<br />
approach uses just two categories: static and<br />
dynamic. Dynamic techniques involve executing<br />
the software; static techniques involve analyzing<br />
documents<br />
<br />
====Static Techniques====<br />
<br />
Static techniques examine software documentation<br />
(including requirements, interface specifications,<br />
designs, and models) and software source<br />
code without executing the code. There are many<br />
tools and techniques for statically examining software<br />
work-products (see section 2.3.2). In addition,<br />
tools that analyze source code control flow<br />
and search for dead code are considered to be<br />
static analysis tools because they do not involve<br />
executing the software code.<br />
<br />
Other, more formal, types of analytical techniques<br />
are known as formal methods. They are<br />
notably used to verify software requirements and<br />
designs. They have mostly been used in the verification<br />
of crucial parts of critical systems, such<br />
as specific security and safety requirements. (See also Formal Methods in the Software Engineering<br />
Models and Methods KA.)<br />
<br />
====Dynamic Techniques====<br />
<br />
Dynamic techniques involve executing the software<br />
code. Different kinds of dynamic techniques<br />
are performed throughout the development and<br />
maintenance of software. Generally, these are<br />
testing techniques, but techniques such as simulation<br />
and model analysis may be considered<br />
dynamic (see the Software Engineering Models<br />
and Methods KA). Code reading is considered a<br />
static technique, but experienced software engineers<br />
may execute the code as they read through<br />
it. Code reading may utilize dynamic techniques.<br />
This discrepancy in categorizing indicates that<br />
people with different roles and experience in the<br />
organization may consider and apply these techniques<br />
differently.<br />
<br />
Different groups may perform testing during<br />
software development, including groups independent<br />
of the development team. The Software<br />
Testing KA is devoted entirely to this subject.<br />
<br />
====Testing====<br />
<br />
Two types of testing may fall under V&V because<br />
of their responsibility for the quality of the materials<br />
used in the project:<br />
<br />
* Evaluation and tests of tools to be used on the project<br />
* Conformance tests (or review of conformance tests) of components and COTS products to be used in the product<br />
<br />
Sometimes an independent (third-party or<br />
IV&V) organization may be tasked to perform<br />
testing or to monitor the test process V&V may<br />
be called upon to evaluate the testing itself: adequacy<br />
of plans, processes, and procedures, and<br />
adequacy and accuracy of results.<br />
<br />
The third party is not the developer, nor is it<br />
associated with the development of the product.<br />
Instead, the third party is an independent facility,<br />
usually accredited by some body of authority.<br />
Their purpose is to test a product for conformance<br />
to a specific set of requirements (see the Software Testing KA).<br />
<br />
===Software Quality Measurement===<br />
{{RightSection|{{referenceLink|number=3|parts=c4}} {{referenceLink|number=8|parts=c17}} {{referenceLink|number=9|parts=p90}}}}<br />
<br />
Software quality measurements are used to<br />
support decision-making. With the increasing<br />
sophistication of software, questions of quality<br />
go beyond whether or not the software works to<br />
how well it achieves measurable quality goals.<br />
<br />
Decisions supported by software quality measurement<br />
include determining levels of software<br />
quality (notably because models of software<br />
product quality include measures to determine<br />
the degree to which the software product achieves<br />
quality goals); managerial questions about effort,<br />
cost, and schedule; determining when to stop testing<br />
and release a product (see Termination under<br />
section 5.1, Practical Considerations, in the Software<br />
Testing KA); and determining the efficacy<br />
of process improvement efforts.<br />
<br />
The cost of SQM processes is an issue frequently<br />
raised in deciding how a project or a software<br />
development and maintenance group should<br />
be organized. Often, generic models of cost are<br />
used, which are based on when a defect is found<br />
and how much effort it takes to fix the defect relative<br />
to finding the defect earlier in the development<br />
process. Software quality measurement data<br />
collected internally may give a better picture of<br />
cost within this project or organization.<br />
<br />
While the software quality measurement data<br />
may be useful in itself (e.g., the number of defective<br />
requirements or the proportion of defective<br />
requirements), mathematical and graphical techniques<br />
can be applied to aid in the interpretation<br />
of the measures (see the Engineering Foundations<br />
KA). These techniques include<br />
<br />
* descriptive statistics based (e.g., Pareto analysis, run charts, scatter plots, normal distribution)<br />
* statistical tests (e.g., the binomial test, chisquared test)<br />
* trend analysis (e.g., control charts; see''The Quality Toolbox'' in the list of further readings)<br />
* prediction (e.g., reliability models).<br />
<br />
Descriptive statistics-based techniques and<br />
tests often provide a snapshot of the more troublesome areas of the software product under<br />
examination. The resulting charts and graphs<br />
are visualization aids, which the decision makers<br />
can use to focus resources and conduct process<br />
improvements where they appear to be most<br />
needed. Results from trend analysis may indicate<br />
that a schedule is being met, such as in testing, or<br />
that certain classes of faults may become more<br />
likely to occur unless some corrective action is<br />
taken in development. The predictive techniques<br />
assist in estimating testing effort and schedule<br />
and in predicting failures. More discussion on<br />
measurement in general appears in the Software<br />
Engineering Process and Software Engineering<br />
Management KAs. More specific information on<br />
testing measurement is presented in the Software<br />
Testing KA.<br />
<br />
Software quality measurement includes measuring<br />
defect occurrences and applying statistical<br />
methods to understand the types of defects that<br />
occur most frequently. This information may be<br />
used by software process improvement for determining<br />
methods to prevent, reduce, or eliminate<br />
their recurrence. They also aid in understanding<br />
trends, how well detection and containment techniques<br />
are working, and how well the development<br />
and maintenance processes are progressing.<br />
<br />
From these measurement methods, defect<br />
profiles can be developed for a specific application<br />
domain. Then, for the next software project<br />
within that organization, the profiles can be used<br />
to guide the SQM processes—that is, to expend<br />
the effort where problems are most likely to occur.<br />
Similarly, benchmarks, or defect counts typical of<br />
that domain, may serve as one aid in determining<br />
when the product is ready for delivery. Discussion<br />
on using data from SQM to improve development<br />
and maintenance processes appears in the<br />
Software Engineering Management and Software<br />
Engineering Process KAs.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_10:_Software_Quality&diff=869Chapter 10: Software Quality2015-08-29T13:20:24Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}<br />
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}<br />
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}<br />
{{Acronym|name=FTA|description=Fault Tree Analysis}}<br />
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}<br />
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}<br />
{{Acronym|name=QFD|description=Quality Function Deployment}}<br />
{{Acronym|name=SPI|description=Software Process Improvement}}<br />
{{Acronym|name=SQA|description=Software Quality Assurance}}<br />
{{Acronym|name=SQC|description=Software Quality Control}}<br />
{{Acronym|name=SQM|description=Software Quality Management}}<br />
{{Acronym|name=TQM|description=Total Quality Management}}<br />
{{Acronym|name=V&V|description=Verification and Validation}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
What is software quality, and why is it so important<br />
that it is included in many knowledge areas<br />
(KAs) of the ''SWEBOK Guide''?<br />
<br />
One reason is that the term ''software quality'' is<br />
overloaded. Software quality may refer: to desirable<br />
characteristics of software products, to the<br />
extent to which a particular software product possess<br />
those characteristics, and to processes, tools,<br />
and techniques used to achieve those characteristics.<br />
Over the years, authors and organizations<br />
have defined the term quality differently. To Phil<br />
Crosby, it was “conformance to requirements”<br />
[1]. Watts Humphrey refers to it as “achieving<br />
excellent levels of “fitness for use” [2]. Meanwhile,<br />
IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”<br />
[3*, p8].<br />
<br />
More recently, software quality is defined as the<br />
“capability of software product to satisfy stated<br />
and implied needs under specified conditions” [4]<br />
and as “the degree to which a software product<br />
meets established requirements; however, quality<br />
depends upon the degree to which those established<br />
requirements accurately represent stakeholder<br />
needs, wants, and expectations” [5]. Both<br />
definitions embrace the premise of conformance<br />
to requirements. Neither refers to types of requirements<br />
(e.g., functional, reliability, performance,<br />
dependability, or any other characteristic). Significantly,<br />
however, these definitions emphasize that<br />
quality is dependent upon requirements.<br />
<br />
These definitions also illustrate another reason<br />
for the prevalence of software quality throughout<br />
this ''Guide'': a frequent ambiguity of ''software quality'' versus ''software quality requirements''<br />
(“the -''ilities''” is a common shorthand). Software<br />
quality requirements are actually attributes of (or<br />
constraints on) functional requirements (what<br />
the system does). Software requirements may<br />
also specify resource usage, a communication<br />
protocol, or many other characteristics. This KA<br />
attempts clarity by using ''software quality'' in the<br />
broadest sense from the definitions above and<br />
by using ''software quality requirements'' as constraints<br />
on functional requirements. Software<br />
quality is achieved by conformance to all requirements<br />
regardless of what characteristic is specified<br />
or how requirements are grouped or named.<br />
<br />
Software quality is also considered in many of<br />
the SWEBOK KAs because it is a basic parameter<br />
of a software engineering effort. For all engineered<br />
products, the primary goal is delivering<br />
maximum stakeholder value, while balancing the<br />
constraints of development cost and schedule;<br />
this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements.<br />
For software products, stakeholders could<br />
value price (what they pay for the product), lead<br />
time (how fast they get the product), and software<br />
quality.<br />
<br />
This KA addresses definitions and provides an<br />
overview of practices, tools, and techniques for<br />
defining software quality and for appraising the<br />
state of software quality during development,<br />
maintenance, and deployment. Cited references<br />
provide additional details.}}<br />
[[File:Breakdown of Topics for the Software Quality.jpg|thumb|300px|frame|Figure 10.1: Breakdown of Topics for the Software Quality KA]]<br />
{{IntroSection|title=Breakdown of Topics for Software Quality|body=<br />
The breakdown of topics for the Software Quality KA is presented in Figure 10.1.}}<br />
<br />
==Software Quality Fundamentals==<br />
<br />
Reaching agreement on what constitutes quality<br />
for all stakeholders and clearly communicating<br />
that agreement to software engineers require that the many aspects of quality be formally defined<br />
and discussed.<br />
<br />
A software engineer should understand quality<br />
concepts, characteristics, values, and their<br />
application to the software under development or<br />
maintenance. The important concept is that the<br />
software requirements define the required quality<br />
attributes of the software. Software requirements<br />
influence the measurement methods and acceptance<br />
criteria for assessing the degree to which<br />
the software and related documentation achieve<br />
the desired quality levels.<br />
<br />
===Software Engineering Culture and Ethics===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=6|parts=c2s3.5}}}}<br />
<br />
Software engineers are expected to share a commitment<br />
to software quality as part of their culture.<br />
A healthy software engineering culture includes<br />
many characteristics, including the understanding<br />
that tradeoffs among cost, schedule, and quality<br />
are a basic tenant of the engineering of any product.<br />
A strong software engineering ethic assumes that engineers accurately report information, conditions,<br />
and outcomes related to quality.<br />
<br />
Ethics also play a significant role in software<br />
quality, the culture, and the attitudes of software<br />
engineers. The IEEE Computer Society and the<br />
ACM have developed a code of ethics and professional<br />
practice (see Codes of Ethics and Professional<br />
Conduct in the Software Engineering<br />
Professional Practice KA).<br />
<br />
===Value and Costs of Quality===<br />
{{RightSection|{{referenceLink|number=7|parts=c17, c22}}}}<br />
<br />
Defining and then achieving software quality is<br />
not simple. Quality characteristics may or may<br />
not be required, or they may be required to a<br />
greater or lesser degree, and tradeoffs may be<br />
made among them. To help determine the level<br />
of software quality, i.e., achieving stakeholder<br />
value, this section presents cost of software quality<br />
(CoSQ): a set of measurements derived from<br />
the economic assessment of software quality<br />
development and maintenance processes. The<br />
CoSQ measurements are examples of process<br />
measurements that may be used to infer characteristics<br />
of a product.<br />
<br />
The premise underlying the CoSQ is that the<br />
level of quality in a software product can be<br />
inferred from the cost of activities related to dealing<br />
with the consequences of poor quality. Poor<br />
quality means that the software product does not<br />
fully “satisfy stated and implied needs” or “established<br />
requirements.” There are four cost of quality<br />
categories: prevention, appraisal, internal failure,<br />
and external failure.<br />
<br />
Prevention costs include investments in software<br />
process improvement efforts, quality infrastructure,<br />
quality tools, training, audits, and management<br />
reviews. These costs are usually not specific<br />
to a project; they span the organization. Appraisal<br />
costs arise from project activities that find defects.<br />
These appraisal activities can be categorized into<br />
costs of reviews (design, peer) and costs of testing<br />
(software unit testing, software integration,<br />
system level testing, acceptance testing); appraisal<br />
costs would be extended to subcontracted software<br />
suppliers. Costs of internal failures are those that<br />
are incurred to fix defects found during appraisal<br />
activities and discovered prior to delivery of the software product to the customer. External failure<br />
costs include activities to respond to software<br />
problems discovered after delivery to the customer. <br />
<br />
Software engineers should be able to use CoSQ<br />
methods to ascertain levels of software quality<br />
and should also be able to present quality alternatives<br />
and their costs so that tradeoffs between<br />
cost, schedule, and delivery of stakeholder value<br />
can be made.<br />
<br />
===Models and Quality Characteristics===<br />
{{RightSection|{{referenceLink|number=3|parts=c24s1}} {{referenceLink|number=7|parts=c2s4}} {{referenceLink|number=8|parts=c17}}}}<br />
<br />
Terminology for software quality characteristics<br />
differs from one taxonomy (or model of software<br />
quality) to another, each model perhaps having<br />
a different number of hierarchical levels and a<br />
different total number of characteristics. Various<br />
authors have produced models of software quality<br />
characteristics or attributes that can be useful<br />
for discussing, planning, and rating the quality<br />
of software products. ISO/IEC 25010: 2011 [4]<br />
defines product quality and quality in use as two<br />
related quality models. Appendix B in the SWEBOK<br />
Guide provides a list of applicable standards<br />
for each KA. Standards for this KA cover various<br />
ways of characterizing software quality.<br />
<br />
====Software Process Quality====<br />
<br />
Software quality management and software engineering<br />
process quality have a direct bearing on<br />
the quality of the software product.<br />
<br />
Models and criteria that evaluate the capabilities<br />
of software organizations are primarily project<br />
organization and management considerations<br />
and, as such, are covered in the Software Engineering<br />
Management and Software Engineering<br />
Process KAs.<br />
<br />
It is not possible to completely distinguish process<br />
quality from product quality because process<br />
outcomes include products. Determining whether<br />
a process has the capability to consistently produce<br />
products of desired quality is not simple.<br />
<br />
The software engineering process, discussed<br />
in the Software Engineering Process KA, influences<br />
the quality characteristics of software products,<br />
which in turn affect quality as perceived by<br />
stakeholders.<br />
<br />
====Software Product Quality====<br />
<br />
The software engineer, first of all, must determine<br />
the real purpose of the software. In this regard,<br />
stakeholder requirements are paramount, and they<br />
include quality requirements in addition to functional<br />
requirements. Thus, software engineers<br />
have a responsibility to elicit quality requirements<br />
that may not be explicit at the outset and to understand<br />
their importance as well as the level of difficulty<br />
in attaining them. All software development<br />
processes (e.g., eliciting requirements, designing,<br />
constructing, building, checking, improving quality)<br />
are designed with these quality requirements<br />
in mind and may carry additional development<br />
costs if attributes such as safety, security, and<br />
dependability are important. The additional development<br />
costs help ensure that quality obtained can<br />
be traded off against the anticipated benefits.<br />
<br />
The term work-product means any artifact that<br />
is the outcome of a process used to create the<br />
final software product. Examples of a work-product<br />
include a system/subsystem specification, a<br />
software requirements specification for a software<br />
component of a system, a software design<br />
description, source code, software test documentation,<br />
or reports. While some treatments of quality<br />
are described in terms of final software and<br />
system performance, sound engineering practice<br />
requires that intermediate work-products relevant<br />
to quality be evaluated throughout the software<br />
engineering process.<br />
<br />
===Software Quality Improvement===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s4}} {{referenceLink|number=9|parts=c24}} {{referenceLink|number=10|parts=c11s2.4}}}}<br />
<br />
The quality of software products can be improved<br />
through preventative processes or an iterative<br />
process of continual improvement, which<br />
requires management control, coordination, and<br />
feedback from many concurrent processes: (1)<br />
the software life cycle processes, (2) the process<br />
of fault/defect detection, removal, and prevention,<br />
and (3) the quality improvement process.<br />
<br />
The theory and concepts behind quality<br />
improvement—such as building in quality<br />
through the prevention and early detection of<br />
defects, continual improvement, and stakeholder<br />
focus—are pertinent to software engineering.<br />
These concepts are based on the work of experts in quality who have stated that the quality of a<br />
product is directly linked to the quality of the<br />
process used to create it. Approaches such as the<br />
Deming improvement cycle of Plan-Do-Check-<br />
Act (PDCA), evolutionary delivery, kaizen, and<br />
quality function deployment (QFD) offer techniques<br />
to specify quality objectives and determine<br />
whether they are met. The Software Engineering<br />
Institute’s IDEAL is another method [7*]. Quality<br />
management is now recognized by the '''SWEBOK Guide'' as an important discipline.<br />
<br />
Management sponsorship supports process and<br />
product evaluations and the resulting findings.<br />
Then an improvement program is developed<br />
identifying detailed actions and improvement<br />
projects to be addressed in a feasible time frame.<br />
Management support implies that each improvement<br />
project has enough resources to achieve the<br />
goal defined for it. Management sponsorship is<br />
solicited frequently by implementing proactive<br />
communication activities.<br />
<br />
===Software Safety===<br />
{{RightSection|{{referenceLink|number=9|parts=c11s3}}}}<br />
<br />
Safety-critical systems are those in which a system<br />
failure could harm human life, other living<br />
things, physical structures, or the environment.<br />
The software in these systems is safety-critical.<br />
There are increasing numbers of applications<br />
of safety-critical software in a growing number<br />
of industries. Examples of systems with safetycritical<br />
software include mass transit systems,<br />
chemical manufacturing plants, and medical<br />
devices. The failure of software in these systems<br />
could have catastrophic effects. There are industry<br />
standards, such as DO-178C [11], and emerging<br />
processes, tools, and techniques for developing<br />
safetycritical software. The intent of these<br />
standards, tools, and techniques is to reduce the<br />
risk of injecting faults into the software and thus<br />
improve software reliability.<br />
<br />
Safety-critical software can be categorized as<br />
direct or indirect. Direct is that software embedded<br />
in a safety-critical system, such as the flight<br />
control computer of an aircraft. Indirect includes<br />
software applications used to develop safetycritical<br />
software. Indirect software is included in<br />
software engineering environments and software<br />
test environments.<br />
<br />
Three complementary techniques for reducing<br />
the risk of failure are avoidance, detection<br />
and removal, and damage limitation. These<br />
techniques impact software functional requirements,<br />
software performance requirements, and<br />
development processes. Increasing levels of risk<br />
imply increasing levels of software quality assurance<br />
and control techniques such as inspections.<br />
Higher risk levels may necessitate more thorough<br />
inspections of requirements, design, and code<br />
or the use of more formal analytical techniques.<br />
Another technique for managing and controlling<br />
software risk is building assurance cases. An<br />
assurance case is a reasoned, auditable artifact<br />
created to support the contention that its claim<br />
or claims are satisfied. It contains the following<br />
and their relationships: one or more claims about<br />
properties; arguments that logically link the evidence<br />
and any assumptions to the claims; and a<br />
body of evidence and assumptions supporting<br />
these arguments [12].<br />
<br />
==Software Quality Management Processes==<br />
<br />
Software quality management is the collection of<br />
all processes that ensure that software products,<br />
services, and life cycle process implementations<br />
meet organizational software quality objectives<br />
and achieve stakeholder satisfaction [13, 14].<br />
SQM defines processes, process owners, requirements<br />
for the processes, measurements of the<br />
processes and their outputs, and feedback channels<br />
throughout the whole software life cycle.<br />
<br />
SQM comprises four subcategories: software<br />
quality planning, software quality assurance<br />
(SQA), software quality control (SQC), and software<br />
process improvement (SPI). Software quality<br />
planning includes determining which quality<br />
standards are to be used, defining specific quality<br />
goals, and estimating the effort and schedule of<br />
software quality activities. In some cases, software<br />
quality planning also includes defining the<br />
software quality processes to be used. SQA activities<br />
define and assess the adequacy of software<br />
processes to provide evidence that establishes<br />
confidence that the software processes are appropriate<br />
for and produce software products of suitable<br />
quality for their intended purposes [5]. SQC<br />
activities examine specific project artifacts (documents<br />
and executables) to determine whether they comply with standards established for the project<br />
(including requirements, constraints, designs,<br />
contracts, and plans). SQC evaluates intermediate<br />
products as well as the final products.<br />
<br />
The fourth SQM category dealing with improvement<br />
has various names within the software industry,<br />
including SPI, software quality improvement,<br />
and software corrective and preventive action. The<br />
activities in this category seek to improve process<br />
effectiveness, efficiency, and other characteristics<br />
with the ultimate goal of improving software<br />
quality. Although SPI could be included in any of<br />
the first three categories, an increasing number<br />
of organizations organize SPI into a separate category<br />
that may span across many projects (see the<br />
Software Engineering Process KA).<br />
<br />
Software quality processes consist of tasks<br />
and techniques to indicate how software plans<br />
(e.g., software management, development, quality<br />
management, or configuration management<br />
plans) are being implemented and how well the<br />
intermediate and final products are meeting their<br />
specified requirements. Results from these tasks<br />
are assembled in reports for management before<br />
corrective action is taken. The management of<br />
an SQM process is tasked with ensuring that the<br />
results of these reports are accurate.<br />
<br />
Risk management can also play an important<br />
role in delivering quality software. Incorporating<br />
disciplined risk analysis and management techniques<br />
into the software life cycle processes can<br />
help improve product quality (see the Software<br />
Engineering Management KA for related material<br />
on risk management).<br />
<br />
===Software Quality Assurance===<br />
{{RightSection|{{referenceLink|number=7|parts=c4–c6, c11, c12, c26–27}}}}<br />
<br />
To quell a widespread misunderstanding, software<br />
quality assurance is not testing. software<br />
quality assurance (SQA) is a set of activities that<br />
define and assess the adequacy of software processes<br />
to provide evidence that establishes confidence<br />
that the software processes are appropriate<br />
and produce software products of suitable quality<br />
for their intended purposes. A key attribute of<br />
SQA is the objectivity of the SQA function with<br />
respect to the project. The SQA function may<br />
also be organizationally independent of the project;<br />
that is, free from technical, managerial, and financial pressures from the project [5]. SQA has<br />
two aspects: product assurance and process assurance,<br />
which are explained in section 2.3.<br />
<br />
The software quality plan (in some industry<br />
sectors it is termed the software quality assurance<br />
plan) defines the activities and tasks employed<br />
to ensure that software developed for a specific<br />
product satisfies the project’s established requirements<br />
and user needs within project cost and<br />
schedule constraints and is commensurate with<br />
project risks. The SQAP first ensures that quality<br />
targets are clearly defined and understood.<br />
<br />
The SQA plan’s quality activities and tasks are<br />
specified with their costs, resource requirements,<br />
objectives, and schedule in relation to related<br />
objectives in the software engineering management,<br />
software development, and software maintenance<br />
plans. The SQA plan should be consistent<br />
with the software configuration management<br />
plan (see the Software Configuration Management<br />
KA). The SQA plan identifies documents,<br />
standards, practices, and conventions governing<br />
the project and how these items are checked and<br />
monitored to ensure adequacy and compliance.<br />
The SQA plan also identifies measures; statistical<br />
techniques; procedures for problem reporting and<br />
corrective action; resources such as tools, techniques,<br />
and methodologies; security for physical<br />
media; training; and SQA reporting and documentation.<br />
Moreover, the SQA plan addresses<br />
the software quality assurance activities of any<br />
other type of activity described in the software<br />
plans—such as procurement of supplier software<br />
for the project, commercial off-the-shelf software<br />
(COTS) installation, and service after delivery of<br />
the software. It can also contain acceptance criteria<br />
as well as reporting and management activities<br />
that are critical to software quality.<br />
<br />
===Verification & Validation===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s2.3, c8, c15s1.1, c21s3.3}}}}<br />
<br />
As stated in [15],<br />
<br />
* The purpose of V&V is to help the development organization build quality into the system during the life cycle. V&V processes provide an objective assessment of products and processes throughout the life cycle. This assessment demonstrates whether the requirements are correct, complete, accurate, consistent, and testable. The V&V processes determine whether the development products of a given activity<br />
conform to the requirements of that activity and whether the product satisfies its intended use and user needs.<br />
<br />
Verification is an attempt to ensure that the<br />
product is built correctly, in the sense that the<br />
output products of an activity meet the specifications<br />
imposed on them in previous activities.<br />
Validation is an attempt to ensure that the right<br />
product is built—that is, the product fulfills its<br />
specific intended purpose. Both the verification<br />
process and the validation process begin early<br />
in the development or maintenance phase. They<br />
provide an examination of key product features<br />
in relation to both the product’s immediate predecessor<br />
and the specifications to be met.<br />
<br />
The purpose of planning V&V is to ensure that<br />
each resource, role, and responsibility is clearly<br />
assigned. The resulting V&V plan documents<br />
describe the various resources and their roles and<br />
activities, as well as the techniques and tools to be<br />
used. An understanding of the different purposes of<br />
each V&V activity helps in the careful planning of<br />
the techniques and resources needed to fulfill their<br />
purposes. The plan also addresses the management,<br />
communication, policies, and procedures of<br />
the V&V activities and their interaction, as well as<br />
defect reporting and documentation requirements.<br />
<br />
===Reviews and Audits===<br />
{{RightSection|{{referenceLink|number=9|parts=c24s3}} {{referenceLink|number=16}}}}<br />
<br />
Reviews and audit processes are broadly defined<br />
as static—meaning that no software programs or<br />
models are executed—examination of software<br />
engineering artifacts with respect to standards that<br />
have been established by the organization or project<br />
for those artifacts. Different types of reviews<br />
and audits are distinguished by their purpose, levels<br />
of independence, tools and techniques, roles,<br />
and by the subject of the activity. Product assurance<br />
and process assurance audits are typically<br />
conducted by software quality assurance (SQA)<br />
personnel who are independent of development teams. Management reviews are conducted by<br />
organizational or project management. The engineering<br />
staff conducts technical reviews.<br />
<br />
* Management reviews evaluate actual project results with respect to plans.<br />
* Technical reviews (including inspections, walkthrough, and desk checking) examine engineering work-products.<br />
* Process assurance audits. SQA process assurance activities make certain that the processes used to develop, install, operate, and maintain software conform to contracts, comply with any imposed laws, rules, and regulations and are adequate, efficient and effective for their intended purpose [5].<br />
* Product assurance audits. SQA product assurance activities make certain to provide evidence that software products and related documentation are identified in and comply with contracts; and ensure that nonconformances are identified and addressed [5].<br />
<br />
====Management Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a management review is to monitor progress, determine the status of plans and schedules, and evaluate the effectiveness<br />
of management processes, tools and techniques. Management reviews compare actual project results against plans to determine the status of projects or maintenance efforts. The main parameters of management reviews are project cost, schedule, scope, and quality. Management reviews evaluate decisions about corrective actions, changes in the allocation of resources, or changes to the scope of the project.<br />
<br />
Inputs to management reviews may include<br />
audit reports, progress reports, V&V reports, and<br />
plans of many types, including risk management,<br />
project management, software configuration<br />
management, software safety, and risk assessment,<br />
among others. (Refer to the Software Engineering<br />
Management and the Software Configuration<br />
Management KAs for related material.)<br />
<br />
====Technical Reviews====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a technical review is to evaluate a software product by a team of qualified personnel to determine its suitability for its intended use and identify discrepancies from specifications and standards. It provides management with evidence to confirm the technical status of the project.<br />
<br />
Although any work-product can be reviewed,<br />
technical reviews are performed on the main<br />
software engineering work-products of software<br />
requirements and software design.<br />
<br />
Purpose, roles, activities, and most importantly<br />
the level of formality distinguish different types<br />
of technical reviews. Inspections are the most formal,<br />
walkthroughs less, and pair reviews or desk<br />
checks are the least formal.<br />
<br />
Examples of specific roles include a decision<br />
maker (i.e., software lead), a review leader, a<br />
recorder, and checkers (technical staff members<br />
who examine the work-products). Reviews are<br />
also distinguished by whether meetings (face to<br />
face or electronic) are included in the process. In<br />
some review methods checkers solitarily examine<br />
work-products and send their results back to<br />
a coordinator. In other methods checkers work<br />
cooperatively in meetings. A technical review<br />
may require that mandatory inputs be in place in<br />
order to proceed:<br />
<br />
* Statement of objectives<br />
* Specific software product<br />
* Specific project management plan<br />
* Issues list associated with this product<br />
* Technical review procedure.<br />
<br />
The team follows the documented review procedure.<br />
The technical review is completed once<br />
all the activities listed in the examination have<br />
been completed.<br />
<br />
Technical reviews of source code may include a<br />
wide variety of concerns such as analysis of algorithms,<br />
utilization of critical computer resources,<br />
adherence to coding standards, structure and organization of code for testability, and safetycritical<br />
considerations.<br />
<br />
Note that technical reviews of source code or<br />
design models such as UML are also termed static<br />
analysis (see topic 3, Practical Considerations).<br />
<br />
====Inspections====<br />
<br />
“The purpose of an inspection is to detect and<br />
identify software product anomalies” [16*].<br />
Some important differentiators of inspections as<br />
compared to other types of technical reviews are<br />
these:<br />
<br />
* 1. Rules. Inspections are based upon examining a work-product with respect to a defined set of criteria specified by the organization. Sets of rules can be defined for different types of workproducts (e.g., rules for requirements,architecture descriptions, source code).<br />
* 2. Sampling. Rather that attempt to examine every word and figure in a document, the inspection process allows checkers to evaluate defined subsets (samples) of the documents under review.<br />
* 3. Peer. Individuals holding management positions over members of the inspection team do not participate in the inspection. This is<br />
a key distinction between peer review and management review.<br />
* 4. Led. An impartial moderator who is trained in inspection techniques leads inspection meetings.<br />
* 5. Meeting. The inspection process includes meetings (face to face or electronic) conducted by a moderator according to a formal procedure in which inspection team members report the anomalies they have found and other issues.<br />
<br />
Software inspections always involve the author<br />
of an intermediate or final product; other reviews<br />
might not. Inspections also include an inspection<br />
leader, a recorder, a reader, and a few (two to five)<br />
checkers (inspectors). The members of an inspection<br />
team may possess different expertise, such as<br />
domain expertise, software design method expertise,<br />
or programming language expertise. Inspections<br />
are usually conducted on one relatively small section of the product at a time (samples).<br />
Each team member examines the software product<br />
and other review inputs prior to the review<br />
meeting, perhaps by applying an analytical technique<br />
(see section 3.3.3) to a small section of<br />
the product or to the entire product with a focus<br />
on only one aspect—e.g., interfaces. During the<br />
inspection, the moderator conducts the session<br />
and verifies that everyone has prepared for the<br />
inspection and conducts the session. The inspection<br />
recorder documents anomalies found. A set<br />
of rules, with criteria and questions germane to<br />
the issues of interest, is a common tool used in<br />
inspections. The resulting list often classifies the<br />
anomalies (see section 3.2, Defect Characterization)<br />
and is reviewed for completeness and accuracy<br />
by the team. The inspection exit decision<br />
corresponds to one of the following options:<br />
<br />
* 1. Accept with no or, at most, minor reworking<br />
* 2. Accept with rework verification<br />
* 3. Reinspect.<br />
<br />
====Walkthroughs====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a systematic walk-through is to evaluate a software product. A walkthrough may be conducted for the purpose of educating an audience regarding a software product.<br />
<br />
Walkthroughs are distinguished from inspections.<br />
The main difference is that the author presents<br />
the work-product to the other participants in<br />
a meeting (face to face or electronic). Unlike an<br />
inspection, the meeting participants may not have<br />
necessarily seen the material prior to the meeting.<br />
The meetings may be conducted less formally.<br />
The author takes the role of explaining and<br />
showing the material to participants and solicits<br />
feedback. Like inspections, walkthroughs may be<br />
conducted on any type of work-product including<br />
project plan, requirements, design, source code,<br />
and test reports.<br />
<br />
====Process Assurance and Product Assurance Audits====<br />
<br />
As stated in [16*],<br />
<br />
* The purpose of a software audit is to provide an independent evaluation of the conformance of software products and processes<br />
to applicable regulations, standards, guidelines, plans, and procedures.<br />
<br />
Process assurance audits determine the adequacy<br />
of plans, schedules, and requirements to achieve<br />
project objectives [5]. The audit is a formally<br />
organized activity with participants having specific<br />
roles—such as lead auditor, another auditor, a<br />
recorder, or an initiator—and including a representative<br />
of the audited organization. Audits identify<br />
instances of nonconformance and produce a report<br />
requiring the team to take corrective action.<br />
<br />
While there may be many formal names for<br />
reviews and audits, such as those identified in the<br />
standard [16*], the important point is that they<br />
can occur on almost any product at any stage of<br />
the development or maintenance process.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_10:_Software_Quality&diff=868Chapter 10: Software Quality2015-08-29T12:17:10Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}<br />
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}<br />
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}<br />
{{Acronym|name=FTA|description=Fault Tree Analysis}}<br />
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}<br />
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}<br />
{{Acronym|name=QFD|description=Quality Function Deployment}}<br />
{{Acronym|name=SPI|description=Software Process Improvement}}<br />
{{Acronym|name=SQA|description=Software Quality Assurance}}<br />
{{Acronym|name=SQC|description=Software Quality Control}}<br />
{{Acronym|name=SQM|description=Software Quality Management}}<br />
{{Acronym|name=TQM|description=Total Quality Management}}<br />
{{Acronym|name=V&V|description=Verification and Validation}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
What is software quality, and why is it so important<br />
that it is included in many knowledge areas<br />
(KAs) of the ''SWEBOK Guide''?<br />
<br />
One reason is that the term ''software quality'' is<br />
overloaded. Software quality may refer: to desirable<br />
characteristics of software products, to the<br />
extent to which a particular software product possess<br />
those characteristics, and to processes, tools,<br />
and techniques used to achieve those characteristics.<br />
Over the years, authors and organizations<br />
have defined the term quality differently. To Phil<br />
Crosby, it was “conformance to requirements”<br />
[1]. Watts Humphrey refers to it as “achieving<br />
excellent levels of “fitness for use” [2]. Meanwhile,<br />
IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter”<br />
[3*, p8].<br />
<br />
More recently, software quality is defined as the<br />
“capability of software product to satisfy stated<br />
and implied needs under specified conditions” [4]<br />
and as “the degree to which a software product<br />
meets established requirements; however, quality<br />
depends upon the degree to which those established<br />
requirements accurately represent stakeholder<br />
needs, wants, and expectations” [5]. Both<br />
definitions embrace the premise of conformance<br />
to requirements. Neither refers to types of requirements<br />
(e.g., functional, reliability, performance,<br />
dependability, or any other characteristic). Significantly,<br />
however, these definitions emphasize that<br />
quality is dependent upon requirements.<br />
<br />
These definitions also illustrate another reason<br />
for the prevalence of software quality throughout<br />
this ''Guide'': a frequent ambiguity of ''software quality'' versus ''software quality requirements''<br />
(“the -''ilities''” is a common shorthand). Software<br />
quality requirements are actually attributes of (or<br />
constraints on) functional requirements (what<br />
the system does). Software requirements may<br />
also specify resource usage, a communication<br />
protocol, or many other characteristics. This KA<br />
attempts clarity by using ''software quality'' in the<br />
broadest sense from the definitions above and<br />
by using ''software quality requirements'' as constraints<br />
on functional requirements. Software<br />
quality is achieved by conformance to all requirements<br />
regardless of what characteristic is specified<br />
or how requirements are grouped or named.<br />
<br />
Software quality is also considered in many of<br />
the SWEBOK KAs because it is a basic parameter<br />
of a software engineering effort. For all engineered<br />
products, the primary goal is delivering<br />
maximum stakeholder value, while balancing the<br />
constraints of development cost and schedule;<br />
this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements.<br />
For software products, stakeholders could<br />
value price (what they pay for the product), lead<br />
time (how fast they get the product), and software<br />
quality.<br />
<br />
This KA addresses definitions and provides an<br />
overview of practices, tools, and techniques for<br />
defining software quality and for appraising the<br />
state of software quality during development,<br />
maintenance, and deployment. Cited references<br />
provide additional details.}}<br />
[[File:Breakdown of Topics for the Software Quality.jpg|thumb|300px|frame|Figure 10.1: Breakdown of Topics for the Software Quality KA]]<br />
{{IntroSection|title=Breakdown of Topics for Software Quality|body=<br />
The breakdown of topics for the Software Quality KA is presented in Figure 10.1.}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=File:Breakdown_of_Topics_for_the_Software_Quality.jpg&diff=867File:Breakdown of Topics for the Software Quality.jpg2015-08-29T12:16:01Z<p>Daniel Robbins: </p>
<hr />
<div></div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_10:_Software_Quality&diff=866Chapter 10: Software Quality2015-08-29T12:08:34Z<p>Daniel Robbins: Created page with "{{TOC}} {{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}} {{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}} {{Acronym|name=COTS|..."</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=CoSQ|description=CoSQ Cost of Software Quality}}<br />
{{Acronym|name=COTS|description=Commercial Off-the-Shelf Software}}<br />
{{Acronym|name=FMEA|description=Failure Mode and Effects Analysis}}<br />
{{Acronym|name=FTA|description=Fault Tree Analysis}}<br />
{{Acronym|name=PDCA|description=Plan-Do-Check-Act}}<br />
{{Acronym|name=PDSA|description=Plan-Do-Study-Act}}<br />
{{Acronym|name=QFD|description=Quality Function Deployment}}<br />
{{Acronym|name=SPI|description=Software Process Improvement}}<br />
{{Acronym|name=SQA|description=Software Quality Assurance}}<br />
{{Acronym|name=SQC|description=Software Quality Control}}<br />
{{Acronym|name=SQM|description=Software Quality Management}}<br />
{{Acronym|name=TQM|description=Total Quality Management}}<br />
{{Acronym|name=V&V|description=Verification and Validation}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=865Chapter 11: Software Engineering Professional Practice2015-08-29T10:46:29Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.<br />
<br />
==Communication Skills==<br />
<br />
It is vital that a software engineer communicate<br />
well, both orally and in reading and writing. Successful<br />
attainment of software requirements and<br />
deadlines depends on developing clear understanding<br />
between the software engineer and<br />
customers, supervisors, coworkers, and suppliers.<br />
Optimal problem solving is made possible<br />
through the ability to investigate, comprehend,<br />
and summarize information. Customer product<br />
acceptance and safe product usage depend on the<br />
provision of relevant training and documentation.<br />
It follows that the software engineer’s own career<br />
success is affected by the ability to consistently<br />
provide oral and written communication effectively<br />
and on time.<br />
<br />
===Reading, Understanding, and Summarizing===<br />
{{RightSection|{{referenceLink|number=5|parts=c33}}}}<br />
<br />
Software engineers are able to read and understand<br />
technical material. Technical material<br />
includes reference books, manuals, research<br />
papers, and program source code.<br />
<br />
Reading is not only a primary way of improving<br />
skills, but also a way of gathering information<br />
necessary for the completion of engineering<br />
goals. A software engineer sifts through accumulated<br />
information, filtering out the pieces that<br />
will be most helpful. Customers may request that<br />
a software engineer summarize the results of<br />
such information gathering for them, simplifying<br />
or explaining it so that they may make the final<br />
choice between competing solutions.<br />
<br />
Reading and comprehending source code is<br />
also a component of information gathering and<br />
problem solving. When modifying, extending, or rewriting software, it is critical to understand<br />
both its implementation directly derived from the<br />
presented code and its design, which must often<br />
be inferred.<br />
<br />
===Writing===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s5}}}}<br />
<br />
Software engineers are able to produce written<br />
products as required by customer requests or generally<br />
accepted practice. These written products<br />
may include source code, software project plans,<br />
software requirement documents, risk analyses,<br />
software design documents, software test plans,<br />
user manuals, technical reports and evaluations,<br />
justifications, diagrams and charts, and so forth.<br />
<br />
Writing clearly and concisely is very important<br />
because often it is the primary method of communication<br />
among relevant parties. In all cases,<br />
written software engineering products must be<br />
written so that they are accessible, understandable<br />
and relevant for their intended audience(s).<br />
<br />
===Team and Group Communication===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s6.8}} {{referenceLink|number=4|parts=c22s3}} {{referenceLink|number=5|parts=c27s1}} {{referenceLink|number=9|parts=c10s4}}}}<br />
<br />
Effective communication among team and group<br />
members is essential to a collaborative software<br />
engineering effort. Stakeholders must be consulted,<br />
decisions must be made, and plans must<br />
be generated. The greater the number of team<br />
and group members, the greater the need to<br />
communicate.<br />
<br />
The number of communication paths, however,<br />
grows quadratically with the addition of<br />
each team member. Further, team members<br />
are unlikely to communicate with anyone perceived<br />
to be removed from them by more than<br />
two degrees (levels). This problem can be more<br />
serious when software engineering endeavors or<br />
organizations are spread across national and continental<br />
borders.<br />
<br />
Some communication can be accomplished in<br />
writing. Software documentation is a common<br />
substitute for direct interaction. Email is another<br />
but, although it is useful, it is not always enough;<br />
also, if one sends too many messages, it becomes<br />
difficult to identify the important information.<br />
Increasingly, organizations are using enterprise collaboration tools to share information. In addition,<br />
the use of electronic information stores,<br />
accessible to all team members, for organizational<br />
policies, standards, common engineering<br />
procedures, and project-specific information, can<br />
be most beneficial.<br />
<br />
Some software engineering teams focus on<br />
face-to-face interaction and promote such interaction<br />
by office space arrangement. Although<br />
private offices improve individual productivity,<br />
colocating team members in physical or virtual<br />
forms and providing communal work areas is<br />
important to collaborative efforts.<br />
<br />
===Presentation Skills===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=4|parts=c22}} {{referenceLink|number=9|parts=c10s7–c10s8}}}}<br />
<br />
Software engineers rely on their presentation<br />
skills during software life cycle processes. For<br />
example, during the software requirements phase, software engineers may walk customers<br />
and teammates through software requirements<br />
and conduct formal requirements reviews (see<br />
Requirement Reviews in the Software Requirements<br />
KA). During and after software design,<br />
software construction, and software maintenance,<br />
software engineers lead reviews, product walkthroughs<br />
(see Review and Audits in the Software<br />
Quality KA), and training. All of these require the<br />
ability to present technical information to groups<br />
and solicit ideas or feedback.<br />
<br />
The software engineer’s ability to convey<br />
concepts effectively in a presentation therefore<br />
influences product acceptance, management,<br />
and customer support; it also influences the ability<br />
of stakeholders to comprehend and assist in<br />
the product effort. This knowledge needs to be<br />
archived in the form of slides, knowledge writeup,<br />
technical whitepapers, and any other material<br />
utilized for knowledge creation.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
Gerald M. Weinberg, ''The Psychology of Computer Programming'' [10].<br />
<br />
This was the first major book to address programming<br />
as an individual and team effort and became<br />
a classic in the field.<br />
<br />
Kinney and Lange, P.A., ''Intellectual Property Law for Business Lawyers'' [11].<br />
<br />
This book covers IP laws in the US. It not only<br />
talks about what the IP law is; it also explains<br />
why it looks the way it does.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=F. Bott et al.<br />
|article=<br />
|publication=Professional Issues in Software Engineering<br />
|edition=3rd ed.<br />
|publisher=Taylor & Francis<br />
|issue=<br />
|date=2000<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=Merriam-Webster’s Collegiate Dictionary<br />
|article=<br />
|publication=<br />
|edition=11th ed<br />
|publisher=<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=G. Voland<br />
|article=<br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=4<br />
|author=I. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=IEEE CS/ACM Joint Task Force onSoftware Engineering Ethics and Professional Practices<br />
|article=Software Engineering Code of Ethics and Professional Practice (Version 5.2)<br />
|publication=<br />
|edition=<br />
|publisher=<br />
|issue=<br />
|date=1999<br />
|part=<br />
|link=www.acm.org/serving/se/code.htm<br />
}}{{reference<br />
|number=7<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=8<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=9<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=10<br />
|author=G.M. Weinberg<br />
|article=<br />
|publication=The Psychology of Computer Programming: Silver Anniversary Edition<br />
|edition=<br />
|publisher=Dorset House<br />
|issue=<br />
|date=1998<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=Kinney and Lange, P.A.<br />
|article=<br />
|publication=Intellectual Property Law for Business Lawyers<br />
|edition=<br />
|publisher=Thomson West<br />
|issue=<br />
|date=2013<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=864Chapter 11: Software Engineering Professional Practice2015-08-29T10:45:34Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronyms|{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.<br />
<br />
==Communication Skills==<br />
<br />
It is vital that a software engineer communicate<br />
well, both orally and in reading and writing. Successful<br />
attainment of software requirements and<br />
deadlines depends on developing clear understanding<br />
between the software engineer and<br />
customers, supervisors, coworkers, and suppliers.<br />
Optimal problem solving is made possible<br />
through the ability to investigate, comprehend,<br />
and summarize information. Customer product<br />
acceptance and safe product usage depend on the<br />
provision of relevant training and documentation.<br />
It follows that the software engineer’s own career<br />
success is affected by the ability to consistently<br />
provide oral and written communication effectively<br />
and on time.<br />
<br />
===Reading, Understanding, and Summarizing===<br />
{{RightSection|{{referenceLink|number=5|parts=c33}}}}<br />
<br />
Software engineers are able to read and understand<br />
technical material. Technical material<br />
includes reference books, manuals, research<br />
papers, and program source code.<br />
<br />
Reading is not only a primary way of improving<br />
skills, but also a way of gathering information<br />
necessary for the completion of engineering<br />
goals. A software engineer sifts through accumulated<br />
information, filtering out the pieces that<br />
will be most helpful. Customers may request that<br />
a software engineer summarize the results of<br />
such information gathering for them, simplifying<br />
or explaining it so that they may make the final<br />
choice between competing solutions.<br />
<br />
Reading and comprehending source code is<br />
also a component of information gathering and<br />
problem solving. When modifying, extending, or rewriting software, it is critical to understand<br />
both its implementation directly derived from the<br />
presented code and its design, which must often<br />
be inferred.<br />
<br />
===Writing===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s5}}}}<br />
<br />
Software engineers are able to produce written<br />
products as required by customer requests or generally<br />
accepted practice. These written products<br />
may include source code, software project plans,<br />
software requirement documents, risk analyses,<br />
software design documents, software test plans,<br />
user manuals, technical reports and evaluations,<br />
justifications, diagrams and charts, and so forth.<br />
<br />
Writing clearly and concisely is very important<br />
because often it is the primary method of communication<br />
among relevant parties. In all cases,<br />
written software engineering products must be<br />
written so that they are accessible, understandable<br />
and relevant for their intended audience(s).<br />
<br />
===Team and Group Communication===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s6.8}} {{referenceLink|number=4|parts=c22s3}} {{referenceLink|number=5|parts=c27s1}} {{referenceLink|number=9|parts=c10s4}}}}<br />
<br />
Effective communication among team and group<br />
members is essential to a collaborative software<br />
engineering effort. Stakeholders must be consulted,<br />
decisions must be made, and plans must<br />
be generated. The greater the number of team<br />
and group members, the greater the need to<br />
communicate.<br />
<br />
The number of communication paths, however,<br />
grows quadratically with the addition of<br />
each team member. Further, team members<br />
are unlikely to communicate with anyone perceived<br />
to be removed from them by more than<br />
two degrees (levels). This problem can be more<br />
serious when software engineering endeavors or<br />
organizations are spread across national and continental<br />
borders.<br />
<br />
Some communication can be accomplished in<br />
writing. Software documentation is a common<br />
substitute for direct interaction. Email is another<br />
but, although it is useful, it is not always enough;<br />
also, if one sends too many messages, it becomes<br />
difficult to identify the important information.<br />
Increasingly, organizations are using enterprise collaboration tools to share information. In addition,<br />
the use of electronic information stores,<br />
accessible to all team members, for organizational<br />
policies, standards, common engineering<br />
procedures, and project-specific information, can<br />
be most beneficial.<br />
<br />
Some software engineering teams focus on<br />
face-to-face interaction and promote such interaction<br />
by office space arrangement. Although<br />
private offices improve individual productivity,<br />
colocating team members in physical or virtual<br />
forms and providing communal work areas is<br />
important to collaborative efforts.<br />
<br />
===Presentation Skills===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=4|parts=c22}} {{referenceLink|number=9|parts=c10s7–c10s8}}}}<br />
<br />
Software engineers rely on their presentation<br />
skills during software life cycle processes. For<br />
example, during the software requirements phase, software engineers may walk customers<br />
and teammates through software requirements<br />
and conduct formal requirements reviews (see<br />
Requirement Reviews in the Software Requirements<br />
KA). During and after software design,<br />
software construction, and software maintenance,<br />
software engineers lead reviews, product walkthroughs<br />
(see Review and Audits in the Software<br />
Quality KA), and training. All of these require the<br />
ability to present technical information to groups<br />
and solicit ideas or feedback.<br />
<br />
The software engineer’s ability to convey<br />
concepts effectively in a presentation therefore<br />
influences product acceptance, management,<br />
and customer support; it also influences the ability<br />
of stakeholders to comprehend and assist in<br />
the product effort. This knowledge needs to be<br />
archived in the form of slides, knowledge writeup,<br />
technical whitepapers, and any other material<br />
utilized for knowledge creation.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
Gerald M. Weinberg, ''The Psychology of Computer Programming'' [10].<br />
<br />
This was the first major book to address programming<br />
as an individual and team effort and became<br />
a classic in the field.<br />
<br />
Kinney and Lange, P.A., ''Intellectual Property Law for Business Lawyers'' [11].<br />
<br />
This book covers IP laws in the US. It not only<br />
talks about what the IP law is; it also explains<br />
why it looks the way it does.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=F. Bott et al.<br />
|article=<br />
|publication=Professional Issues in Software Engineering<br />
|edition=3rd ed.<br />
|publisher=Taylor & Francis<br />
|issue=<br />
|date=2000<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=Merriam-Webster’s Collegiate Dictionary<br />
|article=<br />
|publication=<br />
|edition=11th ed<br />
|publisher=<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=G. Voland<br />
|article=<br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=4<br />
|author=I. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=IEEE CS/ACM Joint Task Force onSoftware Engineering Ethics and Professional Practices<br />
|article=Software Engineering Code of Ethics and Professional Practice (Version 5.2)<br />
|publication=<br />
|edition=<br />
|publisher=<br />
|issue=<br />
|date=1999<br />
|part=<br />
|link=www.acm.org/serving/se/code.htm<br />
}}{{reference<br />
|number=7<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=8<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=9<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=10<br />
|author=G.M. Weinberg<br />
|article=<br />
|publication=The Psychology of Computer Programming: Silver Anniversary Edition<br />
|edition=<br />
|publisher=Dorset House<br />
|issue=<br />
|date=1998<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=Kinney and Lange, P.A.<br />
|article=<br />
|publication=Intellectual Property Law for Business Lawyers<br />
|edition=<br />
|publisher=Thomson West<br />
|issue=<br />
|date=2013<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=863Chapter 11: Software Engineering Professional Practice2015-08-29T10:44:21Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.<br />
<br />
==Communication Skills==<br />
<br />
It is vital that a software engineer communicate<br />
well, both orally and in reading and writing. Successful<br />
attainment of software requirements and<br />
deadlines depends on developing clear understanding<br />
between the software engineer and<br />
customers, supervisors, coworkers, and suppliers.<br />
Optimal problem solving is made possible<br />
through the ability to investigate, comprehend,<br />
and summarize information. Customer product<br />
acceptance and safe product usage depend on the<br />
provision of relevant training and documentation.<br />
It follows that the software engineer’s own career<br />
success is affected by the ability to consistently<br />
provide oral and written communication effectively<br />
and on time.<br />
<br />
===Reading, Understanding, and Summarizing===<br />
{{RightSection|{{referenceLink|number=5|parts=c33}}}}<br />
<br />
Software engineers are able to read and understand<br />
technical material. Technical material<br />
includes reference books, manuals, research<br />
papers, and program source code.<br />
<br />
Reading is not only a primary way of improving<br />
skills, but also a way of gathering information<br />
necessary for the completion of engineering<br />
goals. A software engineer sifts through accumulated<br />
information, filtering out the pieces that<br />
will be most helpful. Customers may request that<br />
a software engineer summarize the results of<br />
such information gathering for them, simplifying<br />
or explaining it so that they may make the final<br />
choice between competing solutions.<br />
<br />
Reading and comprehending source code is<br />
also a component of information gathering and<br />
problem solving. When modifying, extending, or rewriting software, it is critical to understand<br />
both its implementation directly derived from the<br />
presented code and its design, which must often<br />
be inferred.<br />
<br />
===Writing===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s5}}}}<br />
<br />
Software engineers are able to produce written<br />
products as required by customer requests or generally<br />
accepted practice. These written products<br />
may include source code, software project plans,<br />
software requirement documents, risk analyses,<br />
software design documents, software test plans,<br />
user manuals, technical reports and evaluations,<br />
justifications, diagrams and charts, and so forth.<br />
<br />
Writing clearly and concisely is very important<br />
because often it is the primary method of communication<br />
among relevant parties. In all cases,<br />
written software engineering products must be<br />
written so that they are accessible, understandable<br />
and relevant for their intended audience(s).<br />
<br />
===Team and Group Communication===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s6.8}} {{referenceLink|number=4|parts=c22s3}} {{referenceLink|number=5|parts=c27s1}} {{referenceLink|number=9|parts=c10s4}}}}<br />
<br />
Effective communication among team and group<br />
members is essential to a collaborative software<br />
engineering effort. Stakeholders must be consulted,<br />
decisions must be made, and plans must<br />
be generated. The greater the number of team<br />
and group members, the greater the need to<br />
communicate.<br />
<br />
The number of communication paths, however,<br />
grows quadratically with the addition of<br />
each team member. Further, team members<br />
are unlikely to communicate with anyone perceived<br />
to be removed from them by more than<br />
two degrees (levels). This problem can be more<br />
serious when software engineering endeavors or<br />
organizations are spread across national and continental<br />
borders.<br />
<br />
Some communication can be accomplished in<br />
writing. Software documentation is a common<br />
substitute for direct interaction. Email is another<br />
but, although it is useful, it is not always enough;<br />
also, if one sends too many messages, it becomes<br />
difficult to identify the important information.<br />
Increasingly, organizations are using enterprise collaboration tools to share information. In addition,<br />
the use of electronic information stores,<br />
accessible to all team members, for organizational<br />
policies, standards, common engineering<br />
procedures, and project-specific information, can<br />
be most beneficial.<br />
<br />
Some software engineering teams focus on<br />
face-to-face interaction and promote such interaction<br />
by office space arrangement. Although<br />
private offices improve individual productivity,<br />
colocating team members in physical or virtual<br />
forms and providing communal work areas is<br />
important to collaborative efforts.<br />
<br />
===Presentation Skills===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=4|parts=c22}} {{referenceLink|number=9|parts=c10s7–c10s8}}}}<br />
<br />
Software engineers rely on their presentation<br />
skills during software life cycle processes. For<br />
example, during the software requirements phase, software engineers may walk customers<br />
and teammates through software requirements<br />
and conduct formal requirements reviews (see<br />
Requirement Reviews in the Software Requirements<br />
KA). During and after software design,<br />
software construction, and software maintenance,<br />
software engineers lead reviews, product walkthroughs<br />
(see Review and Audits in the Software<br />
Quality KA), and training. All of these require the<br />
ability to present technical information to groups<br />
and solicit ideas or feedback.<br />
<br />
The software engineer’s ability to convey<br />
concepts effectively in a presentation therefore<br />
influences product acceptance, management,<br />
and customer support; it also influences the ability<br />
of stakeholders to comprehend and assist in<br />
the product effort. This knowledge needs to be<br />
archived in the form of slides, knowledge writeup,<br />
technical whitepapers, and any other material<br />
utilized for knowledge creation.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
Gerald M. Weinberg, ''The Psychology of Computer Programming'' [10].<br />
<br />
This was the first major book to address programming<br />
as an individual and team effort and became<br />
a classic in the field.<br />
<br />
Kinney and Lange, P.A., ''Intellectual Property Law for Business Lawyers'' [11].<br />
<br />
This book covers IP laws in the US. It not only<br />
talks about what the IP law is; it also explains<br />
why it looks the way it does.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=F. Bott et al.<br />
|article=<br />
|publication=Professional Issues in Software Engineering<br />
|edition=3rd ed.<br />
|publisher=Taylor & Francis<br />
|issue=<br />
|date=2000<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=Merriam-Webster’s Collegiate Dictionary<br />
|article=<br />
|publication=<br />
|edition=11th ed<br />
|publisher=<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=G. Voland<br />
|article=<br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=4<br />
|author=I. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=IEEE CS/ACM Joint Task Force onSoftware Engineering Ethics and Professional Practices<br />
|article=Software Engineering Code of Ethics and Professional Practice (Version 5.2)<br />
|publication=<br />
|edition=<br />
|publisher=<br />
|issue=<br />
|date=1999<br />
|part=<br />
|link=www.acm.org/serving/se/code.htm<br />
}}{{reference<br />
|number=7<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=8<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=9<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=10<br />
|author=G.M. Weinberg<br />
|article=<br />
|publication=The Psychology of Computer Programming: Silver Anniversary Edition<br />
|edition=<br />
|publisher=Dorset House<br />
|issue=<br />
|date=1998<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=Kinney and Lange, P.A.<br />
|article=<br />
|publication=Intellectual Property Law for Business Lawyers<br />
|edition=<br />
|publisher=Thomson West<br />
|issue=<br />
|date=2013<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=862Chapter 11: Software Engineering Professional Practice2015-08-29T10:23:49Z<p>Daniel Robbins: /* Presentation Skills */</p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.<br />
<br />
==Communication Skills==<br />
<br />
It is vital that a software engineer communicate<br />
well, both orally and in reading and writing. Successful<br />
attainment of software requirements and<br />
deadlines depends on developing clear understanding<br />
between the software engineer and<br />
customers, supervisors, coworkers, and suppliers.<br />
Optimal problem solving is made possible<br />
through the ability to investigate, comprehend,<br />
and summarize information. Customer product<br />
acceptance and safe product usage depend on the<br />
provision of relevant training and documentation.<br />
It follows that the software engineer’s own career<br />
success is affected by the ability to consistently<br />
provide oral and written communication effectively<br />
and on time.<br />
<br />
===Reading, Understanding, and Summarizing===<br />
{{RightSection|{{referenceLink|number=5|parts=c33}}}}<br />
<br />
Software engineers are able to read and understand<br />
technical material. Technical material<br />
includes reference books, manuals, research<br />
papers, and program source code.<br />
<br />
Reading is not only a primary way of improving<br />
skills, but also a way of gathering information<br />
necessary for the completion of engineering<br />
goals. A software engineer sifts through accumulated<br />
information, filtering out the pieces that<br />
will be most helpful. Customers may request that<br />
a software engineer summarize the results of<br />
such information gathering for them, simplifying<br />
or explaining it so that they may make the final<br />
choice between competing solutions.<br />
<br />
Reading and comprehending source code is<br />
also a component of information gathering and<br />
problem solving. When modifying, extending, or rewriting software, it is critical to understand<br />
both its implementation directly derived from the<br />
presented code and its design, which must often<br />
be inferred.<br />
<br />
===Writing===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s5}}}}<br />
<br />
Software engineers are able to produce written<br />
products as required by customer requests or generally<br />
accepted practice. These written products<br />
may include source code, software project plans,<br />
software requirement documents, risk analyses,<br />
software design documents, software test plans,<br />
user manuals, technical reports and evaluations,<br />
justifications, diagrams and charts, and so forth.<br />
<br />
Writing clearly and concisely is very important<br />
because often it is the primary method of communication<br />
among relevant parties. In all cases,<br />
written software engineering products must be<br />
written so that they are accessible, understandable<br />
and relevant for their intended audience(s).<br />
<br />
===Team and Group Communication===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s6.8}} {{referenceLink|number=4|parts=c22s3}} {{referenceLink|number=5|parts=c27s1}} {{referenceLink|number=9|parts=c10s4}}}}<br />
<br />
Effective communication among team and group<br />
members is essential to a collaborative software<br />
engineering effort. Stakeholders must be consulted,<br />
decisions must be made, and plans must<br />
be generated. The greater the number of team<br />
and group members, the greater the need to<br />
communicate.<br />
<br />
The number of communication paths, however,<br />
grows quadratically with the addition of<br />
each team member. Further, team members<br />
are unlikely to communicate with anyone perceived<br />
to be removed from them by more than<br />
two degrees (levels). This problem can be more<br />
serious when software engineering endeavors or<br />
organizations are spread across national and continental<br />
borders.<br />
<br />
Some communication can be accomplished in<br />
writing. Software documentation is a common<br />
substitute for direct interaction. Email is another<br />
but, although it is useful, it is not always enough;<br />
also, if one sends too many messages, it becomes<br />
difficult to identify the important information.<br />
Increasingly, organizations are using enterprise collaboration tools to share information. In addition,<br />
the use of electronic information stores,<br />
accessible to all team members, for organizational<br />
policies, standards, common engineering<br />
procedures, and project-specific information, can<br />
be most beneficial.<br />
<br />
Some software engineering teams focus on<br />
face-to-face interaction and promote such interaction<br />
by office space arrangement. Although<br />
private offices improve individual productivity,<br />
colocating team members in physical or virtual<br />
forms and providing communal work areas is<br />
important to collaborative efforts.<br />
<br />
===Presentation Skills===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=4|parts=c22}} {{referenceLink|number=9|parts=c10s7–c10s8}}}}<br />
<br />
Software engineers rely on their presentation<br />
skills during software life cycle processes. For<br />
example, during the software requirements phase, software engineers may walk customers<br />
and teammates through software requirements<br />
and conduct formal requirements reviews (see<br />
Requirement Reviews in the Software Requirements<br />
KA). During and after software design,<br />
software construction, and software maintenance,<br />
software engineers lead reviews, product walkthroughs<br />
(see Review and Audits in the Software<br />
Quality KA), and training. All of these require the<br />
ability to present technical information to groups<br />
and solicit ideas or feedback.<br />
<br />
The software engineer’s ability to convey<br />
concepts effectively in a presentation therefore<br />
influences product acceptance, management,<br />
and customer support; it also influences the ability<br />
of stakeholders to comprehend and assist in<br />
the product effort. This knowledge needs to be<br />
archived in the form of slides, knowledge writeup,<br />
technical whitepapers, and any other material<br />
utilized for knowledge creation.<br />
<br />
{{EndSection|title=Further Readings|body=<br />
<br />
Gerald M. Weinberg, ''The Psychology of Computer Programming'' [10].<br />
<br />
This was the first major book to address programming<br />
as an individual and team effort and became<br />
a classic in the field.<br />
<br />
Kinney and Lange, P.A., ''Intellectual Property Law for Business Lawyers'' [11].<br />
<br />
This book covers IP laws in the US. It not only<br />
talks about what the IP law is; it also explains<br />
why it looks the way it does.}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=861Chapter 11: Software Engineering Professional Practice2015-08-29T10:20:40Z<p>Daniel Robbins: /* Dealing with Multicultural Environments */</p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.<br />
<br />
==Communication Skills==<br />
<br />
It is vital that a software engineer communicate<br />
well, both orally and in reading and writing. Successful<br />
attainment of software requirements and<br />
deadlines depends on developing clear understanding<br />
between the software engineer and<br />
customers, supervisors, coworkers, and suppliers.<br />
Optimal problem solving is made possible<br />
through the ability to investigate, comprehend,<br />
and summarize information. Customer product<br />
acceptance and safe product usage depend on the<br />
provision of relevant training and documentation.<br />
It follows that the software engineer’s own career<br />
success is affected by the ability to consistently<br />
provide oral and written communication effectively<br />
and on time.<br />
<br />
===Reading, Understanding, and Summarizing===<br />
{{RightSection|{{referenceLink|number=5|parts=c33}}}}<br />
<br />
Software engineers are able to read and understand<br />
technical material. Technical material<br />
includes reference books, manuals, research<br />
papers, and program source code.<br />
<br />
Reading is not only a primary way of improving<br />
skills, but also a way of gathering information<br />
necessary for the completion of engineering<br />
goals. A software engineer sifts through accumulated<br />
information, filtering out the pieces that<br />
will be most helpful. Customers may request that<br />
a software engineer summarize the results of<br />
such information gathering for them, simplifying<br />
or explaining it so that they may make the final<br />
choice between competing solutions.<br />
<br />
Reading and comprehending source code is<br />
also a component of information gathering and<br />
problem solving. When modifying, extending, or rewriting software, it is critical to understand<br />
both its implementation directly derived from the<br />
presented code and its design, which must often<br />
be inferred.<br />
<br />
===Writing===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s5}}}}<br />
<br />
Software engineers are able to produce written<br />
products as required by customer requests or generally<br />
accepted practice. These written products<br />
may include source code, software project plans,<br />
software requirement documents, risk analyses,<br />
software design documents, software test plans,<br />
user manuals, technical reports and evaluations,<br />
justifications, diagrams and charts, and so forth.<br />
<br />
Writing clearly and concisely is very important<br />
because often it is the primary method of communication<br />
among relevant parties. In all cases,<br />
written software engineering products must be<br />
written so that they are accessible, understandable<br />
and relevant for their intended audience(s).<br />
<br />
===Team and Group Communication===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s6.8}} {{referenceLink|number=4|parts=c22s3}} {{referenceLink|number=5|parts=c27s1}} {{referenceLink|number=9|parts=c10s4}}}}<br />
<br />
Effective communication among team and group<br />
members is essential to a collaborative software<br />
engineering effort. Stakeholders must be consulted,<br />
decisions must be made, and plans must<br />
be generated. The greater the number of team<br />
and group members, the greater the need to<br />
communicate.<br />
<br />
The number of communication paths, however,<br />
grows quadratically with the addition of<br />
each team member. Further, team members<br />
are unlikely to communicate with anyone perceived<br />
to be removed from them by more than<br />
two degrees (levels). This problem can be more<br />
serious when software engineering endeavors or<br />
organizations are spread across national and continental<br />
borders.<br />
<br />
Some communication can be accomplished in<br />
writing. Software documentation is a common<br />
substitute for direct interaction. Email is another<br />
but, although it is useful, it is not always enough;<br />
also, if one sends too many messages, it becomes<br />
difficult to identify the important information.<br />
Increasingly, organizations are using enterprise collaboration tools to share information. In addition,<br />
the use of electronic information stores,<br />
accessible to all team members, for organizational<br />
policies, standards, common engineering<br />
procedures, and project-specific information, can<br />
be most beneficial.<br />
<br />
Some software engineering teams focus on<br />
face-to-face interaction and promote such interaction<br />
by office space arrangement. Although<br />
private offices improve individual productivity,<br />
colocating team members in physical or virtual<br />
forms and providing communal work areas is<br />
important to collaborative efforts.<br />
<br />
===Presentation Skills===<br />
{{RightSection| {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=4|parts=c22}} {{referenceLink|number=9|parts=c10s7–c10s8}}}}<br />
<br />
Software engineers rely on their presentation<br />
skills during software life cycle processes. For<br />
example, during the software requirements phase, software engineers may walk customers<br />
and teammates through software requirements<br />
and conduct formal requirements reviews (see<br />
Requirement Reviews in the Software Requirements<br />
KA). During and after software design,<br />
software construction, and software maintenance,<br />
software engineers lead reviews, product walkthroughs<br />
(see Review and Audits in the Software<br />
Quality KA), and training. All of these require the<br />
ability to present technical information to groups<br />
and solicit ideas or feedback.<br />
<br />
The software engineer’s ability to convey<br />
concepts effectively in a presentation therefore<br />
influences product acceptance, management,<br />
and customer support; it also influences the ability<br />
of stakeholders to comprehend and assist in<br />
the product effort. This knowledge needs to be<br />
archived in the form of slides, knowledge writeup,<br />
technical whitepapers, and any other material<br />
utilized for knowledge creation.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=860Chapter 11: Software Engineering Professional Practice2015-08-29T10:05:19Z<p>Daniel Robbins: /* Individual Cognition */</p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
===Dealing with Problem Complexity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Many, if not most, software engineering problems<br />
are too complex and difficult to address as<br />
a whole or to be tackled by individual software<br />
engineers. When such circumstances arise, the<br />
usual means to adopt is teamwork and problem<br />
decomposition (see Problem Solving Techniques<br />
in the Computing Foundations KA).<br />
<br />
Teams work together to deal with complex and<br />
large problems by sharing burdens and drawing<br />
upon each other’s knowledge and creativity.<br />
When software engineers work in teams, different<br />
views and abilities of the individual engineers<br />
complement each other and help build a solution<br />
that is otherwise difficult to come by. Some specific<br />
teamwork examples to software engineering<br />
are pair programming (see Agile Methods in the<br />
Software Engineering Models and Methods KA)<br />
and code review (see Reviews and Audits in the<br />
Software Quality KA).<br />
<br />
===Interacting with Stakeholders===<br />
{{RightSection|{{referenceLink|number=9|parts=c2s3.1}}}}<br />
<br />
Success of a software engineering endeavor<br />
depends upon positive interactions with stakeholders.<br />
They should provide support, information,<br />
and feedback at all stages of the software<br />
life cycle process. For example, during the early<br />
stages, it is critical to identify all stakeholders and<br />
discover how the product will affect them, so that<br />
sufficient definition of the stakeholder requirements<br />
can be properly and completely captured.<br />
<br />
During development, stakeholders may provide<br />
feedback on specifications and/or early<br />
versions of the software, change of priority, as<br />
well as clarification of detailed or new software<br />
requirements. Last, during software maintenance<br />
and until the end of product life, stakeholders provide<br />
feedback on evolving or new requirements<br />
as well problem reports so that the software may<br />
be extended and improved.<br />
<br />
Therefore, it is vital to maintain open and productive<br />
communication with stakeholders for the<br />
duration of the software product’s lifetime.<br />
<br />
===Dealing with Uncertainty and Ambiguity===<br />
{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
As with engineers of other fields, software engineers<br />
must often deal with and resolve uncertainty<br />
and ambiguities while providing services<br />
and developing products. The software engineer<br />
must attack and reduce or eliminate any lack of<br />
clarity that is an obstacle to performing work.<br />
Often, uncertainty is simply a reflection of lack<br />
of knowledge. In this case, investigation through<br />
recourse to formal sources such as textbooks and<br />
professional journals, interviews with stakeholders,<br />
or consultation with teammates and peers can<br />
overcome it.<br />
<br />
When uncertainty or ambiguity cannot be overcome<br />
easily, software engineers or organizations<br />
may choose to regard it as a project risk. In this<br />
case, work estimates or pricing are adjusted to<br />
mitigate the anticipated cost of addressing it (see<br />
Risk Management in the Software Engineering<br />
Management KA).<br />
<br />
===Dealing with Multicultural Environments===<br />
{{RightSection|{{referenceLink|number=9|parts=c10s7}}}}<br />
<br />
Multicultural environments can have an impact<br />
on the dynamics of a group. This is especially<br />
true when the group is geographically separated<br />
or communication is infrequent, since such separation<br />
elevates the importance of each contact.<br />
Intercultural communication is even more difficult<br />
if the difference in time zones make oral<br />
communication less frequent.<br />
<br />
Multicultural environments are quite prevalent<br />
in software engineering, perhaps more than in<br />
other fields of engineering, due to the strong trend<br />
of international outsourcing and the easy shipment<br />
of software components instantaneously across<br />
the globe. For example, it is rather common for a<br />
software project to be divided into pieces across<br />
national and cultural borders, and it is also quite<br />
common for a software project team to consist of<br />
people from diverse cultural backgrounds.<br />
<br />
For a software project to be a success, team<br />
members must achieve a level of tolerance, acknowledging that some rules depend on societal<br />
norms and that not all societies derive the<br />
same solutions and expectations.<br />
<br />
This tolerance and accompanying understanding<br />
can be facilitated by the support of leadership<br />
and management. More frequent communication,<br />
including face-to-face meetings, can help to mitigate<br />
geographical and cultural divisions, promote<br />
cohesiveness, and raise productivity. Also, being<br />
able to communicate with teammates in their<br />
native language could be very beneficial.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=859Chapter 11: Software Engineering Professional Practice2015-08-29T09:03:05Z<p>Daniel Robbins: /* Group Dynamics and Psychology */</p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.<br />
<br />
===Dynamics of Working in Teams/Groups===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6}} {{referenceLink|number=9|parts=c1s3.5, c10}}}}<br />
<br />
Software engineers must work with others. On<br />
one hand, they work internally in engineering<br />
teams; on the other hand, they work with customers,<br />
members of the public, regulators, and<br />
other stakeholders. Performing teams—those<br />
that demonstrate consistent quality of work and<br />
progress toward goals—are cohesive and possess<br />
a cooperative, honest, and focused atmosphere.<br />
Individual and team goals are aligned so that the<br />
members naturally commit to and feel ownership<br />
of shared outcomes.<br />
<br />
Team members facilitate this atmosphere by<br />
being intellectually honest, making use of group<br />
thinking, admitting ignorance, and acknowledging<br />
mistakes. They share responsibility, rewards,<br />
and workload fairly. They take care to communicate<br />
clearly, directly to each other and in documents,<br />
as well as in source code, so that information<br />
is accessible to everyone. Peer reviews about<br />
work products are framed in a constructive and<br />
nonpersonal way (see Reviews and Audits in the<br />
Software Quality KA). This allows all the members<br />
to pursue a cycle of continuous improvement<br />
and growth without personal risk. In general,<br />
members of cohesive teams demonstrate respect<br />
for each other and their leader.<br />
<br />
One point to emphasize is that software engineers<br />
must be able to work in multidisciplinary<br />
environments and in varied application domains.<br />
Since today software is everywhere, from a phone<br />
to a car, software is impacting people’s lives far<br />
beyond the more traditional concept of software<br />
made for information management in a business<br />
environment.<br />
<br />
===Individual Cognition===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s6.5}} {{referenceLink|number=5|parts=c33}}}}<br />
<br />
Engineers desire to solve problems. The ability to<br />
solve problems effectively and efficiently is what<br />
every engineer strives for. However, the limits<br />
and processes of individual cognition affect problem<br />
solving. In software engineering, notably due<br />
to the highly abstract nature of software itself,<br />
individual cognition plays a very prominent role<br />
in problem solving.<br />
<br />
In general, an individual’s (in particular, a software<br />
engineer’s) ability to decompose a problem and creatively<br />
develop a solution can be inhibited by<br />
<br />
* need for more knowledge,<br />
* subconscious assumptions,<br />
* volume of data,<br />
* fear of failure or consequence of failure,<br />
* culture, either application domain or organizational,<br />
* lack of ability to express the problem,<br />
* perceived working atmosphere, and<br />
* emotional status of the individual.<br />
<br />
The impact of these inhibiting factors can be<br />
reduced by cultivating good problem solving<br />
habits that minimize the impact of misleading<br />
assumptions. The ability to focus is vital, as is<br />
intellectual humility: both allow a software engineer<br />
to suspend personal considerations and consult<br />
with others freely, which is especially important<br />
when working in teams.<br />
<br />
There is a set of basic methods engineers use<br />
to facilitate problem solving (see Problem Solving<br />
Techniques in the Computing Foundations<br />
KA). Breaking down problems and solving them<br />
one piece at a time reduces cognitive overload.<br />
Taking advantage of professional curiosity and<br />
pursuing continuous professional development through training and study add skills and knowledge<br />
to the software engineer’s portfolio; reading,<br />
networking, and experimenting with new tools,<br />
techniques, and methods are all valid means of<br />
professional development.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=858Chapter 11: Software Engineering Professional Practice2015-08-29T08:54:10Z<p>Daniel Robbins: /* Codes of Ethics and Professional Conduct */</p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.<br />
<br />
===Nature and Role of Professional Societies===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s1–c1s2}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c35s1}}}}<br />
<br />
Professional societies are comprised of a mix<br />
of practitioners and academics. These societies<br />
serve to define, advance, and regulate their corresponding<br />
professions. Professional societies<br />
help to establish professional standards as well<br />
as codes of ethics and professional conduct. For<br />
this reason, they also engage in related activities, which include<br />
<br />
* establishing and promulgating a body of generally accepted knowledge;<br />
* accrediting, certifying, and licensing;<br />
* dispensing disciplinary actions;<br />
* advancing the profession through conferences, training, and publications.<br />
<br />
Participation in professional societies assists<br />
the individual engineer in maintaining and sharpening<br />
their professional knowledge and relevancy<br />
and in expanding and maintaining their professional<br />
network.<br />
<br />
===Nature and Role of Software Engineering Standards===<br />
{{RightSection|{{referenceLink|number=1|parts=c5s3.2, c10s2.1}} {{referenceLink|number=5|parts=c32s6}} {{referenceLink|number=7|parts=c1s2}}}}<br />
<br />
Software engineering standards cover a remarkable<br />
variety of topics. They provide guidelines for<br />
the practice of software engineering and processes<br />
to be used during development, maintenance, and<br />
support of software. By establishing a consensual<br />
body of knowledge and experience, software engineering<br />
standards establish a basis upon which further<br />
guidelines may be developed. Appendix B of<br />
this 'Guide'' provides guidance on IEEE and ISO/<br />
IEC software engineering standards that support<br />
the knowledge areas of this ''Guide''.<br />
<br />
The benefits of software engineering standards<br />
are many and include improving software quality,helping avoid errors, protecting both software<br />
producers and users, increasing professional discipline,<br />
and helping technology transition.<br />
<br />
===Economic Impact of Software===<br />
{{RightSection|{{referenceLink|number=3|parts=c10s8}} {{referenceLink|number=4|parts=c1s1.1}} {{referenceLink|number=8|parts=c1}}}}<br />
<br />
Software has economic effects at the individual,<br />
business, and societal levels. Software “success”<br />
may be determined by the suitability of a product<br />
for a recognized problem as well as by its effectiveness<br />
when applied to that problem.<br />
<br />
At the individual level, an engineer’s continuing<br />
employment may depend on their ability<br />
and willingness to interpret and execute tasks<br />
in meeting customers’ or employers’ needs and<br />
expectations. The customer or employer’s financial<br />
situation may in turn be positively or negatively<br />
affected by the purchase of software.<br />
<br />
At the business level, software properly applied<br />
to a problem can eliminate months of work<br />
and translate to elevated profits or more effective<br />
organizations. Moreover, organizations that<br />
acquire or provide successful software may be a<br />
boon to the society in which they operate by providing<br />
both employment and improved services.<br />
However, the development or acquisition costs of<br />
software can also equate to those of any major<br />
acquisition.<br />
<br />
At the societal level, direct impacts of software<br />
success or failure include or exclude accidents,<br />
interruptions, and loss of service. Indirect impacts<br />
include the success or failure of the organization<br />
that acquired or produced the software, increased<br />
or decreased societal productivity, harmonious<br />
or disruptive social order, and even the saving or<br />
loss of property and life.<br />
<br />
===Employment Contracts===<br />
{{RightSection|{{referenceLink|number=1|parts=c7}}}}<br />
<br />
Software engineering services may be provided<br />
under a variety of client-engineer relationships.<br />
The software engineering work may be solicited<br />
as company-to-customer supplier, engineerto-<br />
customer consultancy, direct hire, or even<br />
volunteering. In all of these situations, the customer<br />
and supplier agree that a product or service<br />
will be provided in return for some sort of consideration. Here, we are most concerned with<br />
the engineer-to-customer arrangement and its<br />
attendant agreements or contracts, whether they<br />
are of the direct-hire or consultant variety, and<br />
the issues they typically address. <br />
<br />
A common concern in software engineering<br />
contracts is confidentiality. Employers derive<br />
commercial advantage from intellectual property,<br />
so they strive to protect that property from disclosure.<br />
Therefore, software engineers are often<br />
required to sign non-disclosure (NDA) or intellectual<br />
property (IP) agreements as a precondition<br />
to work. These agreements typically apply<br />
to information the software engineer could only<br />
gain through association with the customer. The<br />
terms of these agreements may extend past termination<br />
of the association.<br />
<br />
Another concern is IP ownership. Rights to<br />
software engineering assets—products, innovations,<br />
inventions, discoveries, and ideas—may<br />
reside with the employer or customer, either under<br />
explicit contract terms or relevant laws, if those<br />
assets are obtained during the term of the software<br />
engineer’s relationship with that employer<br />
or customer. Contracts differ in the ownership of<br />
assets created using non-employer-owned equipment<br />
or information.<br />
<br />
Finally, contracts can also specify among<br />
other elements the location at which work is to<br />
be performed; standards to which that work will<br />
be held; the system configuration to be used for<br />
development; limitations of the software engineer’s<br />
and employer’s liability; a communication<br />
matrix and/or escalation plan; and administrative<br />
details such as rates, frequency of compensation,<br />
working hours, and working conditions.<br />
<br />
===Legal Issues===<br />
{{RightSection|{{referenceLink|number=1|parts=c6, c11}} {{referenceLink|number=3|parts=c5s3–c5s4}} {{referenceLink|number=9|parts=c1s10}}}}<br />
<br />
Legal issues surrounding software engineering<br />
professional practice notably include matters<br />
related to standards, trademarks, patents, copyrights,<br />
trade secrets, professional liability, legal<br />
requirements, trade compliance, and cybercrime.<br />
It is therefore beneficial to possess knowledge of<br />
these issues and their applicability.<br />
<br />
Legal issues are jurisdictionally based; software<br />
engineers must consult attorneys who specialize in the type and jurisdiction of any identified<br />
legal issues.<br />
<br />
====Standards====<br />
<br />
Software engineering standards establish guidelines<br />
for generally accepted practices and minimum<br />
requirements for products and services provided<br />
by a software engineer. Appendix B of this<br />
''Guide'' provides guidance on software engineering<br />
standards that are applicable to each KA.<br />
<br />
Standards are valuable sources of requirements<br />
and assistance during the everyday conduct of<br />
software engineering activities. Adherence to<br />
standards facilitates discipline by enumerating<br />
minimal characteristics of products and practice.<br />
That discipline helps to mitigate subconscious<br />
assumptions or overconfidence in a design. For<br />
these reasons, organizations performing software<br />
engineering activities often include conformance<br />
to standards as part of their organizational policies.<br />
Further, adherence to standards is a major<br />
component of defense from legal action or from<br />
allegations of malpractice.<br />
<br />
====Trademarks====<br />
<br />
A trademark relates to any word, name, symbol,<br />
or device that is used in business transactions.<br />
It is used “to indicate the source or origin of the<br />
goods” [2].<br />
<br />
Trademark protection protects names, logos,<br />
images, and packaging. However, if a name, image,<br />
or other trademarked asset becomes a generic term,<br />
then trademark protection is nullified.<br />
<br />
The World Intellectual Property Organization<br />
(WIPO) is the authority that frames the rules and<br />
regulations on trademarks. WIPO is the United<br />
Nations agency dedicated to the use of intellectual<br />
property as a means of stimulating innovation<br />
and creativity.<br />
<br />
====Patents====<br />
<br />
Patents protect an inventor’s right to manufacture<br />
and sell an idea. A patent consists of a set<br />
of exclusive rights granted by a sovereign government<br />
to an individual, group of individuals, or<br />
organization for a limited period of time. Patents are an old form of idea-ownership protection and<br />
date back to the 15th century. <br />
<br />
Application for a patent entails careful records<br />
of the process that led to the invention. Patent<br />
attorneys are helpful in writing patent disclosure<br />
claims in a manner most likely to protect the software<br />
engineer’s rights.<br />
<br />
Note that, if inventions are made during the<br />
course of a software engineering contract, ownership<br />
may belong to the employer or customer or<br />
be jointly held, rather than belong to the software<br />
engineer.<br />
<br />
There are rules concerning what is and is not<br />
patentable. In many countries, software code is<br />
not patentable, although software algorithms may<br />
be. Existing and filed patent applications can be<br />
searched at WIPO.<br />
<br />
====Copyrights====<br />
<br />
Most governments in the world give exclusive<br />
rights of an original work to its creator, usually<br />
for a limited time, enacted as a copyright. Copyrights<br />
protect the way an idea is presented—not<br />
the idea itself. For example, they may protect the<br />
particular wording of an account of an historical<br />
event, whereas the event itself is not protected.<br />
Copyrights are long-term and renewable; they<br />
date back to the 17th century.<br />
<br />
====Trade Secrets====<br />
<br />
In many countries, an intellectual asset such as<br />
a formula, algorithm, process, design, method,<br />
pattern, instrument, or compilation of information<br />
may be considered a “trade secret,” provided<br />
that these assets are not generally known and may<br />
provide a business some economic advantage.<br />
The designation of “trade secret” provides legal<br />
protection if the asset is stolen. This protection<br />
is not subject to a time limit. However, if another<br />
party derives or discovers the same asset legally,<br />
then the asset is no longer protected and the other<br />
party will also possess all rights to use it.<br />
<br />
====Professional Liability====<br />
<br />
It is common for software engineers to be concerned<br />
with matters of professional liability. As an individual provides services to a client or<br />
employer, it is vital to adhere to standards and<br />
generally accepted practices, thereby protecting<br />
against allegations or proceedings of or related to<br />
malpractice, negligence, or incompetence.<br />
<br />
For engineers, including software engineers,<br />
professional liability is related to product liability.<br />
Under the laws and rules governing in their<br />
jurisdiction, engineers may be held to account<br />
for failing to fully and conscientiously follow<br />
recommended practice; this is known as “negligence.”<br />
They may also be subject to laws governing<br />
“strict liability” and either implied or express<br />
warranty, where, by selling the product, the engineer<br />
is held to warrant that the product is both<br />
suitable and safe for use. In some countries (for<br />
example, in the US), “privity” (the idea that one<br />
could only sue the person selling the product) is<br />
no longer a defense against liability actions.<br />
<br />
Legal suits for liability can be brought under<br />
tort law in the US allowing anyone who is harmed<br />
to recover their loss even if no guarantees were<br />
made. Because it is difficult to measure the suitability<br />
or safety of software, failure to take due<br />
care can be used to prove negligence on the part<br />
of software engineers. A defense against such an<br />
allegation is to show that standards and generally<br />
accepted practices were followed in the development<br />
of the product.<br />
<br />
====Legal Requirements====<br />
<br />
Software engineers must operate within the confines<br />
of local, national, and international legal<br />
frameworks. Therefore, software engineers must<br />
be aware of legal requirements for<br />
<br />
* registration and licensing—including examination, education, experience, and training requirements;<br />
* contractual agreements;<br />
* noncontractual legalities, such as those governing liability;<br />
* Basic information on the international legal framework can be accessed from the World Trade Organization (WTO).<br />
<br />
====Trade Compliance====<br />
<br />
All software professionals must be aware of<br />
legal restrictions on import, export, or reexport<br />
of goods, services, and technology in the jurisdictions<br />
in which they work. The considerations<br />
include export controls and classification, transfer<br />
of goods, acquisition of necessary governmental<br />
licenses for foreign use of hardware and software,<br />
services and technology by sanctioned nation,<br />
enterprise or individual entities, and import<br />
restrictions and duties. Trade experts should be<br />
consulted for detailed compliance guidance.<br />
<br />
====Cybercrime====<br />
<br />
Cybercrime refers to any crime that involves<br />
a computer, computer software, computer networks,<br />
or embedded software controlling a system.<br />
The computer or software may have been<br />
used in the commission of a crime or it may have<br />
been the target. This category of crime includes<br />
fraud, unauthorized access, spam, obscene or<br />
offensive content, threats, harassment, theft of<br />
sensitive personal data or trade secrets, and use<br />
of one computer to damage or infiltrate other<br />
networked computers and automated system<br />
controls.<br />
<br />
Computer and software users commit fraud by<br />
altering electronic data to facilitate illegal activity.<br />
Forms of unauthorized access include hacking,<br />
eavesdropping, and using computer systems<br />
in a way that is concealed from their owners.<br />
<br />
Many countries have separate laws to cover<br />
cybercrimes, but it has sometimes been difficult<br />
to prosecute cybercrimes due to a lack of precisely<br />
framed statutes. The software engineer has<br />
a professional obligation to consider the threat of<br />
cybercrime and to understand how the software<br />
system will protect or endanger software and user<br />
information from accidental or malicious access,<br />
use, modification, destruction, or disclosure.<br />
<br />
===Documentation===<br />
{{RightSection|{{referenceLink|number=1|parts=c10s5.8}} {{referenceLink|number=3|parts=c1s5}} {{referenceLink|number=5|parts=c32}}}}<br />
<br />
Providing clear, thorough, and accurate documentation<br />
is the responsibility of each software<br />
engineer. The adequacy of documentation is judged by different criteria based on the needs of<br />
the various stakeholder audiences<br />
<br />
Good documentation complies with accepted<br />
standards and guidelines. In particular, software<br />
engineers should document<br />
<br />
* relevant facts,<br />
* significant risks and tradeoffs, and<br />
* warnings of undesirable or dangerous consequences from use or misuse of the software.<br />
<br />
Software engineers should avoid<br />
<br />
* certifying or approving unacceptable products,<br />
* disclosing confidential information, or<br />
* falsifying facts or data.<br />
<br />
In addition, software engineers and their managers<br />
should notably provide the following documentation<br />
for use by other elements of the software<br />
development organization:<br />
<br />
* software requirements specifications, software design documents, details on the software engineering tools used, software test specifications and results, and details on the adopted software engineering methods;<br />
* problems encountered during the development process.<br />
<br />
For external stakeholders (customer, users,<br />
others) software documentation should notably<br />
provide<br />
<br />
* information needed to determine if the software is likely to meet the customer’s and users’ needs,<br />
* description of the safe, and unsafe, use of the software,<br />
* description of the protection of sensitive information created by or stored using the software, and<br />
* clear identification of warnings and critical procedures.<br />
<br />
Use of software may include installation, operation,<br />
administration, and performance of other<br />
functions by various groups of users and support<br />
personnel. If the customer will acquire ownership of the software source code or the right to modify<br />
the code, the software engineer should provide<br />
documentation of the functional specifications,<br />
the software design, the test suite, and the necessary<br />
operating environment for the software.<br />
<br />
The minimum length of time documents should<br />
be kept is the duration of the software products’<br />
life cycle or the time required by relevant organizational<br />
or regulatory requirements.<br />
<br />
===Tradeoff Analysis===<br />
{{RightSection|{{referenceLink|number=3|parts=c1s2, c10}} {{referenceLink|number=9|parts=c9s5.10}}}}<br />
<br />
Within the practice of software engineering, a<br />
software engineer often has to choose between<br />
alternative problem solutions. The outcome of<br />
these choices is determined by the software engineer’s<br />
professional evaluation of the risks, costs,<br />
and benefits of alternatives, in cooperation with<br />
stakeholders. The software engineer’s evaluation<br />
is called “tradeoff analysis.” Tradeoff analysis<br />
notably enables the identification of competing<br />
and complementary software requirements<br />
in order to prioritize the final set of requirements<br />
defining the software to be constructed<br />
(see Requirements Negotiation in the Software<br />
Requirements KA and Determination and Negotiation<br />
of Requirements in the Software Engineering<br />
Management KA).<br />
<br />
In the case of an ongoing software development<br />
project that is late or over budget, tradeoff<br />
analysis is often conducted to decide which software<br />
requirements can be relaxed or dropped<br />
given the effects thereof.<br />
<br />
A first step in a tradeoff analysis is establishing<br />
design goals (see Engineering Design in the<br />
Engineering Foundations KA) and setting the<br />
relative importance of those goals. This permits<br />
identification of the solution that most nearly<br />
meets those goals; this means that the way the<br />
goals are stated is critically important.<br />
<br />
Design goals may include minimization of<br />
monetary cost and maximization of reliability,<br />
performance, or some other criteria on a wide<br />
range of dimensions. However, it is difficult to<br />
formulate a tradeoff analysis of cost against risk,<br />
especially where primary production and secondary<br />
risk-based costs must be traded against each<br />
other.<br />
<br />
A software engineer must conduct a tradeoff<br />
analysis in an ethical manner—notably by being<br />
objective and impartial when selecting criteria for<br />
comparison of alternative problem solutions and<br />
when assigning weights or importance to these<br />
criteria. Any conflict of interest must be disclosed<br />
up front.<br />
<br />
==Group Dynamics and Psychology==<br />
<br />
Engineering work is very often conducted in the<br />
context of teamwork. A software engineer must<br />
be able to interact cooperatively and constructively<br />
with others to first determine and then<br />
meet both needs and expectations. Knowledge of<br />
group dynamics and psychology is an asset when<br />
interacting with customers, coworkers, suppliers,<br />
and subordinates to solve software engineering<br />
problems.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=857Chapter 11: Software Engineering Professional Practice2015-08-29T08:02:00Z<p>Daniel Robbins: /* Codes of Ethics and Professional Conduct */</p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}<br />
<br />
Codes of ethics and professional conduct comprise<br />
the values and behavior that an engineer’s<br />
professional practice and decisions should<br />
embody.<br />
<br />
The professional community establishes codes<br />
of ethics and professional conduct. They exist<br />
in the context of, and are adjusted to agree with,<br />
societal norms and local laws. Therefore, codes<br />
of ethics and professional conduct present guidance<br />
in the face of conflicting imperatives.<br />
<br />
Once established, codes of ethics and professional<br />
conduct are enforced by the profession,<br />
as represented by professional societies or by a<br />
statutory body.<br />
<br />
Violations may be acts of commission, such<br />
as concealing inadequate work, disclosing confidential<br />
information, falsifying information, or<br />
misrepresenting one’s abilities. They may also<br />
occur through omission, including failure to disclose<br />
risks or to provide important information,<br />
failure to give proper credit or to acknowledge<br />
references, and failure to represent client interests.<br />
Violations of codes of ethics and professional<br />
conduct may result in penalties and possible<br />
expulsion from professional status.<br />
<br />
A code of ethics and professional conduct for<br />
software engineering was approved by the ACM<br />
Council and the IEEE CS Board of Governors in<br />
1999 [6*]. According to the short version of this<br />
code:<br />
<br />
* Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the eight principles concerning the public, client and employer, product, judgment, management, profession, colleagues, and self, respectively.<br />
<br />
Since standards and codes of ethics and professional<br />
conduct may be introduced, modified,<br />
or replaced at any time, individual software engineers<br />
bear the responsibility for their own continuing<br />
study to stay current in their professional<br />
practice.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=856Chapter 11: Software Engineering Professional Practice2015-08-29T07:57:13Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}<br />
<br />
{{IntroSection|title=Breakdown of Topics for Software Engineering Professional Practice|body=<br />
The Software Engineering Professional Practice<br />
KA’s breakdown of topics is shown in Figure<br />
11.1. The subareas presented in this KA are professionalism,<br />
group dynamics and psychology,<br />
and communication skills.}}<br />
[[File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg|thumb|400px|frame|Figure 11.1: Breakdown of Topics for the Software Engineering Professional Practice KA]]<br />
<br />
==Professionalism==<br />
<br />
A software engineer displays professionalism<br />
notably through adherence to codes of ethics<br />
and professional conduct and to standards and practices that are established by the engineer’s<br />
professional community.<br />
<br />
The professional community is often represented<br />
by one or more professional societies;<br />
those societies publish codes of ethics and professional<br />
conduct as well as criteria for admittance<br />
to the community. Those criteria form the basis<br />
for accreditation and licensing activities and may<br />
be used as a measure to determine engineering<br />
competence or negligence.<br />
<br />
===Accreditation, Certification, and Licensing===<br />
{{RightSection|{{referenceLink|number=1|parts=cc1s4.1, c1s5.1–c1s5.4}}}}<br />
<br />
====Accreditation====<br />
<br />
Accreditation is a process to certify the competency,<br />
authority, or credibility of an organization.<br />
Accredited schools or programs are assured to<br />
adhere to particular standards and maintain certain<br />
qualities. In many countries, the basic means<br />
by which engineers acquire knowledge is through<br />
completion of an accredited course of study.<br />
Often, engineering accreditation is performed by<br />
a government organization, such as the ministry<br />
of education. Such countries with government<br />
accreditations include China, France, Germany,<br />
Israel, Italy, and Russia.<br />
<br />
In other countries, however, the accreditation<br />
process is independent of government and<br />
performed by private membership associations.<br />
For example, in the United States, engineering<br />
accreditation is performed by an organization<br />
known as ABET. An organization known as<br />
CSAB serving as a participating body of ABET<br />
is the lead society within ABET for the accreditation<br />
of degree programs in software engineering.<br />
While the process of accreditation may be different<br />
for each country and jurisdiction, the general<br />
meaning is the same. For an institution’s course of<br />
study to be accredited means that “the accreditation<br />
body recognizes an educational institution as<br />
maintaining standards that qualify the graduates<br />
for admission to higher or more specialized institutions<br />
or for professional practice” [2].<br />
<br />
====Certification====<br />
<br />
Certification refers to the confirmation of a person’s<br />
particular characteristics. A common type of certification is professional certification, where<br />
a person is certified as being able to complete an<br />
activity in a certain discipline at a stated level<br />
of competency. Professional certification also<br />
can also verify the holder’s ability to meet professional<br />
standards and to apply professional<br />
judgment in solving or addressing problems.<br />
Professional certification can also involve the<br />
verification of prescribed knowledge, the mastering<br />
of best practice and proven methodologies,<br />
and the amount of professional experience.<br />
<br />
An engineer usually obtains certification by<br />
passing an examination in conjunction with other<br />
experience-based criteria. These examinations<br />
are often administered by nongovernmental organizations,<br />
such as professional societies.<br />
<br />
In software engineering, certification testifies<br />
to one’s qualification as a software engineer.<br />
For example, the IEEE CS has enacted two certification<br />
programs (CSDA and CSDP) designed<br />
to confirm a software engineer’s knowledge of<br />
standard software engineering practices and to<br />
advance one’s career. A lack of certification does<br />
not exclude the individual from working as a<br />
software engineer. Currently certification in software<br />
engineering is completely voluntary. In fact,<br />
most software engineers are not certified under<br />
any program.<br />
<br />
====Licensing====<br />
<br />
“Licensing” is the action of giving a person the<br />
authorization to perform certain kinds of activities<br />
and take responsibility for resultant engineering<br />
products. The noun “license” refers to both<br />
that authorization and the document recording<br />
that authorization. Governmental authorities or<br />
statutory bodies usually issue licenses.<br />
<br />
Obtaining a license to practice requires not only<br />
that an individual meets a certain standard, but<br />
also that they do so with a certain ability to practice<br />
or operate. Sometimes there is an entry-level<br />
requirement which sets the minimum skills and<br />
capabilities to practice, but as the professional<br />
moves through his or her career, the required<br />
skills and capabilities change and evolve.<br />
<br />
In general, engineers are licensed as a means of<br />
protecting the public from unqualified individuals.<br />
In some countries, no one can practice as a professional<br />
engineer unless licensed; or further, no company may offer “engineering services” unless<br />
at least one licensed engineer is employed there.<br />
<br />
===Codes of Ethics and Professional Conduct===<br />
{{RightSection|{{referenceLink|number=1|parts=c1s6–c1s9}} {{referenceLink|number=3|parts=c8}} {{referenceLink|number=4|parts=c1s2}} {{referenceLink|number=5|parts=c33}} {{referenceLink|number=6}}}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=File:Breakdown_of_Topics_for_the_Software_Engineering_Professional_Practice_KA.jpg&diff=855File:Breakdown of Topics for the Software Engineering Professional Practice KA.jpg2015-08-29T07:05:00Z<p>Daniel Robbins: </p>
<hr />
<div></div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_11:_Software_Engineering_Professional_Practice&diff=854Chapter 11: Software Engineering Professional Practice2015-08-29T06:58:38Z<p>Daniel Robbins: Created page with "{{TOC}} {{Acronym|name=ACM|description=Association for Computing Machinery}} {{Acronym|name=BCS|description=British Computer Society}} {{Acronym|name=CSDA|description=Certifi..."</p>
<hr />
<div>{{TOC}}<br />
<br />
{{Acronym|name=ACM|description=Association for Computing Machinery}}<br />
{{Acronym|name=BCS|description=British Computer Society}}<br />
{{Acronym|name=CSDA|description=Certified Software Development Associate}}<br />
{{Acronym|name=CSDP|description=Certified Software Development Professional}}<br />
{{Acronym|name=IEC|description=International Electrotechnical Commission}}<br />
{{Acronym|name=IEEE CS|description=IEEE Computer Society}}<br />
{{Acronym|name=IFIP|description=International Federation for Information Processing}}<br />
{{Acronym|name=IP|description=Intellectual Property}}<br />
{{Acronym|name=ISO|description=International Organization for Standardization}}<br />
{{Acronym|name=NDA|description=Non-Disclosure Agreement}}<br />
{{Acronym|name=WIPO|description=World Intellectual Property Organization}<br />
{{Acronym|name=WTO|description=World Trade Organization}}<br />
}}<br />
<br />
{{IntroSection|title=Introduction|body=<br />
<br />
The Software Engineering Professional Practice<br />
knowledge area (KA) is concerned with the<br />
knowledge, skills, and attitudes that software<br />
engineers must possess to practice software engineering<br />
in a professional, responsible, and ethical<br />
manner. Because of the widespread applications<br />
of software products in social and personal<br />
life, the quality of software products can have<br />
profound impact on our personal well-being<br />
and societal harmony. Software engineers must<br />
handle unique engineering problems, producing software with known characteristics and reliability.<br />
This requirement calls for software engineers<br />
who possess a proper set of knowledge, skills,<br />
training, and experience in professional practice.<br />
<br />
The term “professional practice” refers to a<br />
way of conducting services so as to achieve certain<br />
standards or criteria in both the process of<br />
performing a service and the end product resulting<br />
from the service. These standards and criteria<br />
can include both technical and nontechnical<br />
aspects. The concept of professional practice can<br />
be viewed as being more applicable within those<br />
professions that have a generally accepted body<br />
of knowledge; codes of ethics and professional<br />
conduct with penalties for violations; accepted<br />
processes for accreditation, certification, and<br />
licensing; and professional societies to provide<br />
and administer all of these. Admission to these<br />
professional societies is often predicated on a prescribed<br />
combination of education and experience.<br />
<br />
A software engineer maintains a professional<br />
practice by performing all work in accordance<br />
with generally accepted practices, standards, and<br />
guidelines notably set forth by the applicable professional<br />
society. For example, the Association for<br />
Computing Machinery (ACM) and IEEE Computer<br />
Society (IEEE CS) have established a Software<br />
Engineering Code of Ethics and Professional<br />
Practice. Both the British Computer Society (BCS)<br />
and the International Federation for Information<br />
Processing (IFIP) have established similar professional<br />
practice standards. ISO/IEC and IEEE have<br />
further provided internationally accepted software<br />
engineering standards (see Appendix B of this<br />
''Guide''). IEEE CS has established two international<br />
certification programs (CSDA, CSDP) and a corresponding<br />
''Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide)''.<br />
All of these are elements that lay the foundation for of the professional<br />
practice of software engineering.}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=File:A_Cash_Flow_Diagram.jpg&diff=853File:A Cash Flow Diagram.jpg2015-08-29T06:46:15Z<p>Daniel Robbins: Daniel Robbins uploaded a new version of File:A Cash Flow Diagram.jpg</p>
<hr />
<div></div>Daniel Robbinshttp://swebokwiki.org/index.php?title=File:The_Seven-Layer_OSI_Networking_Model.jpg&diff=852File:The Seven-Layer OSI Networking Model.jpg2015-08-29T06:41:48Z<p>Daniel Robbins: Daniel Robbins uploaded a new version of File:The Seven-Layer OSI Networking Model.jpg</p>
<hr />
<div></div>Daniel Robbinshttp://swebokwiki.org/index.php?title=File:Machine_Architecture_Levels.jpg&diff=851File:Machine Architecture Levels.jpg2015-08-29T06:40:12Z<p>Daniel Robbins: Daniel Robbins uploaded a new version of File:Machine Architecture Levels.jpg</p>
<hr />
<div></div>Daniel Robbinshttp://swebokwiki.org/index.php?title=File:Machine_Architecture_Levels.jpg&diff=850File:Machine Architecture Levels.jpg2015-08-29T06:40:11Z<p>Daniel Robbins: Daniel Robbins uploaded a new version of File:Machine Architecture Levels.jpg</p>
<hr />
<div></div>Daniel Robbinshttp://swebokwiki.org/index.php?title=File:Assembly-to-Binary_Translations.jpg&diff=849File:Assembly-to-Binary Translations.jpg2015-08-29T06:38:34Z<p>Daniel Robbins: Daniel Robbins uploaded a new version of File:Assembly-to-Binary Translations.jpg</p>
<hr />
<div></div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=848Chapter 15: Engineering Foundations2015-08-29T06:36:11Z<p>Daniel Robbins: /* Techniques for Conducting Root Cause Analysis */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any point on this line and a fixed interior point called the center is constant''. <br />
We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.<br />
<br />
The importance of operational definitions<br />
can hardly be overstated. Take the case of the<br />
apparently simple measurement of height of<br />
individuals. Unless we specify various factors<br />
like the time when the height will be measured<br />
(it is known that the height of individuals vary<br />
across various time points of the day), how the<br />
variability due to hair would be taken care of,<br />
whether the measurement will be with or without<br />
shoes, what kind of accuracy is expected (correct<br />
up to an inch, 1/2 inch, centimeter, etc.) — even this simple measurement will lead to substantial<br />
variation. Engineers must appreciate the need to<br />
define measures from an operational perspective.<br />
<br />
===Levels (Scales) of Measurement===<br />
{{RightSection| {{referenceLink|number=4|parts=c3s2}} {{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Once the operational definitions are determined,<br />
the actual measurements need to be undertaken.<br />
It is to be noted that measurement may be carried<br />
out in four different scales: namely, nominal,<br />
ordinal, interval, and ratio. Brief descriptions of<br />
each are given below.<br />
<br />
''Nominal scale'': This is the lowest level of measurement<br />
and represents the most unrestricted<br />
assignment of numerals. The numerals serve only<br />
as labels, and words or letters would serve as well.<br />
The nominal scale of measurement involves only<br />
classification and the observed sampling units<br />
are put into any one of the mutually exclusive<br />
and collectively exhaustive categories (classes).<br />
Some examples of nominal scales are:<br />
<br />
* Job titles in a company<br />
* The software development life cycle (SDLC) model (like waterfall, iterative, agile, etc.) followed by different software projects<br />
<br />
In nominal scale, the names of the different categories<br />
are just labels and no relationship between<br />
them is assumed. The only operations that can be<br />
carried out on nominal scale is that of counting<br />
the number of occurrences in the different classes<br />
and determining if two occurrences have the same<br />
nominal value. However, statistical analyses may<br />
be carried out to understand how entities belonging<br />
to different classes perform with respect to<br />
some other response variable.<br />
<br />
''Ordinal scale'': Refers to the measurement scale<br />
where the different values obtained through the<br />
process of measurement have an implicit ordering.<br />
The intervals between values are not specified<br />
and there is no objectively defined zero<br />
element. Typical examples of measurements in<br />
ordinal scales are:<br />
<br />
* Skill levels (low, medium, high)<br />
* Capability Maturity Model Integration (CMMI) maturity levels of software development organizations<br />
* Level of adherence to process as measured in a 5-point scale of excellent, above average, average, below average, and poor, indicating<br />
the range from total adherence to no adherence at all<br />
<br />
Measurement in ordinal scale satisfies the transitivity<br />
property in the sense that if A > B and B<br />
> C, then A > C. However, arithmetic operations<br />
cannot be carried out on variables measured in<br />
ordinal scales. Thus, if we measure customer satisfaction<br />
on a 5-point ordinal scale of 5 implying<br />
a very high level of satisfaction and 1 implying a<br />
very high level of dissatisfaction, we cannot say<br />
that a score of four is twice as good as a score<br />
of two. So, it is better to use terminology such<br />
as excellent, above average, average, below average,<br />
and poor than ordinal numbers in order to<br />
avoid the error of treating an ordinal scale as a<br />
ratio scale. It is important to note that ordinal<br />
scale measures are commonly misused and such<br />
misuse can lead to erroneous conclusions [6*,<br />
p274]. A common misuse of ordinal scale measures<br />
is to present a mean and standard deviation<br />
for the data set, both of which are meaningless.<br />
However, we can find the median, as computation<br />
of the median involves counting only.<br />
<br />
''Interval scales'': With the interval scale, we<br />
come to a form that is quantitative in the ordinary<br />
sense of the word. Almost all the usual statistical<br />
measures are applicable here, unless they<br />
require knowledge of a ''true' zero point. The zero<br />
point on an interval scale is a matter of convention.<br />
Ratios do not make sense, but the difference<br />
between levels of attributes can be computed and<br />
is meaningful. Some examples of interval scale of<br />
measurement follow:<br />
<br />
* Measurement of temperature in different scales, such as Celsius and Fahrenheit. Suppose T<sub>1</sub> and T<sub>2</sub> are temperatures measured in some scale. We note that the fact that T<sub>1</sub> is twice T<sub>2</sub> does not mean that one object is twice as hot as another. We also note that the zero points are arbitrary.<br />
* Calendar dates. While the difference between dates to measure the time elapsed is a meaningful concept, the ratio does not make sense.<br />
* Many psychological measurements aspire to create interval scales. Intelligence is often measured in interval scale, as it is not necessary to define what zero intelligence would mean.<br />
<br />
If a variable is measured in interval scale, most<br />
of the usual statistical analyses like mean, standard<br />
deviation, correlation, and regression may<br />
be carried out on the measured values.<br />
<br />
''Ratio scale'': These are quite commonly encountered<br />
in physical science. These scales of measures<br />
are characterized by the fact that operations<br />
exist for determining all 4 relations: equality, rank<br />
order, equality of intervals, and equality of ratios.<br />
Once such a scale is available, its numerical values<br />
can be transformed from one unit to another<br />
by just multiplying by a constant, e.g., conversion<br />
of inches to feet or centimeters. When measurements<br />
are being made in ratio scale, existence of<br />
a nonarbitrary zero is mandatory. All statistical<br />
measures are applicable to ratio scale; logarithm<br />
usage is valid only when these scales are used, as<br />
in the case of decibels. Some examples of ratio<br />
measures are<br />
<br />
* the number of statements in a software program<br />
* temperature measured in the Kelvin (K) scale or in Fahrenheit (F).<br />
<br />
An additional measurement scale, the absolute<br />
scale, is a ratio scale with uniqueness of the measure;<br />
i.e., a measure for which no transformation<br />
is possible (for example, the number of programmers<br />
working on a project).<br />
<br />
===Direct and Derived Measures===<br />
{{RightSection|{{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Measures may be either direct or derived (sometimes<br />
called indirect measures). An example of<br />
a direct measure would be a count of how many<br />
times an event occurred, such as the number of<br />
defects found in a software product. A derived<br />
measure is one that combines direct measures in<br />
some way that is consistent with the measurement<br />
method. An example of a derived measure would<br />
be calculating the productivity of a team as the<br />
number of lines of code developed per developermonth.<br />
In both cases, the measurement method<br />
determines how to make the measurement.<br />
<br />
===Reliability and Validity===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s4, c3s5}}}}<br />
<br />
A basic question to be asked for any measurement<br />
method is whether the proposed measurement<br />
method is truly measuring the concept with<br />
good quality. Reliability and validity are the two<br />
most important criteria to address this question.<br />
<br />
The reliability of a measurement method is<br />
the extent to which the application of the measurement<br />
method yields consistent measurement<br />
results. Essentially, ''reliability'' refers to the consistency<br />
of the values obtained when the same item<br />
is measured a number of times. When the results<br />
agree with each other, the measurement method<br />
is said to be reliable. Reliability usually depends<br />
on the operational definition. It can be quantified<br />
by using the index of variation, which is computed<br />
as the ratio between the standard deviation<br />
and the mean. The smaller the index, the more<br />
reliable the measurement results.<br />
<br />
''Validity'' refers to whether the measurement<br />
method really measures what we intend to measure.<br />
Validity of a measurement method may<br />
be looked at from three different perspectives:<br />
namely, construct validity, criteria validity, and<br />
content validity.<br />
<br />
===Assessing Reliability===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s5}}}}<br />
<br />
There are several methods for assessing reliability;<br />
these include the test-retest method, the<br />
alternative form method, the split-halves method,<br />
and the internal consistency method. The easiest<br />
of these is the test-retest method. In the testretest<br />
method, we simply apply the measurement<br />
method to the same subjects twice. The correlation<br />
coefficient between the first and second set<br />
of measurement results gives the reliability of the<br />
measurement method.<br />
<br />
==Engineering Design==<br />
{{RightSection|{{referenceLink|number=5|parts=c1s2, c1s3, c1s4}}}}<br />
<br />
A product’s life cycle costs are largely influenced<br />
by the design of the product. This is true for manufactured<br />
products as well as for software products.<br />
<br />
The design of a software product is guided by<br />
the features to be included and the quality attributes<br />
to be provided. It is important to note that<br />
software engineers use the term “design” within<br />
their own context; while there are some commonalities,<br />
there are also many differences between<br />
engineering design as discussed in this section<br />
and software engineering design as discussed in<br />
the Software Design KA. The scope of engineering<br />
design is generally viewed as much broader<br />
than that of software design. The primary aim of<br />
this section is to identify the concepts needed to<br />
develop a clear understanding regarding the process<br />
of engineering design.<br />
<br />
Many disciplines engage in problem solving<br />
activities where there is a single correct solution.<br />
In engineering, most problems have many<br />
solutions and the focus is on finding a feasible<br />
solution (among the many alternatives) that<br />
best meets the needs presented. The set of possible<br />
solutions is often constrained by explicitly<br />
imposed limitations such as cost, available<br />
resources, and the state of discipline or domain<br />
knowledge. In engineering problems, sometimes<br />
there are also implicit constraints (such as the<br />
physical properties of materials or laws of physics)<br />
that also restrict the set of feasible solutions<br />
for a given problem.<br />
<br />
===Engineering Design in Engineering Education===<br />
<br />
The importance of engineering design in engineering<br />
education can be clearly seen by the high<br />
expectations held by various accreditation bodies<br />
for engineering education. Both the Canadian<br />
Engineering Accreditation Board and the<br />
Accreditation Board for Engineering and Technology<br />
(ABET) note the importance of including<br />
engineering design in education programs.<br />
<br />
The Canadian Engineering Accreditation<br />
Board includes requirements for the amount of<br />
engineering design experience/coursework that<br />
is necessary for engineering students as well as<br />
qualifications for the faculty members who teach<br />
such coursework or supervise design projects.<br />
Their accreditation criteria states:<br />
<br />
* Design: An ability to design solutions for complex, open-ended engineering problems and to design systems, components or processes that meet specified needs with appropriate attention to health and safety risks, applicable standards, and economic, environmental, cultural and societal considerations. [8, p12]<br />
<br />
In a similar manner, ABET defines engineering<br />
design as<br />
<br />
* the process of devising a system, component, or process to meet desired needs. It is a decision-making process (often iterative), in which the basic sciences, mathematics, and the engineering sciences are applied to convert resources optimally to meet these stated needs. [9, p4]<br />
<br />
Thus, it is clear that engineering design is a<br />
vital component in the training and education for<br />
all engineers. The remainder of this section will<br />
focus on various aspects of engineering design.<br />
<br />
===Design as a Problem Solving Activity===<br />
{{RightSection|{{referenceLink|number=5|parts=c1s4, c2s1, c3s3}}}}<br />
<br />
It is to be noted that engineering design is primarily<br />
a problem solving activity. Design problems<br />
are open ended and more vaguely defined. There<br />
are usually several alternative ways to solve the<br />
same problem. Design is generally considered to<br />
be a ''wicked problem'' —a term first coined by Horst<br />
Rittel in the 1960s when design methods were a<br />
subject of intense interest. Rittel sought an alternative<br />
to the linear, step-by-step model of the design<br />
process being explored by many designers and<br />
design theorists and argued that most of the problems<br />
addressed by the designers are wicked problems.<br />
As explained by Steve McConnell, a wicked<br />
problem is one that could be clearly defined only<br />
by solving it or by solving part of it. This paradox<br />
implies, essentially, that a wicked problem has to<br />
be solved once in order to define it clearly and then<br />
solved again to create a solution that works. This<br />
has been an important insight for software designers<br />
for several decades [10*, c5s1].<br />
<br />
===Steps Involved in Engineering Design===<br />
{{RightSection|{{referenceLink|number=7|parts=c4}}}}<br />
<br />
Engineering problem solving begins when a<br />
need is recognized and no existing solution will<br />
meet that need. As part of this problem solving,<br />
the design goals to be achieved by the solution<br />
should be identified. Additionally, a set of acceptance<br />
criteria must be defined and used to determine<br />
how well a proposed solution will satisfy<br />
the need. Once a need for a solution to a problem<br />
has been identified, the process of engineering<br />
design has the following generic steps:<br />
<br />
* a) define the problem<br />
* b) gather pertinent information<br />
* c) generate multiple solutions<br />
* d) analyze and select a solution<br />
* e) implement the solution<br />
<br />
All of the engineering design steps are iterative,<br />
and knowledge gained at any step in the<br />
process may be used to inform earlier tasks and<br />
trigger an iteration in the process. These steps are<br />
expanded in the subsequent sections<br />
<br />
''a''. ''Define the problem''. <br />
<br />
At this stage, the customer’s<br />
requirements are gathered. Specific information<br />
about product functions and features are also<br />
closely examined. This step includes refining the<br />
problem statement to identify the real problem to<br />
be solved and setting the design goals and criteria<br />
for success.<br />
<br />
The problem definition is a crucial stage in<br />
engineering design. A point to note is that this<br />
step is deceptively simple. Thus, enough care<br />
must be taken to carry out this step judiciously. It<br />
is important to identify needs and link the success<br />
criteria with the required product characteristics.<br />
It is also an engineering task to limit the scope<br />
of a problem and its solution through negotiation<br />
among the stakeholders.<br />
<br />
''b''. ''Gather pertinent information''.<br />
<br />
At this stage,<br />
the designer attempts to expand his/her knowledge<br />
about the problem. This is a vital, yet often<br />
neglected, stage. Gathering pertinent information<br />
can reveal facts leading to a redefinition of the problem—in particular, mistakes and false starts<br />
may be identified. This step may also involve the<br />
decomposition of the problem into smaller, more<br />
easily solved subproblems.<br />
<br />
While gathering pertinent information, care<br />
must be taken to identify how a product may be<br />
used as well as misused. It is also important to<br />
understand the perceived value of the product/<br />
service being offered. Included in the pertinent<br />
information is a list of constraints that must be<br />
satisfied by the solution or that may limit the set<br />
of feasible solutions.<br />
<br />
''c''. ''Generate multiple solutions''.<br />
<br />
During this stage,<br />
different solutions to the same problem are developed.<br />
It has already been stated that design problems<br />
have multiple solutions. The goal of this<br />
step is to conceptualize multiple possible solutions<br />
and refine them to a sufficient level of detail<br />
that a comparison can be done among them.<br />
<br />
''d''. ''Analyze and select a solution''.<br />
<br />
Once alternative<br />
solutions have been identified, they need to be analyzed<br />
to identify the solution that best suits the current<br />
situation. The analysis includes a functional<br />
analysis to assess whether the proposed design<br />
would meet the functional requirements. Physical<br />
solutions that involve human users often include<br />
analysis of the ergonomics or user friendliness of<br />
the proposed solution. Other aspects of the solution—<br />
such as product safety and liability, an economic<br />
or market analysis to ensure a return (profit)<br />
on the solution, performance predictions and analysis<br />
to meet quality characteristics, opportunities<br />
for incorrect data input or hardware malfunctions,<br />
and so on—may be studied. The types and amount<br />
of analysis used on a proposed solution are dependent<br />
on the type of problem and the needs that the<br />
solution must address as well as the constraints<br />
imposed on the design.<br />
<br />
''e''. ''Implement the solution''.<br />
<br />
The final phase of the<br />
design process is implementation. Implementation<br />
refers to development and testing of the<br />
proposed solution. Sometimes a preliminary,<br />
partial solution called a ''prototype'' may be developed<br />
initially to test the proposed design solution<br />
under certain conditions. Feedback resulting<br />
from testing a prototype may be used either to refine the design or drive the selection of an alternative<br />
design solution. One of the most important<br />
activities in design is documentation of the<br />
design solution as well as of the tradeoffs for the<br />
choices made in the design of the solution. This<br />
work should be carried out in a manner such that<br />
the solution to the design problem can be communicated<br />
clearly to others.<br />
<br />
The testing and verification take us back to the<br />
success criteria. The engineer needs to devise<br />
tests such that the ability of the design to meet the<br />
success criteria is demonstrated. While designing<br />
the tests, the engineer must think through<br />
different possible failure modes and then design<br />
tests based on those failure modes. The engineer<br />
may choose to carry out designed experiments to<br />
assess the validity of the design.<br />
<br />
==Modeling, Simulation, and Prototyping==<br />
{{RightSection|{{referenceLink|number=5|parts=c6}} {{referenceLink|number=11|parts=c13s3}} {{referenceLink|number=12|parts=c2s3.1}}}}<br />
<br />
Modeling is part of the abstraction process used<br />
to represent some aspects of a system. Simulation<br />
uses a model of the system and provides a<br />
means of conducting designed experiments with<br />
that model to better understand the system, its<br />
behavior, and relationships between subsystems,<br />
as well as to analyze aspects of the design. Modeling<br />
and simulation are techniques that can be<br />
used to construct theories or hypotheses about the<br />
behavior of the system; engineers then use those<br />
theories to make predictions about the system.<br />
Prototyping is another abstraction process where<br />
a partial representation (that captures aspects of<br />
interest) of the product or system is built. A prototype<br />
may be an initial version of the system but<br />
lacks the full functionality of the final version.<br />
<br />
===Modeling===<br />
<br />
A model is always an abstraction of some real<br />
or imagined artifact. Engineers use models in<br />
many ways as part of their problem solving<br />
activities. Some models are physical, such as a<br />
made-to-scale miniature construction of a bridge<br />
or building. Other models may be nonphysical<br />
representations, such as a CAD drawing of a cog<br />
or a mathematical model for a process. Models<br />
help engineers reason and understand aspects of a problem. They can also help engineers understand<br />
what they do know and what they don’t<br />
know about the problem at hand.<br />
<br />
There are three types of models: iconic, analogic,<br />
and symbolic. An iconic model is a visually<br />
equivalent but incomplete 2-dimensional<br />
or 3-dimensional representation—for example,<br />
maps, globes, or built-to-scale models of structures<br />
such as bridges or highways. An iconic<br />
model actually resembles the artifact modeled.<br />
<br />
In contrast, an analogic model is a functionally<br />
equivalent but incomplete representation. That<br />
is, the model behaves like the physical artifact<br />
even though it may not physically resemble it.<br />
Examples of analogic models include a miniature<br />
airplane for wind tunnel testing or a computer<br />
simulation of a manufacturing process.<br />
<br />
Finally, a symbolic model is a higher level of<br />
abstraction, where the model is represented using<br />
symbols such as equations. The model captures<br />
the relevant aspects of the process or system in<br />
symbolic form. The symbols can then be used to<br />
increase the engineer’s understanding of the final<br />
system. An example is an equation such as F = Ma. Such mathematical models can be used to<br />
describe and predict properties or behavior of the<br />
final system or product.<br />
<br />
===Simulation===<br />
<br />
All simulation models are a specification of reality.<br />
A central issue in simulation is to abstract<br />
and specify an appropriate simplification of<br />
reality. Developing this abstraction is of vital<br />
importance, as misspecification of the abstraction<br />
would invalidate the results of the simulation<br />
exercise. Simulation can be used for a variety of<br />
testing purposes.<br />
<br />
Simulation is classified based on the type of<br />
system under study. Thus, simulation can be either<br />
continuous or discrete. In the context of software<br />
engineering, the emphasis will be primarily on<br />
discrete simulation. Discrete simulations may<br />
model event scheduling or process interaction.<br />
The main components in such a model include<br />
entities, activities and events, resources, the state<br />
of the system, a simulation clock, and a random<br />
number generator. Output is generated by the<br />
simulation and must be analyzed.<br />
<br />
An important problem in the development of a<br />
discrete simulation is that of initialization. Before<br />
a simulation can be run, the initial values of all<br />
the state variables must be provided. As the simulation<br />
designer may not know what initial values<br />
are appropriate for the state variables, these values<br />
might be chosen somewhat arbitrarily. For<br />
instance, it might be decided that a queue should<br />
be initialized as empty and idle. Such a choice of<br />
initial condition can have a significant but unrecognized<br />
impact on the outcome of the simulation.<br />
<br />
===Prototyping===<br />
<br />
Constructing a prototype of a system is another<br />
abstraction process. In this case, an initial version<br />
of the system is constructed, often while the system<br />
is being designed. This helps the designers<br />
determine the feasibility of their design.<br />
<br />
There are many uses for a prototype, including<br />
the elicitation of requirements, the design and<br />
refinement of a user interface to the system, validation<br />
of functional requirements, and so on. The<br />
objectives and purposes for building the prototype<br />
will determine its construction and the level<br />
of abstraction used.<br />
<br />
The role of prototyping is somewhat different<br />
between physical systems and software. With<br />
physical systems, the prototype may actually<br />
be the first fully functional version of a system<br />
or it may be a model of the system. In software<br />
engineering, prototypes are also an abstract<br />
model of part of the software but are usually not<br />
constructed with all of the architectural, performance,<br />
and other quality characteristics expected<br />
in the finished product. In either case, prototype<br />
construction must have a clear purpose and be<br />
planned, monitored, and controlled—it is a technique<br />
to study a specific problem within a limited<br />
context [6*, c2s8].<br />
<br />
In conclusion, modeling, simulation, and prototyping<br />
are powerful techniques for studying the<br />
behavior of a system from a given perspective.<br />
All can be used to perform designed experiments<br />
to study various aspects of the system. However,<br />
these are abstractions and, as such, may not<br />
model all attributes of interest.<br />
<br />
==Standards==<br />
{{RightSection|{{referenceLink|number=5|parts=c9s3.2}} {{referenceLink|number=13|parts=c1s2}}}}<br />
<br />
Moore states that a<br />
<br />
* standard can be;<br />
** (a) an object or measure of comparison that defines or represents the magnitude of a unit;<br />
** (b) a characterization that establishes allowable tolerances for categories of items;<br />
** and (c) a degree or level of required excellence or attainment.<br />
* Standards are definitional in nature, established either to further understanding and interaction or to acknowledge observed (or<br />
desired) norms of exhibited characteristics or behavior. [13*, p8]<br />
<br />
Standards provide requirements, specifications,<br />
guidelines, or characteristics that must be<br />
observed by engineers so that the products, processes,<br />
and materials have acceptable levels of<br />
quality. The qualities that various standards provide<br />
may be those of safety, reliability, or other<br />
product characteristics. Standards are considered<br />
critical to engineers and engineers are expected to<br />
be familiar with and to use the appropriate standards<br />
in their discipline.<br />
<br />
Compliance or conformance to a standard lets<br />
an organization say to the public that they (or<br />
their products) meet the requirements stated in<br />
that standard. Thus, standards divide organizations<br />
or their products into those that conform to<br />
the standard and those that do not. For a standard<br />
to be useful, conformance with the standard must<br />
add value—real or perceived—to the product,<br />
process, or effort.<br />
<br />
Apart from the organizational goals, standards<br />
are used for a number of other purposes such<br />
as protecting the buyer, protecting the business,<br />
and better defining the methods and procedures<br />
to be followed by the practice. Standards also<br />
provide users with a common terminology and<br />
expectations.<br />
<br />
There are many internationally recognized<br />
standards-making organizations including the<br />
International Telecommunications Union (ITU),<br />
the International Electrotechnical Commission<br />
(IEC), IEEE, and the International Organization<br />
for Standardization (ISO). In addition, there are regional and governmentally recognized organizations<br />
that generate standards for that region or<br />
country. For example, in the United States, there<br />
are over 300 organizations that develop standards.<br />
These include organizations such as the<br />
American National Standards Institute (ANSI),<br />
the American Society for Testing and Materials<br />
(ASTM), the Society of Automotive Engineers<br />
(SAE), and Underwriters Laboratories, Inc. (UL),<br />
as well as the US government. For more detail<br />
on standards used in software engineering, see<br />
Appendix B on standards.<br />
<br />
There is a set of commonly used principles<br />
behind standards. Standards makers attempt to<br />
have consensus around their decisions. There is<br />
usually an openness within the community of<br />
interest so that once a standard has been set, there<br />
is a good chance that it will be widely accepted.<br />
Most standards organizations have well-defined<br />
processes for their efforts and adhere to those<br />
processes carefully. Engineers must be aware of<br />
the existing standards but must also update their<br />
understanding of the standards as those standards<br />
change over time.<br />
<br />
In many engineering endeavors, knowing and<br />
understanding the applicable standards is critical<br />
and the law may even require use of particular<br />
standards. In these cases, the standards often represent<br />
minimal requirements that must be met by<br />
the endeavor and thus are an element in the constraints<br />
imposed on any design effort. The engineer<br />
must review all current standards related to<br />
a given endeavor and determine which must be<br />
met. Their designs must then incorporate any and<br />
all constraints imposed by the applicable standard.<br />
Standards important to software engineers<br />
are discussed in more detail in an appendix specifically<br />
on this subject.<br />
<br />
==Root Cause Analysis==<br />
{{RightSection|{{referenceLink|number=4|parts=c5, c3s7, c9s8}} {{referenceLink|number=5|parts=c9s3, c9s4, c9s5}} {{referenceLink|number=13|parts=c13s3.4.5}}}}<br />
<br />
Root cause analysis (RCA) is a process designed<br />
to investigate and identify why and how an<br />
undesirable event has happened. Root causes<br />
are underlying causes. The investigator should<br />
attempt to identify specific underlying causes of<br />
the event that has occurred. The primary objective of RCA is to prevent recurrence of the undesirable<br />
event. Thus, the more specific the investigator<br />
can be about why an event occurred, the easier<br />
it will be to prevent recurrence. A common way<br />
to identify specific underlying cause(s) is to ask a<br />
series of ''why'' questions.<br />
<br />
===Techniques for Conducting Root Cause Analysis===<br />
{{RightSection|{{referenceLink|number=4|parts=c5}} {{referenceLink|number=5|parts=c3}}}}<br />
<br />
There are many approaches used for both quality<br />
control and root cause analysis. The first step in<br />
any root cause analysis effort is to identify the real<br />
problem. Techniques such as statement-restatement,<br />
why-why diagrams, the revision method,<br />
present state and desired state diagrams, and the<br />
fresh-eye approach are used to identify and refine<br />
the real problem that needs to be addressed.<br />
<br />
Once the real problem has been identified, then<br />
work can begin to determine the cause of the<br />
problem. Ishikawa is known for the seven tools<br />
for quality control that he promoted. Some of<br />
those tools are helpful in identifying the causes<br />
for a given problem. Those tools are check sheets<br />
or checklists, Pareto diagrams, histograms, run<br />
charts, scatter diagrams, control charts, and<br />
fishbone or cause-and-effect diagrams. More<br />
recently, other approaches for quality improvement<br />
and root cause analysis have emerged. Some<br />
examples of these newer methods are affinity diagrams,<br />
relations diagrams, tree diagrams, matrix<br />
charts, matrix data analysis charts, process decision<br />
program charts, and arrow diagrams. A few<br />
of these techniques are briefly described below.<br />
<br />
A fishbone or cause-and-effect diagram is a<br />
way to visualize the various factors that affect<br />
some characteristic. The main line in the diagram<br />
represents the problem and the connecting lines<br />
represent the factors that led to or influenced the<br />
problem. Those factors are broken down into subfactors<br />
and sub-subfactors until root causes can<br />
be identified.<br />
<br />
A very simple approach that is useful in quality<br />
control is the use of a checklist. Checklists are<br />
a list of key points in a process with tasks that<br />
must be completed. As each task is completed,<br />
it is checked off the list. If a problem occurs,<br />
then sometimes the checklist can quickly identify<br />
tasks that may have been skipped or only partially<br />
completed.<br />
<br />
Finally, relations diagrams are a means for displaying<br />
complex relationships. They give visual<br />
support to cause-and-effect thinking. The diagram<br />
relates the specific to the general, revealing<br />
key causes and key effects.<br />
<br />
Root cause analysis aims at preventing the<br />
recurrence of undesirable events. Reduction of<br />
variation due to common causes requires utilization<br />
of a number of techniques. An important<br />
point to note is that these techniques should be<br />
used offline and not necessarily in direct response<br />
to the occurrence of some undesirable event.<br />
Some of the techniques that may be used to<br />
reduce variation due to common causes are given<br />
below.<br />
<br />
* 1. Cause-and-effect diagrams may be used to identify the sub and sub-sub causes.<br />
* 2. Fault tree analysis is a technique that may be used to understand the sources of failures.<br />
* 3. Designed experiments may be used to understand the impact of various causes on the occurrence of undesirable events (see Empirical<br />
Methods and Experimental Techniques in this KA).<br />
* 4. Various kinds of correlation analyses may be used to understand the relationship between various causes and their impact. These techniques may be used in cases when conducting controlled experiments is difficult but data may be gathered (see Statistical Analysis in this KA).<br />
<br />
{{EndSection|title=Futher Readings|body=<br />
A. Abran, ''Software Metrics and Software Metrology''. [14]<br />
<br />
This book provides very good information on the<br />
proper use of the terms measure, measurement<br />
method and measurement outcome. It provides<br />
strong support material for the entire section on<br />
Measurement.<br />
<br />
W.G. Vincenti, ''What Engineers Know and How They Know It''. [15]<br />
<br />
This book provides an interesting introduction<br />
to engineering foundations through a series<br />
of case studies that show many of the foundational<br />
concepts as used in real world engineering<br />
applications.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=IEEE<br />
|article=<br />
|publication=ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary, ISO/IEC/IEEE<br />
|edition=<br />
|publisher=ISO/IEC/IEEE<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=D.C. Montgomery and G.C. Runger<br />
|article=<br />
|publication=Applied Statistics and Probability for Engineers<br />
|edition=4th ed.<br />
|publisher=Wiley<br />
|issue=<br />
|date=2007<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=L. Null and J. Lobur<br />
|article=<br />
|publication=The Essentials of Computer Organization and Architecture<br />
|edition=2nd ed.<br />
|publisher=Jones and Bartlett Publishers<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=4<br />
|author=S.H. Kan<br />
|article=<br />
|publication=Metrics and Models in Software Quality Engineering<br />
|edition=2nd ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2002<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=G. Voland <br />
|article= <br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=7<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=7<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=8<br />
|author=Canadian Engineering Accreditation Board, Engineers Canada<br />
|article=Accreditation Criteria and Procedures<br />
|publication=<br />
|edition=<br />
|publisher=Canadian Council of Professional Engineers<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=www.engineerscanada.ca/files/w_Accreditation_Criteria_Procedures_2011.pdf<br />
}}<br />
{{reference<br />
|number=9<br />
|author=ABET Engineering Accreditation Commission<br />
|article=Criteria for Accrediting Engineering Programs, 2012-2013<br />
|publication=<br />
|edition=<br />
|publisher=ABET<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=www.abet.org/uploadedFiles/Accreditation/Accreditation_Process/Accreditation_Documents/Current/eaccriteria-2012-2013.pdf<br />
}}<br />
{{reference<br />
|number=10<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=E.W. Cheney and D.R. Kincaid<br />
|article=<br />
|publication=Numerical Mathematics and Computing<br />
|edition=<br />
|publisher=Brooks/Cole<br />
|issue=<br />
|date=2007<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=12<br />
|authorI. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=13<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=14<br />
|author=A. Abran<br />
|article=<br />
|publication=Software Metrics and Software Metrology<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=15<br />
|author=W.G. Vincenti<br />
|article=<br />
|publication=What Engineers Know and How They Know It<br />
|edition=<br />
|publisher=John Hopkins University Press<br />
|issue=<br />
|date=1990<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=847Chapter 15: Engineering Foundations2015-08-29T06:33:17Z<p>Daniel Robbins: /* Techniques for Conducting Root Cause Analysis */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any point on this line and a fixed interior point called the center is constant''. <br />
We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.<br />
<br />
The importance of operational definitions<br />
can hardly be overstated. Take the case of the<br />
apparently simple measurement of height of<br />
individuals. Unless we specify various factors<br />
like the time when the height will be measured<br />
(it is known that the height of individuals vary<br />
across various time points of the day), how the<br />
variability due to hair would be taken care of,<br />
whether the measurement will be with or without<br />
shoes, what kind of accuracy is expected (correct<br />
up to an inch, 1/2 inch, centimeter, etc.) — even this simple measurement will lead to substantial<br />
variation. Engineers must appreciate the need to<br />
define measures from an operational perspective.<br />
<br />
===Levels (Scales) of Measurement===<br />
{{RightSection| {{referenceLink|number=4|parts=c3s2}} {{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Once the operational definitions are determined,<br />
the actual measurements need to be undertaken.<br />
It is to be noted that measurement may be carried<br />
out in four different scales: namely, nominal,<br />
ordinal, interval, and ratio. Brief descriptions of<br />
each are given below.<br />
<br />
''Nominal scale'': This is the lowest level of measurement<br />
and represents the most unrestricted<br />
assignment of numerals. The numerals serve only<br />
as labels, and words or letters would serve as well.<br />
The nominal scale of measurement involves only<br />
classification and the observed sampling units<br />
are put into any one of the mutually exclusive<br />
and collectively exhaustive categories (classes).<br />
Some examples of nominal scales are:<br />
<br />
* Job titles in a company<br />
* The software development life cycle (SDLC) model (like waterfall, iterative, agile, etc.) followed by different software projects<br />
<br />
In nominal scale, the names of the different categories<br />
are just labels and no relationship between<br />
them is assumed. The only operations that can be<br />
carried out on nominal scale is that of counting<br />
the number of occurrences in the different classes<br />
and determining if two occurrences have the same<br />
nominal value. However, statistical analyses may<br />
be carried out to understand how entities belonging<br />
to different classes perform with respect to<br />
some other response variable.<br />
<br />
''Ordinal scale'': Refers to the measurement scale<br />
where the different values obtained through the<br />
process of measurement have an implicit ordering.<br />
The intervals between values are not specified<br />
and there is no objectively defined zero<br />
element. Typical examples of measurements in<br />
ordinal scales are:<br />
<br />
* Skill levels (low, medium, high)<br />
* Capability Maturity Model Integration (CMMI) maturity levels of software development organizations<br />
* Level of adherence to process as measured in a 5-point scale of excellent, above average, average, below average, and poor, indicating<br />
the range from total adherence to no adherence at all<br />
<br />
Measurement in ordinal scale satisfies the transitivity<br />
property in the sense that if A > B and B<br />
> C, then A > C. However, arithmetic operations<br />
cannot be carried out on variables measured in<br />
ordinal scales. Thus, if we measure customer satisfaction<br />
on a 5-point ordinal scale of 5 implying<br />
a very high level of satisfaction and 1 implying a<br />
very high level of dissatisfaction, we cannot say<br />
that a score of four is twice as good as a score<br />
of two. So, it is better to use terminology such<br />
as excellent, above average, average, below average,<br />
and poor than ordinal numbers in order to<br />
avoid the error of treating an ordinal scale as a<br />
ratio scale. It is important to note that ordinal<br />
scale measures are commonly misused and such<br />
misuse can lead to erroneous conclusions [6*,<br />
p274]. A common misuse of ordinal scale measures<br />
is to present a mean and standard deviation<br />
for the data set, both of which are meaningless.<br />
However, we can find the median, as computation<br />
of the median involves counting only.<br />
<br />
''Interval scales'': With the interval scale, we<br />
come to a form that is quantitative in the ordinary<br />
sense of the word. Almost all the usual statistical<br />
measures are applicable here, unless they<br />
require knowledge of a ''true' zero point. The zero<br />
point on an interval scale is a matter of convention.<br />
Ratios do not make sense, but the difference<br />
between levels of attributes can be computed and<br />
is meaningful. Some examples of interval scale of<br />
measurement follow:<br />
<br />
* Measurement of temperature in different scales, such as Celsius and Fahrenheit. Suppose T<sub>1</sub> and T<sub>2</sub> are temperatures measured in some scale. We note that the fact that T<sub>1</sub> is twice T<sub>2</sub> does not mean that one object is twice as hot as another. We also note that the zero points are arbitrary.<br />
* Calendar dates. While the difference between dates to measure the time elapsed is a meaningful concept, the ratio does not make sense.<br />
* Many psychological measurements aspire to create interval scales. Intelligence is often measured in interval scale, as it is not necessary to define what zero intelligence would mean.<br />
<br />
If a variable is measured in interval scale, most<br />
of the usual statistical analyses like mean, standard<br />
deviation, correlation, and regression may<br />
be carried out on the measured values.<br />
<br />
''Ratio scale'': These are quite commonly encountered<br />
in physical science. These scales of measures<br />
are characterized by the fact that operations<br />
exist for determining all 4 relations: equality, rank<br />
order, equality of intervals, and equality of ratios.<br />
Once such a scale is available, its numerical values<br />
can be transformed from one unit to another<br />
by just multiplying by a constant, e.g., conversion<br />
of inches to feet or centimeters. When measurements<br />
are being made in ratio scale, existence of<br />
a nonarbitrary zero is mandatory. All statistical<br />
measures are applicable to ratio scale; logarithm<br />
usage is valid only when these scales are used, as<br />
in the case of decibels. Some examples of ratio<br />
measures are<br />
<br />
* the number of statements in a software program<br />
* temperature measured in the Kelvin (K) scale or in Fahrenheit (F).<br />
<br />
An additional measurement scale, the absolute<br />
scale, is a ratio scale with uniqueness of the measure;<br />
i.e., a measure for which no transformation<br />
is possible (for example, the number of programmers<br />
working on a project).<br />
<br />
===Direct and Derived Measures===<br />
{{RightSection|{{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Measures may be either direct or derived (sometimes<br />
called indirect measures). An example of<br />
a direct measure would be a count of how many<br />
times an event occurred, such as the number of<br />
defects found in a software product. A derived<br />
measure is one that combines direct measures in<br />
some way that is consistent with the measurement<br />
method. An example of a derived measure would<br />
be calculating the productivity of a team as the<br />
number of lines of code developed per developermonth.<br />
In both cases, the measurement method<br />
determines how to make the measurement.<br />
<br />
===Reliability and Validity===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s4, c3s5}}}}<br />
<br />
A basic question to be asked for any measurement<br />
method is whether the proposed measurement<br />
method is truly measuring the concept with<br />
good quality. Reliability and validity are the two<br />
most important criteria to address this question.<br />
<br />
The reliability of a measurement method is<br />
the extent to which the application of the measurement<br />
method yields consistent measurement<br />
results. Essentially, ''reliability'' refers to the consistency<br />
of the values obtained when the same item<br />
is measured a number of times. When the results<br />
agree with each other, the measurement method<br />
is said to be reliable. Reliability usually depends<br />
on the operational definition. It can be quantified<br />
by using the index of variation, which is computed<br />
as the ratio between the standard deviation<br />
and the mean. The smaller the index, the more<br />
reliable the measurement results.<br />
<br />
''Validity'' refers to whether the measurement<br />
method really measures what we intend to measure.<br />
Validity of a measurement method may<br />
be looked at from three different perspectives:<br />
namely, construct validity, criteria validity, and<br />
content validity.<br />
<br />
===Assessing Reliability===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s5}}}}<br />
<br />
There are several methods for assessing reliability;<br />
these include the test-retest method, the<br />
alternative form method, the split-halves method,<br />
and the internal consistency method. The easiest<br />
of these is the test-retest method. In the testretest<br />
method, we simply apply the measurement<br />
method to the same subjects twice. The correlation<br />
coefficient between the first and second set<br />
of measurement results gives the reliability of the<br />
measurement method.<br />
<br />
==Engineering Design==<br />
{{RightSection|{{referenceLink|number=5|parts=c1s2, c1s3, c1s4}}}}<br />
<br />
A product’s life cycle costs are largely influenced<br />
by the design of the product. This is true for manufactured<br />
products as well as for software products.<br />
<br />
The design of a software product is guided by<br />
the features to be included and the quality attributes<br />
to be provided. It is important to note that<br />
software engineers use the term “design” within<br />
their own context; while there are some commonalities,<br />
there are also many differences between<br />
engineering design as discussed in this section<br />
and software engineering design as discussed in<br />
the Software Design KA. The scope of engineering<br />
design is generally viewed as much broader<br />
than that of software design. The primary aim of<br />
this section is to identify the concepts needed to<br />
develop a clear understanding regarding the process<br />
of engineering design.<br />
<br />
Many disciplines engage in problem solving<br />
activities where there is a single correct solution.<br />
In engineering, most problems have many<br />
solutions and the focus is on finding a feasible<br />
solution (among the many alternatives) that<br />
best meets the needs presented. The set of possible<br />
solutions is often constrained by explicitly<br />
imposed limitations such as cost, available<br />
resources, and the state of discipline or domain<br />
knowledge. In engineering problems, sometimes<br />
there are also implicit constraints (such as the<br />
physical properties of materials or laws of physics)<br />
that also restrict the set of feasible solutions<br />
for a given problem.<br />
<br />
===Engineering Design in Engineering Education===<br />
<br />
The importance of engineering design in engineering<br />
education can be clearly seen by the high<br />
expectations held by various accreditation bodies<br />
for engineering education. Both the Canadian<br />
Engineering Accreditation Board and the<br />
Accreditation Board for Engineering and Technology<br />
(ABET) note the importance of including<br />
engineering design in education programs.<br />
<br />
The Canadian Engineering Accreditation<br />
Board includes requirements for the amount of<br />
engineering design experience/coursework that<br />
is necessary for engineering students as well as<br />
qualifications for the faculty members who teach<br />
such coursework or supervise design projects.<br />
Their accreditation criteria states:<br />
<br />
* Design: An ability to design solutions for complex, open-ended engineering problems and to design systems, components or processes that meet specified needs with appropriate attention to health and safety risks, applicable standards, and economic, environmental, cultural and societal considerations. [8, p12]<br />
<br />
In a similar manner, ABET defines engineering<br />
design as<br />
<br />
* the process of devising a system, component, or process to meet desired needs. It is a decision-making process (often iterative), in which the basic sciences, mathematics, and the engineering sciences are applied to convert resources optimally to meet these stated needs. [9, p4]<br />
<br />
Thus, it is clear that engineering design is a<br />
vital component in the training and education for<br />
all engineers. The remainder of this section will<br />
focus on various aspects of engineering design.<br />
<br />
===Design as a Problem Solving Activity===<br />
{{RightSection|{{referenceLink|number=5|parts=c1s4, c2s1, c3s3}}}}<br />
<br />
It is to be noted that engineering design is primarily<br />
a problem solving activity. Design problems<br />
are open ended and more vaguely defined. There<br />
are usually several alternative ways to solve the<br />
same problem. Design is generally considered to<br />
be a ''wicked problem'' —a term first coined by Horst<br />
Rittel in the 1960s when design methods were a<br />
subject of intense interest. Rittel sought an alternative<br />
to the linear, step-by-step model of the design<br />
process being explored by many designers and<br />
design theorists and argued that most of the problems<br />
addressed by the designers are wicked problems.<br />
As explained by Steve McConnell, a wicked<br />
problem is one that could be clearly defined only<br />
by solving it or by solving part of it. This paradox<br />
implies, essentially, that a wicked problem has to<br />
be solved once in order to define it clearly and then<br />
solved again to create a solution that works. This<br />
has been an important insight for software designers<br />
for several decades [10*, c5s1].<br />
<br />
===Steps Involved in Engineering Design===<br />
{{RightSection|{{referenceLink|number=7|parts=c4}}}}<br />
<br />
Engineering problem solving begins when a<br />
need is recognized and no existing solution will<br />
meet that need. As part of this problem solving,<br />
the design goals to be achieved by the solution<br />
should be identified. Additionally, a set of acceptance<br />
criteria must be defined and used to determine<br />
how well a proposed solution will satisfy<br />
the need. Once a need for a solution to a problem<br />
has been identified, the process of engineering<br />
design has the following generic steps:<br />
<br />
* a) define the problem<br />
* b) gather pertinent information<br />
* c) generate multiple solutions<br />
* d) analyze and select a solution<br />
* e) implement the solution<br />
<br />
All of the engineering design steps are iterative,<br />
and knowledge gained at any step in the<br />
process may be used to inform earlier tasks and<br />
trigger an iteration in the process. These steps are<br />
expanded in the subsequent sections<br />
<br />
''a''. ''Define the problem''. <br />
<br />
At this stage, the customer’s<br />
requirements are gathered. Specific information<br />
about product functions and features are also<br />
closely examined. This step includes refining the<br />
problem statement to identify the real problem to<br />
be solved and setting the design goals and criteria<br />
for success.<br />
<br />
The problem definition is a crucial stage in<br />
engineering design. A point to note is that this<br />
step is deceptively simple. Thus, enough care<br />
must be taken to carry out this step judiciously. It<br />
is important to identify needs and link the success<br />
criteria with the required product characteristics.<br />
It is also an engineering task to limit the scope<br />
of a problem and its solution through negotiation<br />
among the stakeholders.<br />
<br />
''b''. ''Gather pertinent information''.<br />
<br />
At this stage,<br />
the designer attempts to expand his/her knowledge<br />
about the problem. This is a vital, yet often<br />
neglected, stage. Gathering pertinent information<br />
can reveal facts leading to a redefinition of the problem—in particular, mistakes and false starts<br />
may be identified. This step may also involve the<br />
decomposition of the problem into smaller, more<br />
easily solved subproblems.<br />
<br />
While gathering pertinent information, care<br />
must be taken to identify how a product may be<br />
used as well as misused. It is also important to<br />
understand the perceived value of the product/<br />
service being offered. Included in the pertinent<br />
information is a list of constraints that must be<br />
satisfied by the solution or that may limit the set<br />
of feasible solutions.<br />
<br />
''c''. ''Generate multiple solutions''.<br />
<br />
During this stage,<br />
different solutions to the same problem are developed.<br />
It has already been stated that design problems<br />
have multiple solutions. The goal of this<br />
step is to conceptualize multiple possible solutions<br />
and refine them to a sufficient level of detail<br />
that a comparison can be done among them.<br />
<br />
''d''. ''Analyze and select a solution''.<br />
<br />
Once alternative<br />
solutions have been identified, they need to be analyzed<br />
to identify the solution that best suits the current<br />
situation. The analysis includes a functional<br />
analysis to assess whether the proposed design<br />
would meet the functional requirements. Physical<br />
solutions that involve human users often include<br />
analysis of the ergonomics or user friendliness of<br />
the proposed solution. Other aspects of the solution—<br />
such as product safety and liability, an economic<br />
or market analysis to ensure a return (profit)<br />
on the solution, performance predictions and analysis<br />
to meet quality characteristics, opportunities<br />
for incorrect data input or hardware malfunctions,<br />
and so on—may be studied. The types and amount<br />
of analysis used on a proposed solution are dependent<br />
on the type of problem and the needs that the<br />
solution must address as well as the constraints<br />
imposed on the design.<br />
<br />
''e''. ''Implement the solution''.<br />
<br />
The final phase of the<br />
design process is implementation. Implementation<br />
refers to development and testing of the<br />
proposed solution. Sometimes a preliminary,<br />
partial solution called a ''prototype'' may be developed<br />
initially to test the proposed design solution<br />
under certain conditions. Feedback resulting<br />
from testing a prototype may be used either to refine the design or drive the selection of an alternative<br />
design solution. One of the most important<br />
activities in design is documentation of the<br />
design solution as well as of the tradeoffs for the<br />
choices made in the design of the solution. This<br />
work should be carried out in a manner such that<br />
the solution to the design problem can be communicated<br />
clearly to others.<br />
<br />
The testing and verification take us back to the<br />
success criteria. The engineer needs to devise<br />
tests such that the ability of the design to meet the<br />
success criteria is demonstrated. While designing<br />
the tests, the engineer must think through<br />
different possible failure modes and then design<br />
tests based on those failure modes. The engineer<br />
may choose to carry out designed experiments to<br />
assess the validity of the design.<br />
<br />
==Modeling, Simulation, and Prototyping==<br />
{{RightSection|{{referenceLink|number=5|parts=c6}} {{referenceLink|number=11|parts=c13s3}} {{referenceLink|number=12|parts=c2s3.1}}}}<br />
<br />
Modeling is part of the abstraction process used<br />
to represent some aspects of a system. Simulation<br />
uses a model of the system and provides a<br />
means of conducting designed experiments with<br />
that model to better understand the system, its<br />
behavior, and relationships between subsystems,<br />
as well as to analyze aspects of the design. Modeling<br />
and simulation are techniques that can be<br />
used to construct theories or hypotheses about the<br />
behavior of the system; engineers then use those<br />
theories to make predictions about the system.<br />
Prototyping is another abstraction process where<br />
a partial representation (that captures aspects of<br />
interest) of the product or system is built. A prototype<br />
may be an initial version of the system but<br />
lacks the full functionality of the final version.<br />
<br />
===Modeling===<br />
<br />
A model is always an abstraction of some real<br />
or imagined artifact. Engineers use models in<br />
many ways as part of their problem solving<br />
activities. Some models are physical, such as a<br />
made-to-scale miniature construction of a bridge<br />
or building. Other models may be nonphysical<br />
representations, such as a CAD drawing of a cog<br />
or a mathematical model for a process. Models<br />
help engineers reason and understand aspects of a problem. They can also help engineers understand<br />
what they do know and what they don’t<br />
know about the problem at hand.<br />
<br />
There are three types of models: iconic, analogic,<br />
and symbolic. An iconic model is a visually<br />
equivalent but incomplete 2-dimensional<br />
or 3-dimensional representation—for example,<br />
maps, globes, or built-to-scale models of structures<br />
such as bridges or highways. An iconic<br />
model actually resembles the artifact modeled.<br />
<br />
In contrast, an analogic model is a functionally<br />
equivalent but incomplete representation. That<br />
is, the model behaves like the physical artifact<br />
even though it may not physically resemble it.<br />
Examples of analogic models include a miniature<br />
airplane for wind tunnel testing or a computer<br />
simulation of a manufacturing process.<br />
<br />
Finally, a symbolic model is a higher level of<br />
abstraction, where the model is represented using<br />
symbols such as equations. The model captures<br />
the relevant aspects of the process or system in<br />
symbolic form. The symbols can then be used to<br />
increase the engineer’s understanding of the final<br />
system. An example is an equation such as F = Ma. Such mathematical models can be used to<br />
describe and predict properties or behavior of the<br />
final system or product.<br />
<br />
===Simulation===<br />
<br />
All simulation models are a specification of reality.<br />
A central issue in simulation is to abstract<br />
and specify an appropriate simplification of<br />
reality. Developing this abstraction is of vital<br />
importance, as misspecification of the abstraction<br />
would invalidate the results of the simulation<br />
exercise. Simulation can be used for a variety of<br />
testing purposes.<br />
<br />
Simulation is classified based on the type of<br />
system under study. Thus, simulation can be either<br />
continuous or discrete. In the context of software<br />
engineering, the emphasis will be primarily on<br />
discrete simulation. Discrete simulations may<br />
model event scheduling or process interaction.<br />
The main components in such a model include<br />
entities, activities and events, resources, the state<br />
of the system, a simulation clock, and a random<br />
number generator. Output is generated by the<br />
simulation and must be analyzed.<br />
<br />
An important problem in the development of a<br />
discrete simulation is that of initialization. Before<br />
a simulation can be run, the initial values of all<br />
the state variables must be provided. As the simulation<br />
designer may not know what initial values<br />
are appropriate for the state variables, these values<br />
might be chosen somewhat arbitrarily. For<br />
instance, it might be decided that a queue should<br />
be initialized as empty and idle. Such a choice of<br />
initial condition can have a significant but unrecognized<br />
impact on the outcome of the simulation.<br />
<br />
===Prototyping===<br />
<br />
Constructing a prototype of a system is another<br />
abstraction process. In this case, an initial version<br />
of the system is constructed, often while the system<br />
is being designed. This helps the designers<br />
determine the feasibility of their design.<br />
<br />
There are many uses for a prototype, including<br />
the elicitation of requirements, the design and<br />
refinement of a user interface to the system, validation<br />
of functional requirements, and so on. The<br />
objectives and purposes for building the prototype<br />
will determine its construction and the level<br />
of abstraction used.<br />
<br />
The role of prototyping is somewhat different<br />
between physical systems and software. With<br />
physical systems, the prototype may actually<br />
be the first fully functional version of a system<br />
or it may be a model of the system. In software<br />
engineering, prototypes are also an abstract<br />
model of part of the software but are usually not<br />
constructed with all of the architectural, performance,<br />
and other quality characteristics expected<br />
in the finished product. In either case, prototype<br />
construction must have a clear purpose and be<br />
planned, monitored, and controlled—it is a technique<br />
to study a specific problem within a limited<br />
context [6*, c2s8].<br />
<br />
In conclusion, modeling, simulation, and prototyping<br />
are powerful techniques for studying the<br />
behavior of a system from a given perspective.<br />
All can be used to perform designed experiments<br />
to study various aspects of the system. However,<br />
these are abstractions and, as such, may not<br />
model all attributes of interest.<br />
<br />
==Standards==<br />
{{RightSection|{{referenceLink|number=5|parts=c9s3.2}} {{referenceLink|number=13|parts=c1s2}}}}<br />
<br />
Moore states that a<br />
<br />
* standard can be;<br />
** (a) an object or measure of comparison that defines or represents the magnitude of a unit;<br />
** (b) a characterization that establishes allowable tolerances for categories of items;<br />
** and (c) a degree or level of required excellence or attainment.<br />
* Standards are definitional in nature, established either to further understanding and interaction or to acknowledge observed (or<br />
desired) norms of exhibited characteristics or behavior. [13*, p8]<br />
<br />
Standards provide requirements, specifications,<br />
guidelines, or characteristics that must be<br />
observed by engineers so that the products, processes,<br />
and materials have acceptable levels of<br />
quality. The qualities that various standards provide<br />
may be those of safety, reliability, or other<br />
product characteristics. Standards are considered<br />
critical to engineers and engineers are expected to<br />
be familiar with and to use the appropriate standards<br />
in their discipline.<br />
<br />
Compliance or conformance to a standard lets<br />
an organization say to the public that they (or<br />
their products) meet the requirements stated in<br />
that standard. Thus, standards divide organizations<br />
or their products into those that conform to<br />
the standard and those that do not. For a standard<br />
to be useful, conformance with the standard must<br />
add value—real or perceived—to the product,<br />
process, or effort.<br />
<br />
Apart from the organizational goals, standards<br />
are used for a number of other purposes such<br />
as protecting the buyer, protecting the business,<br />
and better defining the methods and procedures<br />
to be followed by the practice. Standards also<br />
provide users with a common terminology and<br />
expectations.<br />
<br />
There are many internationally recognized<br />
standards-making organizations including the<br />
International Telecommunications Union (ITU),<br />
the International Electrotechnical Commission<br />
(IEC), IEEE, and the International Organization<br />
for Standardization (ISO). In addition, there are regional and governmentally recognized organizations<br />
that generate standards for that region or<br />
country. For example, in the United States, there<br />
are over 300 organizations that develop standards.<br />
These include organizations such as the<br />
American National Standards Institute (ANSI),<br />
the American Society for Testing and Materials<br />
(ASTM), the Society of Automotive Engineers<br />
(SAE), and Underwriters Laboratories, Inc. (UL),<br />
as well as the US government. For more detail<br />
on standards used in software engineering, see<br />
Appendix B on standards.<br />
<br />
There is a set of commonly used principles<br />
behind standards. Standards makers attempt to<br />
have consensus around their decisions. There is<br />
usually an openness within the community of<br />
interest so that once a standard has been set, there<br />
is a good chance that it will be widely accepted.<br />
Most standards organizations have well-defined<br />
processes for their efforts and adhere to those<br />
processes carefully. Engineers must be aware of<br />
the existing standards but must also update their<br />
understanding of the standards as those standards<br />
change over time.<br />
<br />
In many engineering endeavors, knowing and<br />
understanding the applicable standards is critical<br />
and the law may even require use of particular<br />
standards. In these cases, the standards often represent<br />
minimal requirements that must be met by<br />
the endeavor and thus are an element in the constraints<br />
imposed on any design effort. The engineer<br />
must review all current standards related to<br />
a given endeavor and determine which must be<br />
met. Their designs must then incorporate any and<br />
all constraints imposed by the applicable standard.<br />
Standards important to software engineers<br />
are discussed in more detail in an appendix specifically<br />
on this subject.<br />
<br />
==Root Cause Analysis==<br />
{{RightSection|{{referenceLink|number=4|parts=c5, c3s7, c9s8}} {{referenceLink|number=5|parts=c9s3, c9s4, c9s5}} {{referenceLink|number=13|parts=c13s3.4.5}}}}<br />
<br />
Root cause analysis (RCA) is a process designed<br />
to investigate and identify why and how an<br />
undesirable event has happened. Root causes<br />
are underlying causes. The investigator should<br />
attempt to identify specific underlying causes of<br />
the event that has occurred. The primary objective of RCA is to prevent recurrence of the undesirable<br />
event. Thus, the more specific the investigator<br />
can be about why an event occurred, the easier<br />
it will be to prevent recurrence. A common way<br />
to identify specific underlying cause(s) is to ask a<br />
series of ''why'' questions.<br />
<br />
===Techniques for Conducting Root Cause Analysis===<br />
{{RightSection|{{referenceLink|number=4|parts=c5}} {{referenceLink|number=5|parts=c3}}}}<br />
<br />
There are many approaches used for both quality<br />
control and root cause analysis. The first step in<br />
any root cause analysis effort is to identify the real<br />
problem. Techniques such as statement-restatement,<br />
why-why diagrams, the revision method,<br />
present state and desired state diagrams, and the<br />
fresh-eye approach are used to identify and refine<br />
the real problem that needs to be addressed.<br />
<br />
Once the real problem has been identified, then<br />
work can begin to determine the cause of the<br />
problem. Ishikawa is known for the seven tools<br />
for quality control that he promoted. Some of<br />
those tools are helpful in identifying the causes<br />
for a given problem. Those tools are check sheets<br />
or checklists, Pareto diagrams, histograms, run<br />
charts, scatter diagrams, control charts, and<br />
fishbone or cause-and-effect diagrams. More<br />
recently, other approaches for quality improvement<br />
and root cause analysis have emerged. Some<br />
examples of these newer methods are affinity diagrams,<br />
relations diagrams, tree diagrams, matrix<br />
charts, matrix data analysis charts, process decision<br />
program charts, and arrow diagrams. A few<br />
of these techniques are briefly described below.<br />
<br />
A fishbone or cause-and-effect diagram is a<br />
way to visualize the various factors that affect<br />
some characteristic. The main line in the diagram<br />
represents the problem and the connecting lines<br />
represent the factors that led to or influenced the<br />
problem. Those factors are broken down into subfactors<br />
and sub-subfactors until root causes can<br />
be identified.<br />
<br />
A very simple approach that is useful in quality<br />
control is the use of a checklist. Checklists are<br />
a list of key points in a process with tasks that<br />
must be completed. As each task is completed,<br />
it is checked off the list. If a problem occurs,<br />
then sometimes the checklist can quickly identify<br />
tasks that may have been skipped or only partially<br />
completed.<br />
<br />
Finally, relations diagrams are a means for displaying<br />
complex relationships. They give visual<br />
support to cause-and-effect thinking. The diagram<br />
relates the specific to the general, revealing<br />
key causes and key effects.<br />
<br />
Root cause analysis aims at preventing the<br />
recurrence of undesirable events. Reduction of<br />
variation due to common causes requires utilization<br />
of a number of techniques. An important<br />
point to note is that these techniques should be<br />
used offline and not necessarily in direct response<br />
to the occurrence of some undesirable event.<br />
Some of the techniques that may be used to<br />
reduce variation due to common causes are given<br />
below.<br />
<br />
* 1. Cause-and-effect diagrams may be used to identify the sub and sub-sub causes.<br />
* 2. Fault tree analysis is a technique that may be used to understand the sources of failures.<br />
* 3. Designed experiments may be used to understand the impact of various causes on the occurrence of undesirable events (see Empirical<br />
Methods and Experimental Techniques in this KA).<br />
* 4. Various kinds of correlation analyses may be used to understand the relationship between various causes and their impact. These techniques may be used in cases when conducting controlled experiments is difficult but data may be gathered (see Statistical Analysis in this KA).<br />
<br />
{{EndSection|title=Futher Readings|body=<br />
A. Abran, ''Software Metrics and Software Metrology''. [14]<br />
<br />
This book provides very good information on the<br />
proper use of the terms measure, measurement<br />
method and measurement outcome. It provides<br />
strong support material for the entire section on<br />
Measurement.<br />
<br />
W.G. Vincenti, ''What Engineers Know and How They Know It''. [15]<br />
<br />
This book provides an interesting introduction<br />
to engineering foundations through a series<br />
of case studies that show many of the foundational<br />
concepts as used in real world engineering<br />
applications.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=IEEE<br />
|article=<br />
|publication=ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary, ISO/IEC/IEEE<br />
|edition=<br />
|publisher=ISO/IEC/IEEE<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=D.C. Montgomery and G.C. Runger<br />
|article=<br />
|publication=Applied Statistics and Probability for Engineers<br />
|edition=4th ed.<br />
|publisher=Wiley<br />
|issue=<br />
|date=2007<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=L. Null and J. Lobur<br />
|article=<br />
|publication=The Essentials of Computer Organization and Architecture<br />
|edition=2nd ed.<br />
|publisher=Jones and Bartlett Publishers<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=4<br />
|author=S.H. Kan<br />
|article=<br />
|publication=Metrics and Models in Software Quality Engineering<br />
|edition=2nd ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2002<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=G. Voland <br />
|article= <br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=7<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=7<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=8<br />
|author=Canadian Engineering Accreditation Board, Engineers Canada<br />
|article=“Accreditation Criteria and Procedures”<br />
|publication=<br />
|edition=<br />
|publisher=Canadian Council of Professional Engineers<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=www.engineerscanada.ca/files/w_Accreditation_Criteria_Procedures_2011.pdf<br />
}}<br />
{{reference<br />
|number=9<br />
|author=ABET Engineering Accreditation Commission<br />
|article=Criteria for Accrediting Engineering Programs, 2012-2013<br />
|publication=<br />
|edition=<br />
|publisher=ABET<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=www.abet.org/uploadedFiles/Accreditation/Accreditation_Process/Accreditation_Documents/Current/eaccriteria-2012-2013.pdf<br />
}}<br />
{{reference<br />
|number=10<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=E.W. Cheney and D.R. Kincaid<br />
|article=<br />
|publication=Numerical Mathematics and Computing<br />
|edition=<br />
|publisher=Brooks/Cole<br />
|issue=<br />
|date=2007<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=12<br />
|authorI. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=13<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=14<br />
|author=A. Abran<br />
|article=<br />
|publication=Software Metrics and Software Metrology<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=15<br />
|author=W.G. Vincenti<br />
|article=<br />
|publication=What Engineers Know and How They Know It<br />
|edition=<br />
|publisher=John Hopkins University Press<br />
|issue=<br />
|date=1990<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=846Chapter 15: Engineering Foundations2015-08-29T06:32:12Z<p>Daniel Robbins: /* Techniques for Conducting Root Cause Analysis */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any point on this line and a fixed interior point called the center is constant''. <br />
We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.<br />
<br />
The importance of operational definitions<br />
can hardly be overstated. Take the case of the<br />
apparently simple measurement of height of<br />
individuals. Unless we specify various factors<br />
like the time when the height will be measured<br />
(it is known that the height of individuals vary<br />
across various time points of the day), how the<br />
variability due to hair would be taken care of,<br />
whether the measurement will be with or without<br />
shoes, what kind of accuracy is expected (correct<br />
up to an inch, 1/2 inch, centimeter, etc.) — even this simple measurement will lead to substantial<br />
variation. Engineers must appreciate the need to<br />
define measures from an operational perspective.<br />
<br />
===Levels (Scales) of Measurement===<br />
{{RightSection| {{referenceLink|number=4|parts=c3s2}} {{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Once the operational definitions are determined,<br />
the actual measurements need to be undertaken.<br />
It is to be noted that measurement may be carried<br />
out in four different scales: namely, nominal,<br />
ordinal, interval, and ratio. Brief descriptions of<br />
each are given below.<br />
<br />
''Nominal scale'': This is the lowest level of measurement<br />
and represents the most unrestricted<br />
assignment of numerals. The numerals serve only<br />
as labels, and words or letters would serve as well.<br />
The nominal scale of measurement involves only<br />
classification and the observed sampling units<br />
are put into any one of the mutually exclusive<br />
and collectively exhaustive categories (classes).<br />
Some examples of nominal scales are:<br />
<br />
* Job titles in a company<br />
* The software development life cycle (SDLC) model (like waterfall, iterative, agile, etc.) followed by different software projects<br />
<br />
In nominal scale, the names of the different categories<br />
are just labels and no relationship between<br />
them is assumed. The only operations that can be<br />
carried out on nominal scale is that of counting<br />
the number of occurrences in the different classes<br />
and determining if two occurrences have the same<br />
nominal value. However, statistical analyses may<br />
be carried out to understand how entities belonging<br />
to different classes perform with respect to<br />
some other response variable.<br />
<br />
''Ordinal scale'': Refers to the measurement scale<br />
where the different values obtained through the<br />
process of measurement have an implicit ordering.<br />
The intervals between values are not specified<br />
and there is no objectively defined zero<br />
element. Typical examples of measurements in<br />
ordinal scales are:<br />
<br />
* Skill levels (low, medium, high)<br />
* Capability Maturity Model Integration (CMMI) maturity levels of software development organizations<br />
* Level of adherence to process as measured in a 5-point scale of excellent, above average, average, below average, and poor, indicating<br />
the range from total adherence to no adherence at all<br />
<br />
Measurement in ordinal scale satisfies the transitivity<br />
property in the sense that if A > B and B<br />
> C, then A > C. However, arithmetic operations<br />
cannot be carried out on variables measured in<br />
ordinal scales. Thus, if we measure customer satisfaction<br />
on a 5-point ordinal scale of 5 implying<br />
a very high level of satisfaction and 1 implying a<br />
very high level of dissatisfaction, we cannot say<br />
that a score of four is twice as good as a score<br />
of two. So, it is better to use terminology such<br />
as excellent, above average, average, below average,<br />
and poor than ordinal numbers in order to<br />
avoid the error of treating an ordinal scale as a<br />
ratio scale. It is important to note that ordinal<br />
scale measures are commonly misused and such<br />
misuse can lead to erroneous conclusions [6*,<br />
p274]. A common misuse of ordinal scale measures<br />
is to present a mean and standard deviation<br />
for the data set, both of which are meaningless.<br />
However, we can find the median, as computation<br />
of the median involves counting only.<br />
<br />
''Interval scales'': With the interval scale, we<br />
come to a form that is quantitative in the ordinary<br />
sense of the word. Almost all the usual statistical<br />
measures are applicable here, unless they<br />
require knowledge of a ''true' zero point. The zero<br />
point on an interval scale is a matter of convention.<br />
Ratios do not make sense, but the difference<br />
between levels of attributes can be computed and<br />
is meaningful. Some examples of interval scale of<br />
measurement follow:<br />
<br />
* Measurement of temperature in different scales, such as Celsius and Fahrenheit. Suppose T<sub>1</sub> and T<sub>2</sub> are temperatures measured in some scale. We note that the fact that T<sub>1</sub> is twice T<sub>2</sub> does not mean that one object is twice as hot as another. We also note that the zero points are arbitrary.<br />
* Calendar dates. While the difference between dates to measure the time elapsed is a meaningful concept, the ratio does not make sense.<br />
* Many psychological measurements aspire to create interval scales. Intelligence is often measured in interval scale, as it is not necessary to define what zero intelligence would mean.<br />
<br />
If a variable is measured in interval scale, most<br />
of the usual statistical analyses like mean, standard<br />
deviation, correlation, and regression may<br />
be carried out on the measured values.<br />
<br />
''Ratio scale'': These are quite commonly encountered<br />
in physical science. These scales of measures<br />
are characterized by the fact that operations<br />
exist for determining all 4 relations: equality, rank<br />
order, equality of intervals, and equality of ratios.<br />
Once such a scale is available, its numerical values<br />
can be transformed from one unit to another<br />
by just multiplying by a constant, e.g., conversion<br />
of inches to feet or centimeters. When measurements<br />
are being made in ratio scale, existence of<br />
a nonarbitrary zero is mandatory. All statistical<br />
measures are applicable to ratio scale; logarithm<br />
usage is valid only when these scales are used, as<br />
in the case of decibels. Some examples of ratio<br />
measures are<br />
<br />
* the number of statements in a software program<br />
* temperature measured in the Kelvin (K) scale or in Fahrenheit (F).<br />
<br />
An additional measurement scale, the absolute<br />
scale, is a ratio scale with uniqueness of the measure;<br />
i.e., a measure for which no transformation<br />
is possible (for example, the number of programmers<br />
working on a project).<br />
<br />
===Direct and Derived Measures===<br />
{{RightSection|{{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Measures may be either direct or derived (sometimes<br />
called indirect measures). An example of<br />
a direct measure would be a count of how many<br />
times an event occurred, such as the number of<br />
defects found in a software product. A derived<br />
measure is one that combines direct measures in<br />
some way that is consistent with the measurement<br />
method. An example of a derived measure would<br />
be calculating the productivity of a team as the<br />
number of lines of code developed per developermonth.<br />
In both cases, the measurement method<br />
determines how to make the measurement.<br />
<br />
===Reliability and Validity===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s4, c3s5}}}}<br />
<br />
A basic question to be asked for any measurement<br />
method is whether the proposed measurement<br />
method is truly measuring the concept with<br />
good quality. Reliability and validity are the two<br />
most important criteria to address this question.<br />
<br />
The reliability of a measurement method is<br />
the extent to which the application of the measurement<br />
method yields consistent measurement<br />
results. Essentially, ''reliability'' refers to the consistency<br />
of the values obtained when the same item<br />
is measured a number of times. When the results<br />
agree with each other, the measurement method<br />
is said to be reliable. Reliability usually depends<br />
on the operational definition. It can be quantified<br />
by using the index of variation, which is computed<br />
as the ratio between the standard deviation<br />
and the mean. The smaller the index, the more<br />
reliable the measurement results.<br />
<br />
''Validity'' refers to whether the measurement<br />
method really measures what we intend to measure.<br />
Validity of a measurement method may<br />
be looked at from three different perspectives:<br />
namely, construct validity, criteria validity, and<br />
content validity.<br />
<br />
===Assessing Reliability===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s5}}}}<br />
<br />
There are several methods for assessing reliability;<br />
these include the test-retest method, the<br />
alternative form method, the split-halves method,<br />
and the internal consistency method. The easiest<br />
of these is the test-retest method. In the testretest<br />
method, we simply apply the measurement<br />
method to the same subjects twice. The correlation<br />
coefficient between the first and second set<br />
of measurement results gives the reliability of the<br />
measurement method.<br />
<br />
==Engineering Design==<br />
{{RightSection|{{referenceLink|number=5|parts=c1s2, c1s3, c1s4}}}}<br />
<br />
A product’s life cycle costs are largely influenced<br />
by the design of the product. This is true for manufactured<br />
products as well as for software products.<br />
<br />
The design of a software product is guided by<br />
the features to be included and the quality attributes<br />
to be provided. It is important to note that<br />
software engineers use the term “design” within<br />
their own context; while there are some commonalities,<br />
there are also many differences between<br />
engineering design as discussed in this section<br />
and software engineering design as discussed in<br />
the Software Design KA. The scope of engineering<br />
design is generally viewed as much broader<br />
than that of software design. The primary aim of<br />
this section is to identify the concepts needed to<br />
develop a clear understanding regarding the process<br />
of engineering design.<br />
<br />
Many disciplines engage in problem solving<br />
activities where there is a single correct solution.<br />
In engineering, most problems have many<br />
solutions and the focus is on finding a feasible<br />
solution (among the many alternatives) that<br />
best meets the needs presented. The set of possible<br />
solutions is often constrained by explicitly<br />
imposed limitations such as cost, available<br />
resources, and the state of discipline or domain<br />
knowledge. In engineering problems, sometimes<br />
there are also implicit constraints (such as the<br />
physical properties of materials or laws of physics)<br />
that also restrict the set of feasible solutions<br />
for a given problem.<br />
<br />
===Engineering Design in Engineering Education===<br />
<br />
The importance of engineering design in engineering<br />
education can be clearly seen by the high<br />
expectations held by various accreditation bodies<br />
for engineering education. Both the Canadian<br />
Engineering Accreditation Board and the<br />
Accreditation Board for Engineering and Technology<br />
(ABET) note the importance of including<br />
engineering design in education programs.<br />
<br />
The Canadian Engineering Accreditation<br />
Board includes requirements for the amount of<br />
engineering design experience/coursework that<br />
is necessary for engineering students as well as<br />
qualifications for the faculty members who teach<br />
such coursework or supervise design projects.<br />
Their accreditation criteria states:<br />
<br />
* Design: An ability to design solutions for complex, open-ended engineering problems and to design systems, components or processes that meet specified needs with appropriate attention to health and safety risks, applicable standards, and economic, environmental, cultural and societal considerations. [8, p12]<br />
<br />
In a similar manner, ABET defines engineering<br />
design as<br />
<br />
* the process of devising a system, component, or process to meet desired needs. It is a decision-making process (often iterative), in which the basic sciences, mathematics, and the engineering sciences are applied to convert resources optimally to meet these stated needs. [9, p4]<br />
<br />
Thus, it is clear that engineering design is a<br />
vital component in the training and education for<br />
all engineers. The remainder of this section will<br />
focus on various aspects of engineering design.<br />
<br />
===Design as a Problem Solving Activity===<br />
{{RightSection|{{referenceLink|number=5|parts=c1s4, c2s1, c3s3}}}}<br />
<br />
It is to be noted that engineering design is primarily<br />
a problem solving activity. Design problems<br />
are open ended and more vaguely defined. There<br />
are usually several alternative ways to solve the<br />
same problem. Design is generally considered to<br />
be a ''wicked problem'' —a term first coined by Horst<br />
Rittel in the 1960s when design methods were a<br />
subject of intense interest. Rittel sought an alternative<br />
to the linear, step-by-step model of the design<br />
process being explored by many designers and<br />
design theorists and argued that most of the problems<br />
addressed by the designers are wicked problems.<br />
As explained by Steve McConnell, a wicked<br />
problem is one that could be clearly defined only<br />
by solving it or by solving part of it. This paradox<br />
implies, essentially, that a wicked problem has to<br />
be solved once in order to define it clearly and then<br />
solved again to create a solution that works. This<br />
has been an important insight for software designers<br />
for several decades [10*, c5s1].<br />
<br />
===Steps Involved in Engineering Design===<br />
{{RightSection|{{referenceLink|number=7|parts=c4}}}}<br />
<br />
Engineering problem solving begins when a<br />
need is recognized and no existing solution will<br />
meet that need. As part of this problem solving,<br />
the design goals to be achieved by the solution<br />
should be identified. Additionally, a set of acceptance<br />
criteria must be defined and used to determine<br />
how well a proposed solution will satisfy<br />
the need. Once a need for a solution to a problem<br />
has been identified, the process of engineering<br />
design has the following generic steps:<br />
<br />
* a) define the problem<br />
* b) gather pertinent information<br />
* c) generate multiple solutions<br />
* d) analyze and select a solution<br />
* e) implement the solution<br />
<br />
All of the engineering design steps are iterative,<br />
and knowledge gained at any step in the<br />
process may be used to inform earlier tasks and<br />
trigger an iteration in the process. These steps are<br />
expanded in the subsequent sections<br />
<br />
''a''. ''Define the problem''. <br />
<br />
At this stage, the customer’s<br />
requirements are gathered. Specific information<br />
about product functions and features are also<br />
closely examined. This step includes refining the<br />
problem statement to identify the real problem to<br />
be solved and setting the design goals and criteria<br />
for success.<br />
<br />
The problem definition is a crucial stage in<br />
engineering design. A point to note is that this<br />
step is deceptively simple. Thus, enough care<br />
must be taken to carry out this step judiciously. It<br />
is important to identify needs and link the success<br />
criteria with the required product characteristics.<br />
It is also an engineering task to limit the scope<br />
of a problem and its solution through negotiation<br />
among the stakeholders.<br />
<br />
''b''. ''Gather pertinent information''.<br />
<br />
At this stage,<br />
the designer attempts to expand his/her knowledge<br />
about the problem. This is a vital, yet often<br />
neglected, stage. Gathering pertinent information<br />
can reveal facts leading to a redefinition of the problem—in particular, mistakes and false starts<br />
may be identified. This step may also involve the<br />
decomposition of the problem into smaller, more<br />
easily solved subproblems.<br />
<br />
While gathering pertinent information, care<br />
must be taken to identify how a product may be<br />
used as well as misused. It is also important to<br />
understand the perceived value of the product/<br />
service being offered. Included in the pertinent<br />
information is a list of constraints that must be<br />
satisfied by the solution or that may limit the set<br />
of feasible solutions.<br />
<br />
''c''. ''Generate multiple solutions''.<br />
<br />
During this stage,<br />
different solutions to the same problem are developed.<br />
It has already been stated that design problems<br />
have multiple solutions. The goal of this<br />
step is to conceptualize multiple possible solutions<br />
and refine them to a sufficient level of detail<br />
that a comparison can be done among them.<br />
<br />
''d''. ''Analyze and select a solution''.<br />
<br />
Once alternative<br />
solutions have been identified, they need to be analyzed<br />
to identify the solution that best suits the current<br />
situation. The analysis includes a functional<br />
analysis to assess whether the proposed design<br />
would meet the functional requirements. Physical<br />
solutions that involve human users often include<br />
analysis of the ergonomics or user friendliness of<br />
the proposed solution. Other aspects of the solution—<br />
such as product safety and liability, an economic<br />
or market analysis to ensure a return (profit)<br />
on the solution, performance predictions and analysis<br />
to meet quality characteristics, opportunities<br />
for incorrect data input or hardware malfunctions,<br />
and so on—may be studied. The types and amount<br />
of analysis used on a proposed solution are dependent<br />
on the type of problem and the needs that the<br />
solution must address as well as the constraints<br />
imposed on the design.<br />
<br />
''e''. ''Implement the solution''.<br />
<br />
The final phase of the<br />
design process is implementation. Implementation<br />
refers to development and testing of the<br />
proposed solution. Sometimes a preliminary,<br />
partial solution called a ''prototype'' may be developed<br />
initially to test the proposed design solution<br />
under certain conditions. Feedback resulting<br />
from testing a prototype may be used either to refine the design or drive the selection of an alternative<br />
design solution. One of the most important<br />
activities in design is documentation of the<br />
design solution as well as of the tradeoffs for the<br />
choices made in the design of the solution. This<br />
work should be carried out in a manner such that<br />
the solution to the design problem can be communicated<br />
clearly to others.<br />
<br />
The testing and verification take us back to the<br />
success criteria. The engineer needs to devise<br />
tests such that the ability of the design to meet the<br />
success criteria is demonstrated. While designing<br />
the tests, the engineer must think through<br />
different possible failure modes and then design<br />
tests based on those failure modes. The engineer<br />
may choose to carry out designed experiments to<br />
assess the validity of the design.<br />
<br />
==Modeling, Simulation, and Prototyping==<br />
{{RightSection|{{referenceLink|number=5|parts=c6}} {{referenceLink|number=11|parts=c13s3}} {{referenceLink|number=12|parts=c2s3.1}}}}<br />
<br />
Modeling is part of the abstraction process used<br />
to represent some aspects of a system. Simulation<br />
uses a model of the system and provides a<br />
means of conducting designed experiments with<br />
that model to better understand the system, its<br />
behavior, and relationships between subsystems,<br />
as well as to analyze aspects of the design. Modeling<br />
and simulation are techniques that can be<br />
used to construct theories or hypotheses about the<br />
behavior of the system; engineers then use those<br />
theories to make predictions about the system.<br />
Prototyping is another abstraction process where<br />
a partial representation (that captures aspects of<br />
interest) of the product or system is built. A prototype<br />
may be an initial version of the system but<br />
lacks the full functionality of the final version.<br />
<br />
===Modeling===<br />
<br />
A model is always an abstraction of some real<br />
or imagined artifact. Engineers use models in<br />
many ways as part of their problem solving<br />
activities. Some models are physical, such as a<br />
made-to-scale miniature construction of a bridge<br />
or building. Other models may be nonphysical<br />
representations, such as a CAD drawing of a cog<br />
or a mathematical model for a process. Models<br />
help engineers reason and understand aspects of a problem. They can also help engineers understand<br />
what they do know and what they don’t<br />
know about the problem at hand.<br />
<br />
There are three types of models: iconic, analogic,<br />
and symbolic. An iconic model is a visually<br />
equivalent but incomplete 2-dimensional<br />
or 3-dimensional representation—for example,<br />
maps, globes, or built-to-scale models of structures<br />
such as bridges or highways. An iconic<br />
model actually resembles the artifact modeled.<br />
<br />
In contrast, an analogic model is a functionally<br />
equivalent but incomplete representation. That<br />
is, the model behaves like the physical artifact<br />
even though it may not physically resemble it.<br />
Examples of analogic models include a miniature<br />
airplane for wind tunnel testing or a computer<br />
simulation of a manufacturing process.<br />
<br />
Finally, a symbolic model is a higher level of<br />
abstraction, where the model is represented using<br />
symbols such as equations. The model captures<br />
the relevant aspects of the process or system in<br />
symbolic form. The symbols can then be used to<br />
increase the engineer’s understanding of the final<br />
system. An example is an equation such as F = Ma. Such mathematical models can be used to<br />
describe and predict properties or behavior of the<br />
final system or product.<br />
<br />
===Simulation===<br />
<br />
All simulation models are a specification of reality.<br />
A central issue in simulation is to abstract<br />
and specify an appropriate simplification of<br />
reality. Developing this abstraction is of vital<br />
importance, as misspecification of the abstraction<br />
would invalidate the results of the simulation<br />
exercise. Simulation can be used for a variety of<br />
testing purposes.<br />
<br />
Simulation is classified based on the type of<br />
system under study. Thus, simulation can be either<br />
continuous or discrete. In the context of software<br />
engineering, the emphasis will be primarily on<br />
discrete simulation. Discrete simulations may<br />
model event scheduling or process interaction.<br />
The main components in such a model include<br />
entities, activities and events, resources, the state<br />
of the system, a simulation clock, and a random<br />
number generator. Output is generated by the<br />
simulation and must be analyzed.<br />
<br />
An important problem in the development of a<br />
discrete simulation is that of initialization. Before<br />
a simulation can be run, the initial values of all<br />
the state variables must be provided. As the simulation<br />
designer may not know what initial values<br />
are appropriate for the state variables, these values<br />
might be chosen somewhat arbitrarily. For<br />
instance, it might be decided that a queue should<br />
be initialized as empty and idle. Such a choice of<br />
initial condition can have a significant but unrecognized<br />
impact on the outcome of the simulation.<br />
<br />
===Prototyping===<br />
<br />
Constructing a prototype of a system is another<br />
abstraction process. In this case, an initial version<br />
of the system is constructed, often while the system<br />
is being designed. This helps the designers<br />
determine the feasibility of their design.<br />
<br />
There are many uses for a prototype, including<br />
the elicitation of requirements, the design and<br />
refinement of a user interface to the system, validation<br />
of functional requirements, and so on. The<br />
objectives and purposes for building the prototype<br />
will determine its construction and the level<br />
of abstraction used.<br />
<br />
The role of prototyping is somewhat different<br />
between physical systems and software. With<br />
physical systems, the prototype may actually<br />
be the first fully functional version of a system<br />
or it may be a model of the system. In software<br />
engineering, prototypes are also an abstract<br />
model of part of the software but are usually not<br />
constructed with all of the architectural, performance,<br />
and other quality characteristics expected<br />
in the finished product. In either case, prototype<br />
construction must have a clear purpose and be<br />
planned, monitored, and controlled—it is a technique<br />
to study a specific problem within a limited<br />
context [6*, c2s8].<br />
<br />
In conclusion, modeling, simulation, and prototyping<br />
are powerful techniques for studying the<br />
behavior of a system from a given perspective.<br />
All can be used to perform designed experiments<br />
to study various aspects of the system. However,<br />
these are abstractions and, as such, may not<br />
model all attributes of interest.<br />
<br />
==Standards==<br />
{{RightSection|{{referenceLink|number=5|parts=c9s3.2}} {{referenceLink|number=13|parts=c1s2}}}}<br />
<br />
Moore states that a<br />
<br />
* standard can be;<br />
** (a) an object or measure of comparison that defines or represents the magnitude of a unit;<br />
** (b) a characterization that establishes allowable tolerances for categories of items;<br />
** and (c) a degree or level of required excellence or attainment.<br />
* Standards are definitional in nature, established either to further understanding and interaction or to acknowledge observed (or<br />
desired) norms of exhibited characteristics or behavior. [13*, p8]<br />
<br />
Standards provide requirements, specifications,<br />
guidelines, or characteristics that must be<br />
observed by engineers so that the products, processes,<br />
and materials have acceptable levels of<br />
quality. The qualities that various standards provide<br />
may be those of safety, reliability, or other<br />
product characteristics. Standards are considered<br />
critical to engineers and engineers are expected to<br />
be familiar with and to use the appropriate standards<br />
in their discipline.<br />
<br />
Compliance or conformance to a standard lets<br />
an organization say to the public that they (or<br />
their products) meet the requirements stated in<br />
that standard. Thus, standards divide organizations<br />
or their products into those that conform to<br />
the standard and those that do not. For a standard<br />
to be useful, conformance with the standard must<br />
add value—real or perceived—to the product,<br />
process, or effort.<br />
<br />
Apart from the organizational goals, standards<br />
are used for a number of other purposes such<br />
as protecting the buyer, protecting the business,<br />
and better defining the methods and procedures<br />
to be followed by the practice. Standards also<br />
provide users with a common terminology and<br />
expectations.<br />
<br />
There are many internationally recognized<br />
standards-making organizations including the<br />
International Telecommunications Union (ITU),<br />
the International Electrotechnical Commission<br />
(IEC), IEEE, and the International Organization<br />
for Standardization (ISO). In addition, there are regional and governmentally recognized organizations<br />
that generate standards for that region or<br />
country. For example, in the United States, there<br />
are over 300 organizations that develop standards.<br />
These include organizations such as the<br />
American National Standards Institute (ANSI),<br />
the American Society for Testing and Materials<br />
(ASTM), the Society of Automotive Engineers<br />
(SAE), and Underwriters Laboratories, Inc. (UL),<br />
as well as the US government. For more detail<br />
on standards used in software engineering, see<br />
Appendix B on standards.<br />
<br />
There is a set of commonly used principles<br />
behind standards. Standards makers attempt to<br />
have consensus around their decisions. There is<br />
usually an openness within the community of<br />
interest so that once a standard has been set, there<br />
is a good chance that it will be widely accepted.<br />
Most standards organizations have well-defined<br />
processes for their efforts and adhere to those<br />
processes carefully. Engineers must be aware of<br />
the existing standards but must also update their<br />
understanding of the standards as those standards<br />
change over time.<br />
<br />
In many engineering endeavors, knowing and<br />
understanding the applicable standards is critical<br />
and the law may even require use of particular<br />
standards. In these cases, the standards often represent<br />
minimal requirements that must be met by<br />
the endeavor and thus are an element in the constraints<br />
imposed on any design effort. The engineer<br />
must review all current standards related to<br />
a given endeavor and determine which must be<br />
met. Their designs must then incorporate any and<br />
all constraints imposed by the applicable standard.<br />
Standards important to software engineers<br />
are discussed in more detail in an appendix specifically<br />
on this subject.<br />
<br />
==Root Cause Analysis==<br />
{{RightSection|{{referenceLink|number=4|parts=c5, c3s7, c9s8}} {{referenceLink|number=5|parts=c9s3, c9s4, c9s5}} {{referenceLink|number=13|parts=c13s3.4.5}}}}<br />
<br />
Root cause analysis (RCA) is a process designed<br />
to investigate and identify why and how an<br />
undesirable event has happened. Root causes<br />
are underlying causes. The investigator should<br />
attempt to identify specific underlying causes of<br />
the event that has occurred. The primary objective of RCA is to prevent recurrence of the undesirable<br />
event. Thus, the more specific the investigator<br />
can be about why an event occurred, the easier<br />
it will be to prevent recurrence. A common way<br />
to identify specific underlying cause(s) is to ask a<br />
series of ''why'' questions.<br />
<br />
===Techniques for Conducting Root Cause Analysis===<br />
{{RightSection|{{referenceLink|number=4|parts=c5}} {{referenceLink|number=5|parts=c3}}}}<br />
<br />
There are many approaches used for both quality<br />
control and root cause analysis. The first step in<br />
any root cause analysis effort is to identify the real<br />
problem. Techniques such as statement-restatement,<br />
why-why diagrams, the revision method,<br />
present state and desired state diagrams, and the<br />
fresh-eye approach are used to identify and refine<br />
the real problem that needs to be addressed.<br />
<br />
Once the real problem has been identified, then<br />
work can begin to determine the cause of the<br />
problem. Ishikawa is known for the seven tools<br />
for quality control that he promoted. Some of<br />
those tools are helpful in identifying the causes<br />
for a given problem. Those tools are check sheets<br />
or checklists, Pareto diagrams, histograms, run<br />
charts, scatter diagrams, control charts, and<br />
fishbone or cause-and-effect diagrams. More<br />
recently, other approaches for quality improvement<br />
and root cause analysis have emerged. Some<br />
examples of these newer methods are affinity diagrams,<br />
relations diagrams, tree diagrams, matrix<br />
charts, matrix data analysis charts, process decision<br />
program charts, and arrow diagrams. A few<br />
of these techniques are briefly described below.<br />
<br />
A fishbone or cause-and-effect diagram is a<br />
way to visualize the various factors that affect<br />
some characteristic. The main line in the diagram<br />
represents the problem and the connecting lines<br />
represent the factors that led to or influenced the<br />
problem. Those factors are broken down into subfactors<br />
and sub-subfactors until root causes can<br />
be identified.<br />
<br />
A very simple approach that is useful in quality<br />
control is the use of a checklist. Checklists are<br />
a list of key points in a process with tasks that<br />
must be completed. As each task is completed,<br />
it is checked off the list. If a problem occurs,<br />
then sometimes the checklist can quickly identify<br />
tasks that may have been skipped or only partially<br />
completed.<br />
<br />
Finally, relations diagrams are a means for displaying<br />
complex relationships. They give visual<br />
support to cause-and-effect thinking. The diagram<br />
relates the specific to the general, revealing<br />
key causes and key effects.<br />
<br />
Root cause analysis aims at preventing the<br />
recurrence of undesirable events. Reduction of<br />
variation due to common causes requires utilization<br />
of a number of techniques. An important<br />
point to note is that these techniques should be<br />
used offline and not necessarily in direct response<br />
to the occurrence of some undesirable event.<br />
Some of the techniques that may be used to<br />
reduce variation due to common causes are given<br />
below.<br />
<br />
* 1. Cause-and-effect diagrams may be used to identify the sub and sub-sub causes.<br />
* 2. Fault tree analysis is a technique that may be used to understand the sources of failures.<br />
* 3. Designed experiments may be used to understand the impact of various causes on the occurrence of undesirable events (see Empirical<br />
Methods and Experimental Techniques in this KA).<br />
* 4. Various kinds of correlation analyses may be used to understand the relationship between various causes and their impact. These techniques may be used in cases when conducting controlled experiments is difficult but data may be gathered (see Statistical Analysis in this KA).<br />
<br />
{{EndSection|title=Futher Readings|body=<br />
A. Abran, ''Software Metrics and Software Metrology''. [14]<br />
<br />
This book provides very good information on the<br />
proper use of the terms measure, measurement<br />
method and measurement outcome. It provides<br />
strong support material for the entire section on<br />
Measurement.<br />
<br />
W.G. Vincenti, ''What Engineers Know and How They Know It''. [15]<br />
<br />
This book provides an interesting introduction<br />
to engineering foundations through a series<br />
of case studies that show many of the foundational<br />
concepts as used in real world engineering<br />
applications.}}<br />
{{EndSection|title=References|body=<br />
{{reference<br />
|number=1<br />
|author=IEEE<br />
|article=<br />
|publication=ISO/IEC/IEEE 24765:2010 Systems and Software Engineering—Vocabulary, ISO/IEC/IEEE<br />
|edition=<br />
|publisher=ISO/IEC/IEEE<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=2<br />
|author=D.C. Montgomery and G.C. Runger<br />
|article=<br />
|publication=Applied Statistics and Probability for Engineers<br />
|edition=4th ed.<br />
|publisher=Wiley<br />
|issue=<br />
|date=2007<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=3<br />
|author=L. Null and J. Lobur<br />
|article=<br />
|publication=The Essentials of Computer Organization and Architecture<br />
|edition=2nd ed.<br />
|publisher=Jones and Bartlett Publishers<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=4<br />
|author=S.H. Kan<br />
|article=<br />
|publication=Metrics and Models in Software Quality Engineering<br />
|edition=2nd ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2002<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=5<br />
|author=G. Voland <br />
|article= <br />
|publication=Engineering by Design<br />
|edition=2nd ed.<br />
|publisher=Prentice Hall<br />
|issue=<br />
|date=2003<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=6<br />
|author=R.E. Fairley<br />
|article=<br />
|publication=Managing and Leading Software Projects<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2009<br />
|part=<br />
|link=<br />
}}{{reference<br />
|number=7<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=7<br />
|author=S. Tockey<br />
|article=<br />
|publication=Return on Software: Maximizing the Return on Your Software Investment<br />
|edition=<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=8<br />
|author=Canadian Engineering Accreditation Board, Engineers Canada<br />
|article=“Accreditation Criteria and Procedures”<br />
|publication=<br />
|edition=<br />
|publisher=Canadian Council of Professional Engineers<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=www.engineerscanada.ca/files/w_Accreditation_Criteria_Procedures_2011.pdf<br />
}}<br />
{{reference<br />
|number=9<br />
|author=ABET Engineering Accreditation Commission<br />
|article=“Criteria for Accrediting Engineering Programs, 2012-2013”<br />
|publication=<br />
|edition=<br />
|publisher=ABET<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=www.abet.org/uploadedFiles/Accreditation/Accreditation_Process/Accreditation_Documents/Current/eaccriteria-2012-2013.pdf<br />
}}<br />
{{reference<br />
|number=10<br />
|author=S. McConnell<br />
|article=<br />
|publication=Code Complete<br />
|edition=2nd ed.<br />
|publisher=Microsoft Press<br />
|issue=<br />
|date=2004<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=11<br />
|author=E.W. Cheney and D.R. Kincaid<br />
|article=<br />
|publication=Numerical Mathematics and Computing<br />
|edition=<br />
|publisher=Brooks/Cole<br />
|issue=<br />
|date=2007<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=12<br />
|authorI. Sommerville<br />
|article=<br />
|publication=Software Engineering<br />
|edition=9th ed.<br />
|publisher=Addison-Wesley<br />
|issue=<br />
|date=2011<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=13<br />
|author=J.W. Moore<br />
|article=<br />
|publication=The Road Map to Software Engineering: A Standards-Based Guide<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2006<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=14<br />
|author=A. Abran<br />
|article=<br />
|publication=Software Metrics and Software Metrology<br />
|edition=<br />
|publisher=Wiley-IEEE Computer Society Press<br />
|issue=<br />
|date=2010<br />
|part=<br />
|link=<br />
}}<br />
{{reference<br />
|number=15<br />
|author=W.G. Vincenti<br />
|article=<br />
|publication=What Engineers Know and How They Know It<br />
|edition=<br />
|publisher=John Hopkins University Press<br />
|issue=<br />
|date=1990<br />
|part=<br />
|link=<br />
}}<br />
{{ReferenceList}}<br />
}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=845Chapter 15: Engineering Foundations2015-08-29T06:08:58Z<p>Daniel Robbins: /* Techniques for Conducting Root Cause Analysis */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any point on this line and a fixed interior point called the center is constant''. <br />
We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.<br />
<br />
The importance of operational definitions<br />
can hardly be overstated. Take the case of the<br />
apparently simple measurement of height of<br />
individuals. Unless we specify various factors<br />
like the time when the height will be measured<br />
(it is known that the height of individuals vary<br />
across various time points of the day), how the<br />
variability due to hair would be taken care of,<br />
whether the measurement will be with or without<br />
shoes, what kind of accuracy is expected (correct<br />
up to an inch, 1/2 inch, centimeter, etc.) — even this simple measurement will lead to substantial<br />
variation. Engineers must appreciate the need to<br />
define measures from an operational perspective.<br />
<br />
===Levels (Scales) of Measurement===<br />
{{RightSection| {{referenceLink|number=4|parts=c3s2}} {{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Once the operational definitions are determined,<br />
the actual measurements need to be undertaken.<br />
It is to be noted that measurement may be carried<br />
out in four different scales: namely, nominal,<br />
ordinal, interval, and ratio. Brief descriptions of<br />
each are given below.<br />
<br />
''Nominal scale'': This is the lowest level of measurement<br />
and represents the most unrestricted<br />
assignment of numerals. The numerals serve only<br />
as labels, and words or letters would serve as well.<br />
The nominal scale of measurement involves only<br />
classification and the observed sampling units<br />
are put into any one of the mutually exclusive<br />
and collectively exhaustive categories (classes).<br />
Some examples of nominal scales are:<br />
<br />
* Job titles in a company<br />
* The software development life cycle (SDLC) model (like waterfall, iterative, agile, etc.) followed by different software projects<br />
<br />
In nominal scale, the names of the different categories<br />
are just labels and no relationship between<br />
them is assumed. The only operations that can be<br />
carried out on nominal scale is that of counting<br />
the number of occurrences in the different classes<br />
and determining if two occurrences have the same<br />
nominal value. However, statistical analyses may<br />
be carried out to understand how entities belonging<br />
to different classes perform with respect to<br />
some other response variable.<br />
<br />
''Ordinal scale'': Refers to the measurement scale<br />
where the different values obtained through the<br />
process of measurement have an implicit ordering.<br />
The intervals between values are not specified<br />
and there is no objectively defined zero<br />
element. Typical examples of measurements in<br />
ordinal scales are:<br />
<br />
* Skill levels (low, medium, high)<br />
* Capability Maturity Model Integration (CMMI) maturity levels of software development organizations<br />
* Level of adherence to process as measured in a 5-point scale of excellent, above average, average, below average, and poor, indicating<br />
the range from total adherence to no adherence at all<br />
<br />
Measurement in ordinal scale satisfies the transitivity<br />
property in the sense that if A > B and B<br />
> C, then A > C. However, arithmetic operations<br />
cannot be carried out on variables measured in<br />
ordinal scales. Thus, if we measure customer satisfaction<br />
on a 5-point ordinal scale of 5 implying<br />
a very high level of satisfaction and 1 implying a<br />
very high level of dissatisfaction, we cannot say<br />
that a score of four is twice as good as a score<br />
of two. So, it is better to use terminology such<br />
as excellent, above average, average, below average,<br />
and poor than ordinal numbers in order to<br />
avoid the error of treating an ordinal scale as a<br />
ratio scale. It is important to note that ordinal<br />
scale measures are commonly misused and such<br />
misuse can lead to erroneous conclusions [6*,<br />
p274]. A common misuse of ordinal scale measures<br />
is to present a mean and standard deviation<br />
for the data set, both of which are meaningless.<br />
However, we can find the median, as computation<br />
of the median involves counting only.<br />
<br />
''Interval scales'': With the interval scale, we<br />
come to a form that is quantitative in the ordinary<br />
sense of the word. Almost all the usual statistical<br />
measures are applicable here, unless they<br />
require knowledge of a ''true' zero point. The zero<br />
point on an interval scale is a matter of convention.<br />
Ratios do not make sense, but the difference<br />
between levels of attributes can be computed and<br />
is meaningful. Some examples of interval scale of<br />
measurement follow:<br />
<br />
* Measurement of temperature in different scales, such as Celsius and Fahrenheit. Suppose T<sub>1</sub> and T<sub>2</sub> are temperatures measured in some scale. We note that the fact that T<sub>1</sub> is twice T<sub>2</sub> does not mean that one object is twice as hot as another. We also note that the zero points are arbitrary.<br />
* Calendar dates. While the difference between dates to measure the time elapsed is a meaningful concept, the ratio does not make sense.<br />
* Many psychological measurements aspire to create interval scales. Intelligence is often measured in interval scale, as it is not necessary to define what zero intelligence would mean.<br />
<br />
If a variable is measured in interval scale, most<br />
of the usual statistical analyses like mean, standard<br />
deviation, correlation, and regression may<br />
be carried out on the measured values.<br />
<br />
''Ratio scale'': These are quite commonly encountered<br />
in physical science. These scales of measures<br />
are characterized by the fact that operations<br />
exist for determining all 4 relations: equality, rank<br />
order, equality of intervals, and equality of ratios.<br />
Once such a scale is available, its numerical values<br />
can be transformed from one unit to another<br />
by just multiplying by a constant, e.g., conversion<br />
of inches to feet or centimeters. When measurements<br />
are being made in ratio scale, existence of<br />
a nonarbitrary zero is mandatory. All statistical<br />
measures are applicable to ratio scale; logarithm<br />
usage is valid only when these scales are used, as<br />
in the case of decibels. Some examples of ratio<br />
measures are<br />
<br />
* the number of statements in a software program<br />
* temperature measured in the Kelvin (K) scale or in Fahrenheit (F).<br />
<br />
An additional measurement scale, the absolute<br />
scale, is a ratio scale with uniqueness of the measure;<br />
i.e., a measure for which no transformation<br />
is possible (for example, the number of programmers<br />
working on a project).<br />
<br />
===Direct and Derived Measures===<br />
{{RightSection|{{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Measures may be either direct or derived (sometimes<br />
called indirect measures). An example of<br />
a direct measure would be a count of how many<br />
times an event occurred, such as the number of<br />
defects found in a software product. A derived<br />
measure is one that combines direct measures in<br />
some way that is consistent with the measurement<br />
method. An example of a derived measure would<br />
be calculating the productivity of a team as the<br />
number of lines of code developed per developermonth.<br />
In both cases, the measurement method<br />
determines how to make the measurement.<br />
<br />
===Reliability and Validity===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s4, c3s5}}}}<br />
<br />
A basic question to be asked for any measurement<br />
method is whether the proposed measurement<br />
method is truly measuring the concept with<br />
good quality. Reliability and validity are the two<br />
most important criteria to address this question.<br />
<br />
The reliability of a measurement method is<br />
the extent to which the application of the measurement<br />
method yields consistent measurement<br />
results. Essentially, ''reliability'' refers to the consistency<br />
of the values obtained when the same item<br />
is measured a number of times. When the results<br />
agree with each other, the measurement method<br />
is said to be reliable. Reliability usually depends<br />
on the operational definition. It can be quantified<br />
by using the index of variation, which is computed<br />
as the ratio between the standard deviation<br />
and the mean. The smaller the index, the more<br />
reliable the measurement results.<br />
<br />
''Validity'' refers to whether the measurement<br />
method really measures what we intend to measure.<br />
Validity of a measurement method may<br />
be looked at from three different perspectives:<br />
namely, construct validity, criteria validity, and<br />
content validity.<br />
<br />
===Assessing Reliability===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s5}}}}<br />
<br />
There are several methods for assessing reliability;<br />
these include the test-retest method, the<br />
alternative form method, the split-halves method,<br />
and the internal consistency method. The easiest<br />
of these is the test-retest method. In the testretest<br />
method, we simply apply the measurement<br />
method to the same subjects twice. The correlation<br />
coefficient between the first and second set<br />
of measurement results gives the reliability of the<br />
measurement method.<br />
<br />
==Engineering Design==<br />
{{RightSection|{{referenceLink|number=5|parts=c1s2, c1s3, c1s4}}}}<br />
<br />
A product’s life cycle costs are largely influenced<br />
by the design of the product. This is true for manufactured<br />
products as well as for software products.<br />
<br />
The design of a software product is guided by<br />
the features to be included and the quality attributes<br />
to be provided. It is important to note that<br />
software engineers use the term “design” within<br />
their own context; while there are some commonalities,<br />
there are also many differences between<br />
engineering design as discussed in this section<br />
and software engineering design as discussed in<br />
the Software Design KA. The scope of engineering<br />
design is generally viewed as much broader<br />
than that of software design. The primary aim of<br />
this section is to identify the concepts needed to<br />
develop a clear understanding regarding the process<br />
of engineering design.<br />
<br />
Many disciplines engage in problem solving<br />
activities where there is a single correct solution.<br />
In engineering, most problems have many<br />
solutions and the focus is on finding a feasible<br />
solution (among the many alternatives) that<br />
best meets the needs presented. The set of possible<br />
solutions is often constrained by explicitly<br />
imposed limitations such as cost, available<br />
resources, and the state of discipline or domain<br />
knowledge. In engineering problems, sometimes<br />
there are also implicit constraints (such as the<br />
physical properties of materials or laws of physics)<br />
that also restrict the set of feasible solutions<br />
for a given problem.<br />
<br />
===Engineering Design in Engineering Education===<br />
<br />
The importance of engineering design in engineering<br />
education can be clearly seen by the high<br />
expectations held by various accreditation bodies<br />
for engineering education. Both the Canadian<br />
Engineering Accreditation Board and the<br />
Accreditation Board for Engineering and Technology<br />
(ABET) note the importance of including<br />
engineering design in education programs.<br />
<br />
The Canadian Engineering Accreditation<br />
Board includes requirements for the amount of<br />
engineering design experience/coursework that<br />
is necessary for engineering students as well as<br />
qualifications for the faculty members who teach<br />
such coursework or supervise design projects.<br />
Their accreditation criteria states:<br />
<br />
* Design: An ability to design solutions for complex, open-ended engineering problems and to design systems, components or processes that meet specified needs with appropriate attention to health and safety risks, applicable standards, and economic, environmental, cultural and societal considerations. [8, p12]<br />
<br />
In a similar manner, ABET defines engineering<br />
design as<br />
<br />
* the process of devising a system, component, or process to meet desired needs. It is a decision-making process (often iterative), in which the basic sciences, mathematics, and the engineering sciences are applied to convert resources optimally to meet these stated needs. [9, p4]<br />
<br />
Thus, it is clear that engineering design is a<br />
vital component in the training and education for<br />
all engineers. The remainder of this section will<br />
focus on various aspects of engineering design.<br />
<br />
===Design as a Problem Solving Activity===<br />
{{RightSection|{{referenceLink|number=5|parts=c1s4, c2s1, c3s3}}}}<br />
<br />
It is to be noted that engineering design is primarily<br />
a problem solving activity. Design problems<br />
are open ended and more vaguely defined. There<br />
are usually several alternative ways to solve the<br />
same problem. Design is generally considered to<br />
be a ''wicked problem'' —a term first coined by Horst<br />
Rittel in the 1960s when design methods were a<br />
subject of intense interest. Rittel sought an alternative<br />
to the linear, step-by-step model of the design<br />
process being explored by many designers and<br />
design theorists and argued that most of the problems<br />
addressed by the designers are wicked problems.<br />
As explained by Steve McConnell, a wicked<br />
problem is one that could be clearly defined only<br />
by solving it or by solving part of it. This paradox<br />
implies, essentially, that a wicked problem has to<br />
be solved once in order to define it clearly and then<br />
solved again to create a solution that works. This<br />
has been an important insight for software designers<br />
for several decades [10*, c5s1].<br />
<br />
===Steps Involved in Engineering Design===<br />
{{RightSection|{{referenceLink|number=7|parts=c4}}}}<br />
<br />
Engineering problem solving begins when a<br />
need is recognized and no existing solution will<br />
meet that need. As part of this problem solving,<br />
the design goals to be achieved by the solution<br />
should be identified. Additionally, a set of acceptance<br />
criteria must be defined and used to determine<br />
how well a proposed solution will satisfy<br />
the need. Once a need for a solution to a problem<br />
has been identified, the process of engineering<br />
design has the following generic steps:<br />
<br />
* a) define the problem<br />
* b) gather pertinent information<br />
* c) generate multiple solutions<br />
* d) analyze and select a solution<br />
* e) implement the solution<br />
<br />
All of the engineering design steps are iterative,<br />
and knowledge gained at any step in the<br />
process may be used to inform earlier tasks and<br />
trigger an iteration in the process. These steps are<br />
expanded in the subsequent sections<br />
<br />
''a''. ''Define the problem''. <br />
<br />
At this stage, the customer’s<br />
requirements are gathered. Specific information<br />
about product functions and features are also<br />
closely examined. This step includes refining the<br />
problem statement to identify the real problem to<br />
be solved and setting the design goals and criteria<br />
for success.<br />
<br />
The problem definition is a crucial stage in<br />
engineering design. A point to note is that this<br />
step is deceptively simple. Thus, enough care<br />
must be taken to carry out this step judiciously. It<br />
is important to identify needs and link the success<br />
criteria with the required product characteristics.<br />
It is also an engineering task to limit the scope<br />
of a problem and its solution through negotiation<br />
among the stakeholders.<br />
<br />
''b''. ''Gather pertinent information''.<br />
<br />
At this stage,<br />
the designer attempts to expand his/her knowledge<br />
about the problem. This is a vital, yet often<br />
neglected, stage. Gathering pertinent information<br />
can reveal facts leading to a redefinition of the problem—in particular, mistakes and false starts<br />
may be identified. This step may also involve the<br />
decomposition of the problem into smaller, more<br />
easily solved subproblems.<br />
<br />
While gathering pertinent information, care<br />
must be taken to identify how a product may be<br />
used as well as misused. It is also important to<br />
understand the perceived value of the product/<br />
service being offered. Included in the pertinent<br />
information is a list of constraints that must be<br />
satisfied by the solution or that may limit the set<br />
of feasible solutions.<br />
<br />
''c''. ''Generate multiple solutions''.<br />
<br />
During this stage,<br />
different solutions to the same problem are developed.<br />
It has already been stated that design problems<br />
have multiple solutions. The goal of this<br />
step is to conceptualize multiple possible solutions<br />
and refine them to a sufficient level of detail<br />
that a comparison can be done among them.<br />
<br />
''d''. ''Analyze and select a solution''.<br />
<br />
Once alternative<br />
solutions have been identified, they need to be analyzed<br />
to identify the solution that best suits the current<br />
situation. The analysis includes a functional<br />
analysis to assess whether the proposed design<br />
would meet the functional requirements. Physical<br />
solutions that involve human users often include<br />
analysis of the ergonomics or user friendliness of<br />
the proposed solution. Other aspects of the solution—<br />
such as product safety and liability, an economic<br />
or market analysis to ensure a return (profit)<br />
on the solution, performance predictions and analysis<br />
to meet quality characteristics, opportunities<br />
for incorrect data input or hardware malfunctions,<br />
and so on—may be studied. The types and amount<br />
of analysis used on a proposed solution are dependent<br />
on the type of problem and the needs that the<br />
solution must address as well as the constraints<br />
imposed on the design.<br />
<br />
''e''. ''Implement the solution''.<br />
<br />
The final phase of the<br />
design process is implementation. Implementation<br />
refers to development and testing of the<br />
proposed solution. Sometimes a preliminary,<br />
partial solution called a ''prototype'' may be developed<br />
initially to test the proposed design solution<br />
under certain conditions. Feedback resulting<br />
from testing a prototype may be used either to refine the design or drive the selection of an alternative<br />
design solution. One of the most important<br />
activities in design is documentation of the<br />
design solution as well as of the tradeoffs for the<br />
choices made in the design of the solution. This<br />
work should be carried out in a manner such that<br />
the solution to the design problem can be communicated<br />
clearly to others.<br />
<br />
The testing and verification take us back to the<br />
success criteria. The engineer needs to devise<br />
tests such that the ability of the design to meet the<br />
success criteria is demonstrated. While designing<br />
the tests, the engineer must think through<br />
different possible failure modes and then design<br />
tests based on those failure modes. The engineer<br />
may choose to carry out designed experiments to<br />
assess the validity of the design.<br />
<br />
==Modeling, Simulation, and Prototyping==<br />
{{RightSection|{{referenceLink|number=5|parts=c6}} {{referenceLink|number=11|parts=c13s3}} {{referenceLink|number=12|parts=c2s3.1}}}}<br />
<br />
Modeling is part of the abstraction process used<br />
to represent some aspects of a system. Simulation<br />
uses a model of the system and provides a<br />
means of conducting designed experiments with<br />
that model to better understand the system, its<br />
behavior, and relationships between subsystems,<br />
as well as to analyze aspects of the design. Modeling<br />
and simulation are techniques that can be<br />
used to construct theories or hypotheses about the<br />
behavior of the system; engineers then use those<br />
theories to make predictions about the system.<br />
Prototyping is another abstraction process where<br />
a partial representation (that captures aspects of<br />
interest) of the product or system is built. A prototype<br />
may be an initial version of the system but<br />
lacks the full functionality of the final version.<br />
<br />
===Modeling===<br />
<br />
A model is always an abstraction of some real<br />
or imagined artifact. Engineers use models in<br />
many ways as part of their problem solving<br />
activities. Some models are physical, such as a<br />
made-to-scale miniature construction of a bridge<br />
or building. Other models may be nonphysical<br />
representations, such as a CAD drawing of a cog<br />
or a mathematical model for a process. Models<br />
help engineers reason and understand aspects of a problem. They can also help engineers understand<br />
what they do know and what they don’t<br />
know about the problem at hand.<br />
<br />
There are three types of models: iconic, analogic,<br />
and symbolic. An iconic model is a visually<br />
equivalent but incomplete 2-dimensional<br />
or 3-dimensional representation—for example,<br />
maps, globes, or built-to-scale models of structures<br />
such as bridges or highways. An iconic<br />
model actually resembles the artifact modeled.<br />
<br />
In contrast, an analogic model is a functionally<br />
equivalent but incomplete representation. That<br />
is, the model behaves like the physical artifact<br />
even though it may not physically resemble it.<br />
Examples of analogic models include a miniature<br />
airplane for wind tunnel testing or a computer<br />
simulation of a manufacturing process.<br />
<br />
Finally, a symbolic model is a higher level of<br />
abstraction, where the model is represented using<br />
symbols such as equations. The model captures<br />
the relevant aspects of the process or system in<br />
symbolic form. The symbols can then be used to<br />
increase the engineer’s understanding of the final<br />
system. An example is an equation such as F = Ma. Such mathematical models can be used to<br />
describe and predict properties or behavior of the<br />
final system or product.<br />
<br />
===Simulation===<br />
<br />
All simulation models are a specification of reality.<br />
A central issue in simulation is to abstract<br />
and specify an appropriate simplification of<br />
reality. Developing this abstraction is of vital<br />
importance, as misspecification of the abstraction<br />
would invalidate the results of the simulation<br />
exercise. Simulation can be used for a variety of<br />
testing purposes.<br />
<br />
Simulation is classified based on the type of<br />
system under study. Thus, simulation can be either<br />
continuous or discrete. In the context of software<br />
engineering, the emphasis will be primarily on<br />
discrete simulation. Discrete simulations may<br />
model event scheduling or process interaction.<br />
The main components in such a model include<br />
entities, activities and events, resources, the state<br />
of the system, a simulation clock, and a random<br />
number generator. Output is generated by the<br />
simulation and must be analyzed.<br />
<br />
An important problem in the development of a<br />
discrete simulation is that of initialization. Before<br />
a simulation can be run, the initial values of all<br />
the state variables must be provided. As the simulation<br />
designer may not know what initial values<br />
are appropriate for the state variables, these values<br />
might be chosen somewhat arbitrarily. For<br />
instance, it might be decided that a queue should<br />
be initialized as empty and idle. Such a choice of<br />
initial condition can have a significant but unrecognized<br />
impact on the outcome of the simulation.<br />
<br />
===Prototyping===<br />
<br />
Constructing a prototype of a system is another<br />
abstraction process. In this case, an initial version<br />
of the system is constructed, often while the system<br />
is being designed. This helps the designers<br />
determine the feasibility of their design.<br />
<br />
There are many uses for a prototype, including<br />
the elicitation of requirements, the design and<br />
refinement of a user interface to the system, validation<br />
of functional requirements, and so on. The<br />
objectives and purposes for building the prototype<br />
will determine its construction and the level<br />
of abstraction used.<br />
<br />
The role of prototyping is somewhat different<br />
between physical systems and software. With<br />
physical systems, the prototype may actually<br />
be the first fully functional version of a system<br />
or it may be a model of the system. In software<br />
engineering, prototypes are also an abstract<br />
model of part of the software but are usually not<br />
constructed with all of the architectural, performance,<br />
and other quality characteristics expected<br />
in the finished product. In either case, prototype<br />
construction must have a clear purpose and be<br />
planned, monitored, and controlled—it is a technique<br />
to study a specific problem within a limited<br />
context [6*, c2s8].<br />
<br />
In conclusion, modeling, simulation, and prototyping<br />
are powerful techniques for studying the<br />
behavior of a system from a given perspective.<br />
All can be used to perform designed experiments<br />
to study various aspects of the system. However,<br />
these are abstractions and, as such, may not<br />
model all attributes of interest.<br />
<br />
==Standards==<br />
{{RightSection|{{referenceLink|number=5|parts=c9s3.2}} {{referenceLink|number=13|parts=c1s2}}}}<br />
<br />
Moore states that a<br />
<br />
* standard can be;<br />
** (a) an object or measure of comparison that defines or represents the magnitude of a unit;<br />
** (b) a characterization that establishes allowable tolerances for categories of items;<br />
** and (c) a degree or level of required excellence or attainment.<br />
* Standards are definitional in nature, established either to further understanding and interaction or to acknowledge observed (or<br />
desired) norms of exhibited characteristics or behavior. [13*, p8]<br />
<br />
Standards provide requirements, specifications,<br />
guidelines, or characteristics that must be<br />
observed by engineers so that the products, processes,<br />
and materials have acceptable levels of<br />
quality. The qualities that various standards provide<br />
may be those of safety, reliability, or other<br />
product characteristics. Standards are considered<br />
critical to engineers and engineers are expected to<br />
be familiar with and to use the appropriate standards<br />
in their discipline.<br />
<br />
Compliance or conformance to a standard lets<br />
an organization say to the public that they (or<br />
their products) meet the requirements stated in<br />
that standard. Thus, standards divide organizations<br />
or their products into those that conform to<br />
the standard and those that do not. For a standard<br />
to be useful, conformance with the standard must<br />
add value—real or perceived—to the product,<br />
process, or effort.<br />
<br />
Apart from the organizational goals, standards<br />
are used for a number of other purposes such<br />
as protecting the buyer, protecting the business,<br />
and better defining the methods and procedures<br />
to be followed by the practice. Standards also<br />
provide users with a common terminology and<br />
expectations.<br />
<br />
There are many internationally recognized<br />
standards-making organizations including the<br />
International Telecommunications Union (ITU),<br />
the International Electrotechnical Commission<br />
(IEC), IEEE, and the International Organization<br />
for Standardization (ISO). In addition, there are regional and governmentally recognized organizations<br />
that generate standards for that region or<br />
country. For example, in the United States, there<br />
are over 300 organizations that develop standards.<br />
These include organizations such as the<br />
American National Standards Institute (ANSI),<br />
the American Society for Testing and Materials<br />
(ASTM), the Society of Automotive Engineers<br />
(SAE), and Underwriters Laboratories, Inc. (UL),<br />
as well as the US government. For more detail<br />
on standards used in software engineering, see<br />
Appendix B on standards.<br />
<br />
There is a set of commonly used principles<br />
behind standards. Standards makers attempt to<br />
have consensus around their decisions. There is<br />
usually an openness within the community of<br />
interest so that once a standard has been set, there<br />
is a good chance that it will be widely accepted.<br />
Most standards organizations have well-defined<br />
processes for their efforts and adhere to those<br />
processes carefully. Engineers must be aware of<br />
the existing standards but must also update their<br />
understanding of the standards as those standards<br />
change over time.<br />
<br />
In many engineering endeavors, knowing and<br />
understanding the applicable standards is critical<br />
and the law may even require use of particular<br />
standards. In these cases, the standards often represent<br />
minimal requirements that must be met by<br />
the endeavor and thus are an element in the constraints<br />
imposed on any design effort. The engineer<br />
must review all current standards related to<br />
a given endeavor and determine which must be<br />
met. Their designs must then incorporate any and<br />
all constraints imposed by the applicable standard.<br />
Standards important to software engineers<br />
are discussed in more detail in an appendix specifically<br />
on this subject.<br />
<br />
==Root Cause Analysis==<br />
{{RightSection|{{referenceLink|number=4|parts=c5, c3s7, c9s8}} {{referenceLink|number=5|parts=c9s3, c9s4, c9s5}} {{referenceLink|number=13|parts=c13s3.4.5}}}}<br />
<br />
Root cause analysis (RCA) is a process designed<br />
to investigate and identify why and how an<br />
undesirable event has happened. Root causes<br />
are underlying causes. The investigator should<br />
attempt to identify specific underlying causes of<br />
the event that has occurred. The primary objective of RCA is to prevent recurrence of the undesirable<br />
event. Thus, the more specific the investigator<br />
can be about why an event occurred, the easier<br />
it will be to prevent recurrence. A common way<br />
to identify specific underlying cause(s) is to ask a<br />
series of ''why'' questions.<br />
<br />
===Techniques for Conducting Root Cause Analysis===<br />
{{RightSection|{{referenceLink|number=4|parts=c5}} {{referenceLink|number=5|parts=c3}}}}<br />
<br />
There are many approaches used for both quality<br />
control and root cause analysis. The first step in<br />
any root cause analysis effort is to identify the real<br />
problem. Techniques such as statement-restatement,<br />
why-why diagrams, the revision method,<br />
present state and desired state diagrams, and the<br />
fresh-eye approach are used to identify and refine<br />
the real problem that needs to be addressed.<br />
<br />
Once the real problem has been identified, then<br />
work can begin to determine the cause of the<br />
problem. Ishikawa is known for the seven tools<br />
for quality control that he promoted. Some of<br />
those tools are helpful in identifying the causes<br />
for a given problem. Those tools are check sheets<br />
or checklists, Pareto diagrams, histograms, run<br />
charts, scatter diagrams, control charts, and<br />
fishbone or cause-and-effect diagrams. More<br />
recently, other approaches for quality improvement<br />
and root cause analysis have emerged. Some<br />
examples of these newer methods are affinity diagrams,<br />
relations diagrams, tree diagrams, matrix<br />
charts, matrix data analysis charts, process decision<br />
program charts, and arrow diagrams. A few<br />
of these techniques are briefly described below.<br />
<br />
A fishbone or cause-and-effect diagram is a<br />
way to visualize the various factors that affect<br />
some characteristic. The main line in the diagram<br />
represents the problem and the connecting lines<br />
represent the factors that led to or influenced the<br />
problem. Those factors are broken down into subfactors<br />
and sub-subfactors until root causes can<br />
be identified.<br />
<br />
A very simple approach that is useful in quality<br />
control is the use of a checklist. Checklists are<br />
a list of key points in a process with tasks that<br />
must be completed. As each task is completed,<br />
it is checked off the list. If a problem occurs,<br />
then sometimes the checklist can quickly identify<br />
tasks that may have been skipped or only partially<br />
completed.<br />
<br />
Finally, relations diagrams are a means for displaying<br />
complex relationships. They give visual<br />
support to cause-and-effect thinking. The diagram<br />
relates the specific to the general, revealing<br />
key causes and key effects.<br />
<br />
Root cause analysis aims at preventing the<br />
recurrence of undesirable events. Reduction of<br />
variation due to common causes requires utilization<br />
of a number of techniques. An important<br />
point to note is that these techniques should be<br />
used offline and not necessarily in direct response<br />
to the occurrence of some undesirable event.<br />
Some of the techniques that may be used to<br />
reduce variation due to common causes are given<br />
below.<br />
<br />
* 1. Cause-and-effect diagrams may be used to identify the sub and sub-sub causes.<br />
* 2. Fault tree analysis is a technique that may be used to understand the sources of failures.<br />
* 3. Designed experiments may be used to understand the impact of various causes on the occurrence of undesirable events (see Empirical<br />
Methods and Experimental Techniques in this KA).<br />
* 4. Various kinds of correlation analyses may be used to understand the relationship between various causes and their impact. These techniques may be used in cases when conducting controlled experiments is difficult but data may be gathered (see Statistical Analysis in this KA).<br />
{{EndSection|title=Futher Readings|body=<br />
A. Abran, ''Software Metrics and Software Metrology''. [14]<br />
<br />
This book provides very good information on the<br />
proper use of the terms measure, measurement<br />
method and measurement outcome. It provides<br />
strong support material for the entire section on<br />
Measurement.<br />
<br />
W.G. Vincenti, ''What Engineers Know and How They Know It''. [15]<br />
<br />
This book provides an interesting introduction<br />
to engineering foundations through a series<br />
of case studies that show many of the foundational<br />
concepts as used in real world engineering<br />
applications.}}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=844Chapter 15: Engineering Foundations2015-08-29T06:03:58Z<p>Daniel Robbins: /* Levels (Scales) of Measurement */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any point on this line and a fixed interior point called the center is constant''. <br />
We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.<br />
<br />
The importance of operational definitions<br />
can hardly be overstated. Take the case of the<br />
apparently simple measurement of height of<br />
individuals. Unless we specify various factors<br />
like the time when the height will be measured<br />
(it is known that the height of individuals vary<br />
across various time points of the day), how the<br />
variability due to hair would be taken care of,<br />
whether the measurement will be with or without<br />
shoes, what kind of accuracy is expected (correct<br />
up to an inch, 1/2 inch, centimeter, etc.) — even this simple measurement will lead to substantial<br />
variation. Engineers must appreciate the need to<br />
define measures from an operational perspective.<br />
<br />
===Levels (Scales) of Measurement===<br />
{{RightSection| {{referenceLink|number=4|parts=c3s2}} {{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Once the operational definitions are determined,<br />
the actual measurements need to be undertaken.<br />
It is to be noted that measurement may be carried<br />
out in four different scales: namely, nominal,<br />
ordinal, interval, and ratio. Brief descriptions of<br />
each are given below.<br />
<br />
''Nominal scale'': This is the lowest level of measurement<br />
and represents the most unrestricted<br />
assignment of numerals. The numerals serve only<br />
as labels, and words or letters would serve as well.<br />
The nominal scale of measurement involves only<br />
classification and the observed sampling units<br />
are put into any one of the mutually exclusive<br />
and collectively exhaustive categories (classes).<br />
Some examples of nominal scales are:<br />
<br />
* Job titles in a company<br />
* The software development life cycle (SDLC) model (like waterfall, iterative, agile, etc.) followed by different software projects<br />
<br />
In nominal scale, the names of the different categories<br />
are just labels and no relationship between<br />
them is assumed. The only operations that can be<br />
carried out on nominal scale is that of counting<br />
the number of occurrences in the different classes<br />
and determining if two occurrences have the same<br />
nominal value. However, statistical analyses may<br />
be carried out to understand how entities belonging<br />
to different classes perform with respect to<br />
some other response variable.<br />
<br />
''Ordinal scale'': Refers to the measurement scale<br />
where the different values obtained through the<br />
process of measurement have an implicit ordering.<br />
The intervals between values are not specified<br />
and there is no objectively defined zero<br />
element. Typical examples of measurements in<br />
ordinal scales are:<br />
<br />
* Skill levels (low, medium, high)<br />
* Capability Maturity Model Integration (CMMI) maturity levels of software development organizations<br />
* Level of adherence to process as measured in a 5-point scale of excellent, above average, average, below average, and poor, indicating<br />
the range from total adherence to no adherence at all<br />
<br />
Measurement in ordinal scale satisfies the transitivity<br />
property in the sense that if A > B and B<br />
> C, then A > C. However, arithmetic operations<br />
cannot be carried out on variables measured in<br />
ordinal scales. Thus, if we measure customer satisfaction<br />
on a 5-point ordinal scale of 5 implying<br />
a very high level of satisfaction and 1 implying a<br />
very high level of dissatisfaction, we cannot say<br />
that a score of four is twice as good as a score<br />
of two. So, it is better to use terminology such<br />
as excellent, above average, average, below average,<br />
and poor than ordinal numbers in order to<br />
avoid the error of treating an ordinal scale as a<br />
ratio scale. It is important to note that ordinal<br />
scale measures are commonly misused and such<br />
misuse can lead to erroneous conclusions [6*,<br />
p274]. A common misuse of ordinal scale measures<br />
is to present a mean and standard deviation<br />
for the data set, both of which are meaningless.<br />
However, we can find the median, as computation<br />
of the median involves counting only.<br />
<br />
''Interval scales'': With the interval scale, we<br />
come to a form that is quantitative in the ordinary<br />
sense of the word. Almost all the usual statistical<br />
measures are applicable here, unless they<br />
require knowledge of a ''true' zero point. The zero<br />
point on an interval scale is a matter of convention.<br />
Ratios do not make sense, but the difference<br />
between levels of attributes can be computed and<br />
is meaningful. Some examples of interval scale of<br />
measurement follow:<br />
<br />
* Measurement of temperature in different scales, such as Celsius and Fahrenheit. Suppose T<sub>1</sub> and T<sub>2</sub> are temperatures measured in some scale. We note that the fact that T<sub>1</sub> is twice T<sub>2</sub> does not mean that one object is twice as hot as another. We also note that the zero points are arbitrary.<br />
* Calendar dates. While the difference between dates to measure the time elapsed is a meaningful concept, the ratio does not make sense.<br />
* Many psychological measurements aspire to create interval scales. Intelligence is often measured in interval scale, as it is not necessary to define what zero intelligence would mean.<br />
<br />
If a variable is measured in interval scale, most<br />
of the usual statistical analyses like mean, standard<br />
deviation, correlation, and regression may<br />
be carried out on the measured values.<br />
<br />
''Ratio scale'': These are quite commonly encountered<br />
in physical science. These scales of measures<br />
are characterized by the fact that operations<br />
exist for determining all 4 relations: equality, rank<br />
order, equality of intervals, and equality of ratios.<br />
Once such a scale is available, its numerical values<br />
can be transformed from one unit to another<br />
by just multiplying by a constant, e.g., conversion<br />
of inches to feet or centimeters. When measurements<br />
are being made in ratio scale, existence of<br />
a nonarbitrary zero is mandatory. All statistical<br />
measures are applicable to ratio scale; logarithm<br />
usage is valid only when these scales are used, as<br />
in the case of decibels. Some examples of ratio<br />
measures are<br />
<br />
* the number of statements in a software program<br />
* temperature measured in the Kelvin (K) scale or in Fahrenheit (F).<br />
<br />
An additional measurement scale, the absolute<br />
scale, is a ratio scale with uniqueness of the measure;<br />
i.e., a measure for which no transformation<br />
is possible (for example, the number of programmers<br />
working on a project).<br />
<br />
===Direct and Derived Measures===<br />
{{RightSection|{{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Measures may be either direct or derived (sometimes<br />
called indirect measures). An example of<br />
a direct measure would be a count of how many<br />
times an event occurred, such as the number of<br />
defects found in a software product. A derived<br />
measure is one that combines direct measures in<br />
some way that is consistent with the measurement<br />
method. An example of a derived measure would<br />
be calculating the productivity of a team as the<br />
number of lines of code developed per developermonth.<br />
In both cases, the measurement method<br />
determines how to make the measurement.<br />
<br />
===Reliability and Validity===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s4, c3s5}}}}<br />
<br />
A basic question to be asked for any measurement<br />
method is whether the proposed measurement<br />
method is truly measuring the concept with<br />
good quality. Reliability and validity are the two<br />
most important criteria to address this question.<br />
<br />
The reliability of a measurement method is<br />
the extent to which the application of the measurement<br />
method yields consistent measurement<br />
results. Essentially, ''reliability'' refers to the consistency<br />
of the values obtained when the same item<br />
is measured a number of times. When the results<br />
agree with each other, the measurement method<br />
is said to be reliable. Reliability usually depends<br />
on the operational definition. It can be quantified<br />
by using the index of variation, which is computed<br />
as the ratio between the standard deviation<br />
and the mean. The smaller the index, the more<br />
reliable the measurement results.<br />
<br />
''Validity'' refers to whether the measurement<br />
method really measures what we intend to measure.<br />
Validity of a measurement method may<br />
be looked at from three different perspectives:<br />
namely, construct validity, criteria validity, and<br />
content validity.<br />
<br />
===Assessing Reliability===<br />
{{RightSection|{{referenceLink|number=4|parts=c3s5}}}}<br />
<br />
There are several methods for assessing reliability;<br />
these include the test-retest method, the<br />
alternative form method, the split-halves method,<br />
and the internal consistency method. The easiest<br />
of these is the test-retest method. In the testretest<br />
method, we simply apply the measurement<br />
method to the same subjects twice. The correlation<br />
coefficient between the first and second set<br />
of measurement results gives the reliability of the<br />
measurement method.<br />
<br />
==Engineering Design==<br />
{{RightSection|{{referenceLink|number=5|parts=c1s2, c1s3, c1s4}}}}<br />
<br />
A product’s life cycle costs are largely influenced<br />
by the design of the product. This is true for manufactured<br />
products as well as for software products.<br />
<br />
The design of a software product is guided by<br />
the features to be included and the quality attributes<br />
to be provided. It is important to note that<br />
software engineers use the term “design” within<br />
their own context; while there are some commonalities,<br />
there are also many differences between<br />
engineering design as discussed in this section<br />
and software engineering design as discussed in<br />
the Software Design KA. The scope of engineering<br />
design is generally viewed as much broader<br />
than that of software design. The primary aim of<br />
this section is to identify the concepts needed to<br />
develop a clear understanding regarding the process<br />
of engineering design.<br />
<br />
Many disciplines engage in problem solving<br />
activities where there is a single correct solution.<br />
In engineering, most problems have many<br />
solutions and the focus is on finding a feasible<br />
solution (among the many alternatives) that<br />
best meets the needs presented. The set of possible<br />
solutions is often constrained by explicitly<br />
imposed limitations such as cost, available<br />
resources, and the state of discipline or domain<br />
knowledge. In engineering problems, sometimes<br />
there are also implicit constraints (such as the<br />
physical properties of materials or laws of physics)<br />
that also restrict the set of feasible solutions<br />
for a given problem.<br />
<br />
===Engineering Design in Engineering Education===<br />
<br />
The importance of engineering design in engineering<br />
education can be clearly seen by the high<br />
expectations held by various accreditation bodies<br />
for engineering education. Both the Canadian<br />
Engineering Accreditation Board and the<br />
Accreditation Board for Engineering and Technology<br />
(ABET) note the importance of including<br />
engineering design in education programs.<br />
<br />
The Canadian Engineering Accreditation<br />
Board includes requirements for the amount of<br />
engineering design experience/coursework that<br />
is necessary for engineering students as well as<br />
qualifications for the faculty members who teach<br />
such coursework or supervise design projects.<br />
Their accreditation criteria states:<br />
<br />
* Design: An ability to design solutions for complex, open-ended engineering problems and to design systems, components or processes that meet specified needs with appropriate attention to health and safety risks, applicable standards, and economic, environmental, cultural and societal considerations. [8, p12]<br />
<br />
In a similar manner, ABET defines engineering<br />
design as<br />
<br />
* the process of devising a system, component, or process to meet desired needs. It is a decision-making process (often iterative), in which the basic sciences, mathematics, and the engineering sciences are applied to convert resources optimally to meet these stated needs. [9, p4]<br />
<br />
Thus, it is clear that engineering design is a<br />
vital component in the training and education for<br />
all engineers. The remainder of this section will<br />
focus on various aspects of engineering design.<br />
<br />
===Design as a Problem Solving Activity===<br />
{{RightSection|{{referenceLink|number=5|parts=c1s4, c2s1, c3s3}}}}<br />
<br />
It is to be noted that engineering design is primarily<br />
a problem solving activity. Design problems<br />
are open ended and more vaguely defined. There<br />
are usually several alternative ways to solve the<br />
same problem. Design is generally considered to<br />
be a ''wicked problem'' —a term first coined by Horst<br />
Rittel in the 1960s when design methods were a<br />
subject of intense interest. Rittel sought an alternative<br />
to the linear, step-by-step model of the design<br />
process being explored by many designers and<br />
design theorists and argued that most of the problems<br />
addressed by the designers are wicked problems.<br />
As explained by Steve McConnell, a wicked<br />
problem is one that could be clearly defined only<br />
by solving it or by solving part of it. This paradox<br />
implies, essentially, that a wicked problem has to<br />
be solved once in order to define it clearly and then<br />
solved again to create a solution that works. This<br />
has been an important insight for software designers<br />
for several decades [10*, c5s1].<br />
<br />
===Steps Involved in Engineering Design===<br />
{{RightSection|{{referenceLink|number=7|parts=c4}}}}<br />
<br />
Engineering problem solving begins when a<br />
need is recognized and no existing solution will<br />
meet that need. As part of this problem solving,<br />
the design goals to be achieved by the solution<br />
should be identified. Additionally, a set of acceptance<br />
criteria must be defined and used to determine<br />
how well a proposed solution will satisfy<br />
the need. Once a need for a solution to a problem<br />
has been identified, the process of engineering<br />
design has the following generic steps:<br />
<br />
* a) define the problem<br />
* b) gather pertinent information<br />
* c) generate multiple solutions<br />
* d) analyze and select a solution<br />
* e) implement the solution<br />
<br />
All of the engineering design steps are iterative,<br />
and knowledge gained at any step in the<br />
process may be used to inform earlier tasks and<br />
trigger an iteration in the process. These steps are<br />
expanded in the subsequent sections<br />
<br />
''a''. ''Define the problem''. <br />
<br />
At this stage, the customer’s<br />
requirements are gathered. Specific information<br />
about product functions and features are also<br />
closely examined. This step includes refining the<br />
problem statement to identify the real problem to<br />
be solved and setting the design goals and criteria<br />
for success.<br />
<br />
The problem definition is a crucial stage in<br />
engineering design. A point to note is that this<br />
step is deceptively simple. Thus, enough care<br />
must be taken to carry out this step judiciously. It<br />
is important to identify needs and link the success<br />
criteria with the required product characteristics.<br />
It is also an engineering task to limit the scope<br />
of a problem and its solution through negotiation<br />
among the stakeholders.<br />
<br />
''b''. ''Gather pertinent information''.<br />
<br />
At this stage,<br />
the designer attempts to expand his/her knowledge<br />
about the problem. This is a vital, yet often<br />
neglected, stage. Gathering pertinent information<br />
can reveal facts leading to a redefinition of the problem—in particular, mistakes and false starts<br />
may be identified. This step may also involve the<br />
decomposition of the problem into smaller, more<br />
easily solved subproblems.<br />
<br />
While gathering pertinent information, care<br />
must be taken to identify how a product may be<br />
used as well as misused. It is also important to<br />
understand the perceived value of the product/<br />
service being offered. Included in the pertinent<br />
information is a list of constraints that must be<br />
satisfied by the solution or that may limit the set<br />
of feasible solutions.<br />
<br />
''c''. ''Generate multiple solutions''.<br />
<br />
During this stage,<br />
different solutions to the same problem are developed.<br />
It has already been stated that design problems<br />
have multiple solutions. The goal of this<br />
step is to conceptualize multiple possible solutions<br />
and refine them to a sufficient level of detail<br />
that a comparison can be done among them.<br />
<br />
''d''. ''Analyze and select a solution''.<br />
<br />
Once alternative<br />
solutions have been identified, they need to be analyzed<br />
to identify the solution that best suits the current<br />
situation. The analysis includes a functional<br />
analysis to assess whether the proposed design<br />
would meet the functional requirements. Physical<br />
solutions that involve human users often include<br />
analysis of the ergonomics or user friendliness of<br />
the proposed solution. Other aspects of the solution—<br />
such as product safety and liability, an economic<br />
or market analysis to ensure a return (profit)<br />
on the solution, performance predictions and analysis<br />
to meet quality characteristics, opportunities<br />
for incorrect data input or hardware malfunctions,<br />
and so on—may be studied. The types and amount<br />
of analysis used on a proposed solution are dependent<br />
on the type of problem and the needs that the<br />
solution must address as well as the constraints<br />
imposed on the design.<br />
<br />
''e''. ''Implement the solution''.<br />
<br />
The final phase of the<br />
design process is implementation. Implementation<br />
refers to development and testing of the<br />
proposed solution. Sometimes a preliminary,<br />
partial solution called a ''prototype'' may be developed<br />
initially to test the proposed design solution<br />
under certain conditions. Feedback resulting<br />
from testing a prototype may be used either to refine the design or drive the selection of an alternative<br />
design solution. One of the most important<br />
activities in design is documentation of the<br />
design solution as well as of the tradeoffs for the<br />
choices made in the design of the solution. This<br />
work should be carried out in a manner such that<br />
the solution to the design problem can be communicated<br />
clearly to others.<br />
<br />
The testing and verification take us back to the<br />
success criteria. The engineer needs to devise<br />
tests such that the ability of the design to meet the<br />
success criteria is demonstrated. While designing<br />
the tests, the engineer must think through<br />
different possible failure modes and then design<br />
tests based on those failure modes. The engineer<br />
may choose to carry out designed experiments to<br />
assess the validity of the design.<br />
<br />
==Modeling, Simulation, and Prototyping==<br />
{{RightSection|{{referenceLink|number=5|parts=c6}} {{referenceLink|number=11|parts=c13s3}} {{referenceLink|number=12|parts=c2s3.1}}}}<br />
<br />
Modeling is part of the abstraction process used<br />
to represent some aspects of a system. Simulation<br />
uses a model of the system and provides a<br />
means of conducting designed experiments with<br />
that model to better understand the system, its<br />
behavior, and relationships between subsystems,<br />
as well as to analyze aspects of the design. Modeling<br />
and simulation are techniques that can be<br />
used to construct theories or hypotheses about the<br />
behavior of the system; engineers then use those<br />
theories to make predictions about the system.<br />
Prototyping is another abstraction process where<br />
a partial representation (that captures aspects of<br />
interest) of the product or system is built. A prototype<br />
may be an initial version of the system but<br />
lacks the full functionality of the final version.<br />
<br />
===Modeling===<br />
<br />
A model is always an abstraction of some real<br />
or imagined artifact. Engineers use models in<br />
many ways as part of their problem solving<br />
activities. Some models are physical, such as a<br />
made-to-scale miniature construction of a bridge<br />
or building. Other models may be nonphysical<br />
representations, such as a CAD drawing of a cog<br />
or a mathematical model for a process. Models<br />
help engineers reason and understand aspects of a problem. They can also help engineers understand<br />
what they do know and what they don’t<br />
know about the problem at hand.<br />
<br />
There are three types of models: iconic, analogic,<br />
and symbolic. An iconic model is a visually<br />
equivalent but incomplete 2-dimensional<br />
or 3-dimensional representation—for example,<br />
maps, globes, or built-to-scale models of structures<br />
such as bridges or highways. An iconic<br />
model actually resembles the artifact modeled.<br />
<br />
In contrast, an analogic model is a functionally<br />
equivalent but incomplete representation. That<br />
is, the model behaves like the physical artifact<br />
even though it may not physically resemble it.<br />
Examples of analogic models include a miniature<br />
airplane for wind tunnel testing or a computer<br />
simulation of a manufacturing process.<br />
<br />
Finally, a symbolic model is a higher level of<br />
abstraction, where the model is represented using<br />
symbols such as equations. The model captures<br />
the relevant aspects of the process or system in<br />
symbolic form. The symbols can then be used to<br />
increase the engineer’s understanding of the final<br />
system. An example is an equation such as F = Ma. Such mathematical models can be used to<br />
describe and predict properties or behavior of the<br />
final system or product.<br />
<br />
===Simulation===<br />
<br />
All simulation models are a specification of reality.<br />
A central issue in simulation is to abstract<br />
and specify an appropriate simplification of<br />
reality. Developing this abstraction is of vital<br />
importance, as misspecification of the abstraction<br />
would invalidate the results of the simulation<br />
exercise. Simulation can be used for a variety of<br />
testing purposes.<br />
<br />
Simulation is classified based on the type of<br />
system under study. Thus, simulation can be either<br />
continuous or discrete. In the context of software<br />
engineering, the emphasis will be primarily on<br />
discrete simulation. Discrete simulations may<br />
model event scheduling or process interaction.<br />
The main components in such a model include<br />
entities, activities and events, resources, the state<br />
of the system, a simulation clock, and a random<br />
number generator. Output is generated by the<br />
simulation and must be analyzed.<br />
<br />
An important problem in the development of a<br />
discrete simulation is that of initialization. Before<br />
a simulation can be run, the initial values of all<br />
the state variables must be provided. As the simulation<br />
designer may not know what initial values<br />
are appropriate for the state variables, these values<br />
might be chosen somewhat arbitrarily. For<br />
instance, it might be decided that a queue should<br />
be initialized as empty and idle. Such a choice of<br />
initial condition can have a significant but unrecognized<br />
impact on the outcome of the simulation.<br />
<br />
===Prototyping===<br />
<br />
Constructing a prototype of a system is another<br />
abstraction process. In this case, an initial version<br />
of the system is constructed, often while the system<br />
is being designed. This helps the designers<br />
determine the feasibility of their design.<br />
<br />
There are many uses for a prototype, including<br />
the elicitation of requirements, the design and<br />
refinement of a user interface to the system, validation<br />
of functional requirements, and so on. The<br />
objectives and purposes for building the prototype<br />
will determine its construction and the level<br />
of abstraction used.<br />
<br />
The role of prototyping is somewhat different<br />
between physical systems and software. With<br />
physical systems, the prototype may actually<br />
be the first fully functional version of a system<br />
or it may be a model of the system. In software<br />
engineering, prototypes are also an abstract<br />
model of part of the software but are usually not<br />
constructed with all of the architectural, performance,<br />
and other quality characteristics expected<br />
in the finished product. In either case, prototype<br />
construction must have a clear purpose and be<br />
planned, monitored, and controlled—it is a technique<br />
to study a specific problem within a limited<br />
context [6*, c2s8].<br />
<br />
In conclusion, modeling, simulation, and prototyping<br />
are powerful techniques for studying the<br />
behavior of a system from a given perspective.<br />
All can be used to perform designed experiments<br />
to study various aspects of the system. However,<br />
these are abstractions and, as such, may not<br />
model all attributes of interest.<br />
<br />
==Standards==<br />
{{RightSection|{{referenceLink|number=5|parts=c9s3.2}} {{referenceLink|number=13|parts=c1s2}}}}<br />
<br />
Moore states that a<br />
<br />
* standard can be;<br />
** (a) an object or measure of comparison that defines or represents the magnitude of a unit;<br />
** (b) a characterization that establishes allowable tolerances for categories of items;<br />
** and (c) a degree or level of required excellence or attainment.<br />
* Standards are definitional in nature, established either to further understanding and interaction or to acknowledge observed (or<br />
desired) norms of exhibited characteristics or behavior. [13*, p8]<br />
<br />
Standards provide requirements, specifications,<br />
guidelines, or characteristics that must be<br />
observed by engineers so that the products, processes,<br />
and materials have acceptable levels of<br />
quality. The qualities that various standards provide<br />
may be those of safety, reliability, or other<br />
product characteristics. Standards are considered<br />
critical to engineers and engineers are expected to<br />
be familiar with and to use the appropriate standards<br />
in their discipline.<br />
<br />
Compliance or conformance to a standard lets<br />
an organization say to the public that they (or<br />
their products) meet the requirements stated in<br />
that standard. Thus, standards divide organizations<br />
or their products into those that conform to<br />
the standard and those that do not. For a standard<br />
to be useful, conformance with the standard must<br />
add value—real or perceived—to the product,<br />
process, or effort.<br />
<br />
Apart from the organizational goals, standards<br />
are used for a number of other purposes such<br />
as protecting the buyer, protecting the business,<br />
and better defining the methods and procedures<br />
to be followed by the practice. Standards also<br />
provide users with a common terminology and<br />
expectations.<br />
<br />
There are many internationally recognized<br />
standards-making organizations including the<br />
International Telecommunications Union (ITU),<br />
the International Electrotechnical Commission<br />
(IEC), IEEE, and the International Organization<br />
for Standardization (ISO). In addition, there are regional and governmentally recognized organizations<br />
that generate standards for that region or<br />
country. For example, in the United States, there<br />
are over 300 organizations that develop standards.<br />
These include organizations such as the<br />
American National Standards Institute (ANSI),<br />
the American Society for Testing and Materials<br />
(ASTM), the Society of Automotive Engineers<br />
(SAE), and Underwriters Laboratories, Inc. (UL),<br />
as well as the US government. For more detail<br />
on standards used in software engineering, see<br />
Appendix B on standards.<br />
<br />
There is a set of commonly used principles<br />
behind standards. Standards makers attempt to<br />
have consensus around their decisions. There is<br />
usually an openness within the community of<br />
interest so that once a standard has been set, there<br />
is a good chance that it will be widely accepted.<br />
Most standards organizations have well-defined<br />
processes for their efforts and adhere to those<br />
processes carefully. Engineers must be aware of<br />
the existing standards but must also update their<br />
understanding of the standards as those standards<br />
change over time.<br />
<br />
In many engineering endeavors, knowing and<br />
understanding the applicable standards is critical<br />
and the law may even require use of particular<br />
standards. In these cases, the standards often represent<br />
minimal requirements that must be met by<br />
the endeavor and thus are an element in the constraints<br />
imposed on any design effort. The engineer<br />
must review all current standards related to<br />
a given endeavor and determine which must be<br />
met. Their designs must then incorporate any and<br />
all constraints imposed by the applicable standard.<br />
Standards important to software engineers<br />
are discussed in more detail in an appendix specifically<br />
on this subject.<br />
<br />
==Root Cause Analysis==<br />
{{RightSection|{{referenceLink|number=4|parts=c5, c3s7, c9s8}} {{referenceLink|number=5|parts=c9s3, c9s4, c9s5}} {{referenceLink|number=13|parts=c13s3.4.5}}}}<br />
<br />
Root cause analysis (RCA) is a process designed<br />
to investigate and identify why and how an<br />
undesirable event has happened. Root causes<br />
are underlying causes. The investigator should<br />
attempt to identify specific underlying causes of<br />
the event that has occurred. The primary objective of RCA is to prevent recurrence of the undesirable<br />
event. Thus, the more specific the investigator<br />
can be about why an event occurred, the easier<br />
it will be to prevent recurrence. A common way<br />
to identify specific underlying cause(s) is to ask a<br />
series of ''why'' questions.<br />
<br />
===Techniques for Conducting Root Cause Analysis===<br />
{{RightSection|{{referenceLink|number=4|parts=c5}} {{referenceLink|number=5|parts=c3}}}}<br />
<br />
There are many approaches used for both quality<br />
control and root cause analysis. The first step in<br />
any root cause analysis effort is to identify the real<br />
problem. Techniques such as statement-restatement,<br />
why-why diagrams, the revision method,<br />
present state and desired state diagrams, and the<br />
fresh-eye approach are used to identify and refine<br />
the real problem that needs to be addressed.<br />
<br />
Once the real problem has been identified, then<br />
work can begin to determine the cause of the<br />
problem. Ishikawa is known for the seven tools<br />
for quality control that he promoted. Some of<br />
those tools are helpful in identifying the causes<br />
for a given problem. Those tools are check sheets<br />
or checklists, Pareto diagrams, histograms, run<br />
charts, scatter diagrams, control charts, and<br />
fishbone or cause-and-effect diagrams. More<br />
recently, other approaches for quality improvement<br />
and root cause analysis have emerged. Some<br />
examples of these newer methods are affinity diagrams,<br />
relations diagrams, tree diagrams, matrix<br />
charts, matrix data analysis charts, process decision<br />
program charts, and arrow diagrams. A few<br />
of these techniques are briefly described below.<br />
<br />
A fishbone or cause-and-effect diagram is a<br />
way to visualize the various factors that affect<br />
some characteristic. The main line in the diagram<br />
represents the problem and the connecting lines<br />
represent the factors that led to or influenced the<br />
problem. Those factors are broken down into subfactors<br />
and sub-subfactors until root causes can<br />
be identified.<br />
<br />
A very simple approach that is useful in quality<br />
control is the use of a checklist. Checklists are<br />
a list of key points in a process with tasks that<br />
must be completed. As each task is completed,<br />
it is checked off the list. If a problem occurs,<br />
then sometimes the checklist can quickly identify<br />
tasks that may have been skipped or only partially<br />
completed.<br />
<br />
Finally, relations diagrams are a means for displaying<br />
complex relationships. They give visual<br />
support to cause-and-effect thinking. The diagram<br />
relates the specific to the general, revealing<br />
key causes and key effects.<br />
<br />
Root cause analysis aims at preventing the<br />
recurrence of undesirable events. Reduction of<br />
variation due to common causes requires utilization<br />
of a number of techniques. An important<br />
point to note is that these techniques should be<br />
used offline and not necessarily in direct response<br />
to the occurrence of some undesirable event.<br />
Some of the techniques that may be used to<br />
reduce variation due to common causes are given<br />
below.<br />
<br />
* 1. Cause-and-effect diagrams may be used to identify the sub and sub-sub causes.<br />
* 2. Fault tree analysis is a technique that may be used to understand the sources of failures.<br />
* 3. Designed experiments may be used to understand the impact of various causes on the occurrence of undesirable events (see Empirical<br />
Methods and Experimental Techniques in this KA).<br />
* 4. Various kinds of correlation analyses may be used to understand the relationship between various causes and their impact. These techniques may be used in cases when conducting controlled experiments is difficult but data may be gathered (see Statistical Analysis in this KA).</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=843Chapter 15: Engineering Foundations2015-08-29T05:25:03Z<p>Daniel Robbins: /* Levels (Scales) of Measurement */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any point on this line and a fixed interior point called the center is constant''. <br />
We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.<br />
<br />
The importance of operational definitions<br />
can hardly be overstated. Take the case of the<br />
apparently simple measurement of height of<br />
individuals. Unless we specify various factors<br />
like the time when the height will be measured<br />
(it is known that the height of individuals vary<br />
across various time points of the day), how the<br />
variability due to hair would be taken care of,<br />
whether the measurement will be with or without<br />
shoes, what kind of accuracy is expected (correct<br />
up to an inch, 1/2 inch, centimeter, etc.) — even this simple measurement will lead to substantial<br />
variation. Engineers must appreciate the need to<br />
define measures from an operational perspective.<br />
<br />
===Levels (Scales) of Measurement===<br />
{{RightSection| {{referenceLink|number=4|parts=c3s2}} {{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Once the operational definitions are determined,<br />
the actual measurements need to be undertaken.<br />
It is to be noted that measurement may be carried<br />
out in four different scales: namely, nominal,<br />
ordinal, interval, and ratio. Brief descriptions of<br />
each are given below.<br />
<br />
''Nominal scale'': This is the lowest level of measurement<br />
and represents the most unrestricted<br />
assignment of numerals. The numerals serve only<br />
as labels, and words or letters would serve as well.<br />
The nominal scale of measurement involves only<br />
classification and the observed sampling units<br />
are put into any one of the mutually exclusive<br />
and collectively exhaustive categories (classes).<br />
Some examples of nominal scales are:<br />
<br />
* Job titles in a company<br />
* The software development life cycle (SDLC) model (like waterfall, iterative, agile, etc.) followed by different software projects<br />
<br />
In nominal scale, the names of the different categories<br />
are just labels and no relationship between<br />
them is assumed. The only operations that can be<br />
carried out on nominal scale is that of counting<br />
the number of occurrences in the different classes<br />
and determining if two occurrences have the same<br />
nominal value. However, statistical analyses may<br />
be carried out to understand how entities belonging<br />
to different classes perform with respect to<br />
some other response variable.<br />
<br />
''Ordinal scale'': Refers to the measurement scale<br />
where the different values obtained through the<br />
process of measurement have an implicit ordering.<br />
The intervals between values are not specified<br />
and there is no objectively defined zero<br />
element. Typical examples of measurements in<br />
ordinal scales are:<br />
<br />
* Skill levels (low, medium, high)<br />
* Capability Maturity Model Integration (CMMI) maturity levels of software development organizations<br />
* Level of adherence to process as measured in a 5-point scale of excellent, above average, average, below average, and poor, indicating<br />
the range from total adherence to no adherence at all<br />
<br />
Measurement in ordinal scale satisfies the transitivity<br />
property in the sense that if A > B and B<br />
> C, then A > C. However, arithmetic operations<br />
cannot be carried out on variables measured in<br />
ordinal scales. Thus, if we measure customer satisfaction<br />
on a 5-point ordinal scale of 5 implying<br />
a very high level of satisfaction and 1 implying a<br />
very high level of dissatisfaction, we cannot say<br />
that a score of four is twice as good as a score<br />
of two. So, it is better to use terminology such<br />
as excellent, above average, average, below average,<br />
and poor than ordinal numbers in order to<br />
avoid the error of treating an ordinal scale as a<br />
ratio scale. It is important to note that ordinal<br />
scale measures are commonly misused and such<br />
misuse can lead to erroneous conclusions [6*,<br />
p274]. A common misuse of ordinal scale measures<br />
is to present a mean and standard deviation<br />
for the data set, both of which are meaningless.<br />
However, we can find the median, as computation<br />
of the median involves counting only.<br />
<br />
''Interval scales'': With the interval scale, we<br />
come to a form that is quantitative in the ordinary<br />
sense of the word. Almost all the usual statistical<br />
measures are applicable here, unless they<br />
require knowledge of a ''true' zero point. The zero<br />
point on an interval scale is a matter of convention.<br />
Ratios do not make sense, but the difference<br />
between levels of attributes can be computed and<br />
is meaningful. Some examples of interval scale of<br />
measurement follow:<br />
<br />
* Measurement of temperature in different scales, such as Celsius and Fahrenheit. Suppose T<sub>1</sub> and T<sub>2</sub> are temperatures measured in some scale. We note that the fact that T<sub>1</sub> is twice T<sub>2</sub> does not mean that one object is twice as hot as another. We also note that the zero points are arbitrary.<br />
* Calendar dates. While the difference between dates to measure the time elapsed is a meaningful concept, the ratio does not make sense.<br />
* Many psychological measurements aspire to create interval scales. Intelligence is often measured in interval scale, as it is not necessary to define what zero intelligence would mean.<br />
<br />
If a variable is measured in interval scale, most<br />
of the usual statistical analyses like mean, standard<br />
deviation, correlation, and regression may<br />
be carried out on the measured values.<br />
<br />
''Ratio scale'': These are quite commonly encountered<br />
in physical science. These scales of measures<br />
are characterized by the fact that operations<br />
exist for determining all 4 relations: equality, rank<br />
order, equality of intervals, and equality of ratios.<br />
Once such a scale is available, its numerical values<br />
can be transformed from one unit to another<br />
by just multiplying by a constant, e.g., conversion<br />
of inches to feet or centimeters. When measurements<br />
are being made in ratio scale, existence of<br />
a nonarbitrary zero is mandatory. All statistical<br />
measures are applicable to ratio scale; logarithm<br />
usage is valid only when these scales are used, as<br />
in the case of decibels. Some examples of ratio<br />
measures are<br />
<br />
* the number of statements in a software program<br />
* temperature measured in the Kelvin (K) scale or in Fahrenheit (F).<br />
<br />
An additional measurement scale, the absolute<br />
scale, is a ratio scale with uniqueness of the measure;<br />
i.e., a measure for which no transformation<br />
is possible (for example, the number of programmers<br />
working on a project).</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=842Chapter 15: Engineering Foundations2015-08-29T05:24:45Z<p>Daniel Robbins: /* Measurement */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any point on this line and a fixed interior point called the center is constant''. <br />
We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.<br />
<br />
The importance of operational definitions<br />
can hardly be overstated. Take the case of the<br />
apparently simple measurement of height of<br />
individuals. Unless we specify various factors<br />
like the time when the height will be measured<br />
(it is known that the height of individuals vary<br />
across various time points of the day), how the<br />
variability due to hair would be taken care of,<br />
whether the measurement will be with or without<br />
shoes, what kind of accuracy is expected (correct<br />
up to an inch, 1/2 inch, centimeter, etc.) — even this simple measurement will lead to substantial<br />
variation. Engineers must appreciate the need to<br />
define measures from an operational perspective.<br />
<br />
==Levels (Scales) of Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s2}} {{referenceLink|number=6|parts=c7s5}}}}<br />
<br />
Once the operational definitions are determined,<br />
the actual measurements need to be undertaken.<br />
It is to be noted that measurement may be carried<br />
out in four different scales: namely, nominal,<br />
ordinal, interval, and ratio. Brief descriptions of<br />
each are given below.<br />
<br />
''Nominal scale'': This is the lowest level of measurement<br />
and represents the most unrestricted<br />
assignment of numerals. The numerals serve only<br />
as labels, and words or letters would serve as well.<br />
The nominal scale of measurement involves only<br />
classification and the observed sampling units<br />
are put into any one of the mutually exclusive<br />
and collectively exhaustive categories (classes).<br />
Some examples of nominal scales are:<br />
<br />
* Job titles in a company<br />
* The software development life cycle (SDLC) model (like waterfall, iterative, agile, etc.) followed by different software projects<br />
<br />
In nominal scale, the names of the different categories<br />
are just labels and no relationship between<br />
them is assumed. The only operations that can be<br />
carried out on nominal scale is that of counting<br />
the number of occurrences in the different classes<br />
and determining if two occurrences have the same<br />
nominal value. However, statistical analyses may<br />
be carried out to understand how entities belonging<br />
to different classes perform with respect to<br />
some other response variable.<br />
<br />
''Ordinal scale'': Refers to the measurement scale<br />
where the different values obtained through the<br />
process of measurement have an implicit ordering.<br />
The intervals between values are not specified<br />
and there is no objectively defined zero<br />
element. Typical examples of measurements in<br />
ordinal scales are:<br />
<br />
* Skill levels (low, medium, high)<br />
* Capability Maturity Model Integration (CMMI) maturity levels of software development organizations<br />
* Level of adherence to process as measured in a 5-point scale of excellent, above average, average, below average, and poor, indicating<br />
the range from total adherence to no adherence at all<br />
<br />
Measurement in ordinal scale satisfies the transitivity<br />
property in the sense that if A > B and B<br />
> C, then A > C. However, arithmetic operations<br />
cannot be carried out on variables measured in<br />
ordinal scales. Thus, if we measure customer satisfaction<br />
on a 5-point ordinal scale of 5 implying<br />
a very high level of satisfaction and 1 implying a<br />
very high level of dissatisfaction, we cannot say<br />
that a score of four is twice as good as a score<br />
of two. So, it is better to use terminology such<br />
as excellent, above average, average, below average,<br />
and poor than ordinal numbers in order to<br />
avoid the error of treating an ordinal scale as a<br />
ratio scale. It is important to note that ordinal<br />
scale measures are commonly misused and such<br />
misuse can lead to erroneous conclusions [6*,<br />
p274]. A common misuse of ordinal scale measures<br />
is to present a mean and standard deviation<br />
for the data set, both of which are meaningless.<br />
However, we can find the median, as computation<br />
of the median involves counting only.<br />
<br />
''Interval scales'': With the interval scale, we<br />
come to a form that is quantitative in the ordinary<br />
sense of the word. Almost all the usual statistical<br />
measures are applicable here, unless they<br />
require knowledge of a ''true' zero point. The zero<br />
point on an interval scale is a matter of convention.<br />
Ratios do not make sense, but the difference<br />
between levels of attributes can be computed and<br />
is meaningful. Some examples of interval scale of<br />
measurement follow:<br />
<br />
* Measurement of temperature in different scales, such as Celsius and Fahrenheit. Suppose T<sub>1</sub> and T<sub>2</sub> are temperatures measured in some scale. We note that the fact that T<sub>1</sub> is twice T<sub>2</sub> does not mean that one object is twice as hot as another. We also note that the zero points are arbitrary.<br />
* Calendar dates. While the difference between dates to measure the time elapsed is a meaningful concept, the ratio does not make sense.<br />
* Many psychological measurements aspire to create interval scales. Intelligence is often measured in interval scale, as it is not necessary to define what zero intelligence would mean.<br />
<br />
If a variable is measured in interval scale, most<br />
of the usual statistical analyses like mean, standard<br />
deviation, correlation, and regression may<br />
be carried out on the measured values.<br />
<br />
''Ratio scale'': These are quite commonly encountered<br />
in physical science. These scales of measures<br />
are characterized by the fact that operations<br />
exist for determining all 4 relations: equality, rank<br />
order, equality of intervals, and equality of ratios.<br />
Once such a scale is available, its numerical values<br />
can be transformed from one unit to another<br />
by just multiplying by a constant, e.g., conversion<br />
of inches to feet or centimeters. When measurements<br />
are being made in ratio scale, existence of<br />
a nonarbitrary zero is mandatory. All statistical<br />
measures are applicable to ratio scale; logarithm<br />
usage is valid only when these scales are used, as<br />
in the case of decibels. Some examples of ratio<br />
measures are<br />
<br />
* the number of statements in a software program<br />
* temperature measured in the Kelvin (K) scale or in Fahrenheit (F).<br />
<br />
An additional measurement scale, the absolute<br />
scale, is a ratio scale with uniqueness of the measure;<br />
i.e., a measure for which no transformation<br />
is possible (for example, the number of programmers<br />
working on a project).</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=841Chapter 15: Engineering Foundations2015-08-29T05:12:56Z<p>Daniel Robbins: /* Measurement */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.<br />
<br />
''Operational definitions''. The definition of attributes,<br />
to start with, is often rather abstract. Such<br />
definitions do not facilitate measurements. For<br />
example, we may define a circle as a line forming<br />
''a closed loop such that the distance between any<br />
point on this line and a fixed interior point called<br />
the center is constant''. We may further say that the<br />
fixed distance from the center to any point on the<br />
closed loop gives the radius of the circle. It may be<br />
noted that though the concept has been defined, no<br />
means of measuring the radius has been proposed.<br />
The operational definition specifies the exact steps<br />
or method used to carry out a specific measurement.<br />
This can also be called the ''measurement method''; sometimes a measurement procedure may<br />
be required to be even more precise.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=840Chapter 15: Engineering Foundations2015-08-28T21:16:10Z<p>Daniel Robbins: /* Measurement */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==<br />
{{RightSection| {{referenceLink|number=4|parts=c3s1, c3s2}} {{referenceLink|number=5|parts=cc4s4}} {{referenceLink|number=6|parts=c7s5, c11s8}} {{referenceLink|number=7|parts=p442–447}}}}<br />
<br />
Knowing what to measure and which measurement<br />
method to use is critical in engineering<br />
endeavors. It is important that everyone involved<br />
in an engineering project understand the measurement<br />
methods and the measurement results<br />
that will be used.<br />
<br />
Measurements can be physical, environmental,<br />
economic, operational, or some other sort of<br />
measurement that is meaningful for the particular<br />
project. This section explores the theory of measurement<br />
and how it is fundamental to engineering.<br />
Measurement starts as a conceptualization<br />
then moves from abstract concepts to definitions<br />
of the measurement method to the actual application<br />
of that method to obtain a measurement<br />
result. Each of these steps must be understood,<br />
communicated, and properly employed in order<br />
to generate usable data. In traditional engineering,<br />
direct measures are often used. In software<br />
engineering, a combination of both direct and<br />
derived measures is necessary [6*, p273].<br />
<br />
The theory of measurement states that measurement<br />
is an attempt to describe an underlying real empirical system. Measurement methods<br />
define activities that allocate a value or a symbol<br />
to an attribute of an entity.<br />
<br />
Attributes must then be defined in terms of<br />
the operations used to identify and measure<br />
them— that is, the measurement methods. In this<br />
approach, a measurement method is defined to be<br />
a precisely specified operation that yields a number<br />
(called the ''measurement result'') when measuring<br />
an attribute. It follows that, to be useful,<br />
the measurement method has to be well defined.<br />
Arbitrariness in the method will reflect itself in<br />
ambiguity in the measurement results.<br />
<br />
In some cases—particularly in the physical<br />
world—the attributes that we wish to measure are<br />
easy to grasp; however, in an artificial world like<br />
software engineering, defining the attributes may<br />
not be that simple. For example, the attributes of<br />
height, weight, distance, etc. are easily and uniformly<br />
understood (though they may not be very<br />
easy to measure in all circumstances), whereas<br />
attributes such as software size or complexity<br />
require clear definitions.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=839Chapter 15: Engineering Foundations2015-08-28T21:07:24Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.<br />
<br />
===Concepts of Correlation and Regression===<br />
{{RightSection|{{referenceLink|number=2|parts=c11s2, c11s8}}}}<br />
<br />
A major objective of many statistical investigations<br />
is to establish relationships that make it possible<br />
to predict one or more variables in terms of<br />
others. Although it is desirable to predict a quantity<br />
exactly in terms of another quantity, it is seldom<br />
possible and, in many cases, we have to be<br />
satisfied with estimating the average or expected<br />
values.<br />
<br />
The relationship between two variables is studied<br />
using the methods of correlation and regression.<br />
Both these concepts are explained briefly in<br />
the following paragraphs.<br />
<br />
''Correlation''. The strength of linear relationship<br />
between two variables is measured using<br />
the correlation coefficient. While computing the<br />
correlation coefficient between two variables, we<br />
assume that these variables measure two different<br />
attributes of the same entity. The correlation<br />
coefficient takes a value between –1 to +1. The<br />
values –1 and +1 indicate a situation when the<br />
association between the variables is perfect—i.e., given the value of one variable, the other can be<br />
estimated with no error. A positive correlation<br />
coefficient indicates a positive relationship—that<br />
is, if one variable increases, so does the other. On<br />
the other hand, when the variables are negatively<br />
correlated, an increase of one leads to a decrease<br />
of the other.<br />
<br />
It is important to remember that correlation<br />
does not imply causation. Thus, if two variables<br />
are correlated, we cannot conclude that one<br />
causes the other.<br />
<br />
''Regression''. The correlation analysis only<br />
measures the degree of relationship between<br />
two variables. The analysis to find the relationship<br />
between two variables is called regression<br />
analysis. The strength of the relationship between<br />
two variables is measured using the coefficient of<br />
determination. This is a value between 0 and 1.<br />
The closer the coefficient is to 1, the stronger the<br />
relationship between the variables. A value of 1<br />
indicates a perfect relationship.<br />
<br />
==Measurement==</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=838Chapter 15: Engineering Foundations2015-08-28T21:01:12Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}<br />
<br />
In test of hypotheses, we aim at maximizing the<br />
power of the test (the value of 1−b) while ensuring<br />
that the probability of a type I error (the value<br />
of a) is maintained within a particular value—<br />
typically 5 percent.<br />
<br />
It is to be noted that construction of a test of<br />
hypothesis includes identifying statistic(s) to<br />
estimate the parameter(s) and defining a critical<br />
region such that if the computed value of the statistic<br />
falls in the critical region, the null hypothesis<br />
is rejected.</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=837Chapter 15: Engineering Foundations2015-08-28T20:58:47Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Reject H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=836Chapter 15: Engineering Foundations2015-08-28T20:57:39Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Accept H<sub>0</sub><br />
|-<br />
|H<sub>0</sub> is true<br />
|OK<br />
|Type I error (probability = a)<br />
|-<br />
|H<sub>0</sub> is false<br />
|Type II error (probability = b)<br />
|OK<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=835Chapter 15: Engineering Foundations2015-08-28T20:55:05Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|-<br />
|Accept H<sub>0</sub><br />
|Accept H<sub>0</sub><br />
|-<br />
|Proactive<br />
|Preventive<br />
|Perfective<br />
|-<br />
|Reactive<br />
|Corrective<br />
|Adaptive<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=834Chapter 15: Engineering Foundations2015-08-28T20:54:02Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|Accept H<sub>0</sub><br />
|Accept H<sub>0</sub><br />
|-<br />
|Proactive<br />
|Preventive<br />
|Perfective<br />
|-<br />
|Reactive<br />
|Corrective<br />
|Adaptive<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=833Chapter 15: Engineering Foundations2015-08-28T20:51:59Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|'''Nature'''<br />
!colspan="2"| '''Statistical Decision'''<br />
|<br />
|-<br />
|Proactive<br />
|Preventive<br />
|Perfective<br />
|-<br />
|Reactive<br />
|Corrective<br />
|Adaptive<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=832Chapter 15: Engineering Foundations2015-08-28T20:48:09Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!rowspan="2"|<br />
'''Nature'''<br />
|'''Statistical Decision'''<br />
|-<br />
|Proactive<br />
|Preventive<br />
|Perfective<br />
|-<br />
|Reactive<br />
|Corrective<br />
|Adaptive<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=831Chapter 15: Engineering Foundations2015-08-28T20:46:30Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!colspan="3"||'''Nature'''<br />
|'''Statistical Decision'''<br />
|-<br />
|Proactive<br />
|Preventive<br />
|Perfective<br />
|-<br />
|Reactive<br />
|Corrective<br />
|Adaptive<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=830Chapter 15: Engineering Foundations2015-08-28T20:45:33Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!colspan="3"|<br />
|'''Nature'''<br />
|'''Statistical Decision'''<br />
|-<br />
|Proactive<br />
|Preventive<br />
|Perfective<br />
|-<br />
|Reactive<br />
|Corrective<br />
|Adaptive<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=829Chapter 15: Engineering Foundations2015-08-28T20:44:23Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
!colspan="3"|<br />
|-<br />
|<br />
|'''Nature'''<br />
|'''Statistical Decision'''<br />
|-<br />
|Proactive<br />
|Preventive<br />
|Perfective<br />
|-<br />
|Reactive<br />
|Corrective<br />
|Adaptive<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=828Chapter 15: Engineering Foundations2015-08-28T19:48:26Z<p>Daniel Robbins: </p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
|'''Nature'''<br />
|'''Statistical Decision'''<br />
|-<br />
|!<br />
|!<br />
|-<br />
|<br />
|<br />
|<br />
|}</div>Daniel Robbinshttp://swebokwiki.org/index.php?title=Chapter_15:_Engineering_Foundations&diff=827Chapter 15: Engineering Foundations2015-08-28T19:33:10Z<p>Daniel Robbins: /* Unit of Analysis (Sampling Units), Population, and Sample */</p>
<hr />
<div>{{TOC}}<br />
{{Acronyms|{{Acronym|name=CAD|description=Computer-Aided Design}}<br />
{{Acronym|name=CMMI|description=Capability Maturity Model Integration}}<br />
{{Acronym|name=pdf|description=Probability Density Function}}<br />
{{Acronym|name=pmf|description=Probability Mass Function}}<br />
{{Acronym|name=RCA|description=Root Cause Analysis}}<br />
{{Acronym|name=SDLC|description=Software Development Life Cycle}}<br />
}}<br />
{{IntroSection|title=Introduction|body=<br />
IEEE defines engineering as “the application of<br />
a systematic, disciplined, quantifiable approach<br />
to structures, machines, products, systems or<br />
processes” [1]. This chapter outlines some of the<br />
engineering foundational skills and techniques<br />
that are useful for a software engineer. The focus<br />
is on topics that support other KAs while minimizing<br />
duplication of subjects covered elsewhere<br />
in this document.<br />
<br />
As the theory and practice of software engineering<br />
matures, it is increasingly apparent that<br />
software engineering is an engineering discipline<br />
that is based on knowledge and skills common<br />
to all engineering disciplines. This Engineering<br />
Foundations knowledge area (KA) is<br />
concerned with the engineering foundations that<br />
apply to software engineering and other engineering<br />
disciplines. Topics in this KA include<br />
empirical methods and experimental techniques;<br />
statistical analysis; measurement; engineering<br />
design; modeling, prototyping, and simulation;<br />
standards; and root cause analysis. Application<br />
of this knowledge, as appropriate, will allow<br />
software engineers to develop and maintain<br />
software more efficiently and effectively. Completing<br />
their engineering work efficiently and effectively is a goal of all engineers in all engineering<br />
disciplines.}}<br />
[[File:Breakdown of Topics for the Engineering Foundations KA.jpg|thumb|400px|frame|Figure 15.1: Breakdown of Topics for the Engineering Foundations KA]]<br />
{{IntroSection|title=Breakdown of Topics for the Engineering Foundations|body=<br />
The breakdown of topics for the Engineering Foundations<br />
KA is shown in Figure 15.1.}}<br />
<br />
<br />
==Empirical Methods and Experimental Techniques==<br />
{{RightSection|{{referenceLink|number=2|parts=c1}}}}<br />
<br />
An engineering method for problem solving<br />
involves proposing solutions or models of solutions<br />
and then conducting experiments or tests<br />
to study the proposed solutions or models. Thus,<br />
engineers must understand how to create an experiment<br />
and then analyze the results of the experiment<br />
in order to evaluate the proposed solution.<br />
Empirical methods and experimental techniques<br />
help the engineer to describe and understand variability<br />
in their observations, to identify the sources<br />
of variability, and to make decisions.<br />
<br />
Three different types of empirical studies commonly<br />
used in engineering efforts are designed<br />
experiments, observational studies, and retrospective<br />
studies. Brief descriptions of the commonly<br />
used methods are given below.<br />
<br />
===Designed Experiment===<br />
<br />
A designed or controlled experiment is an investigation<br />
of a testable hypothesis where one or<br />
more independent variables are manipulated to<br />
measure their effect on one or more dependent<br />
variables. A precondition for conducting an<br />
experiment is the existence of a clear hypothesis.<br />
It is important for an engineer to understand how<br />
to formulate clear hypotheses.<br />
<br />
Designed experiments allow engineers to<br />
determine in precise terms how the variables are<br />
related and, specifically, whether a cause-effect<br />
relationship exists between them. Each combination<br />
of values of the independent variables is<br />
a ''treatment''. The simplest experiments have just<br />
two treatments representing two levels of a single<br />
independent variable (e.g., using a tool vs.<br />
not using a tool). More complex experimental<br />
designs arise when more than two levels, more<br />
than one independent variable, or any dependent<br />
variables are used.<br />
<br />
===Observational Study===<br />
<br />
An observational or case study is an empirical<br />
inquiry that makes observations of processes<br />
or phenomena within a real-life context. While<br />
an experiment deliberately ignores context, an<br />
observational or case study includes context as<br />
part of the observation. A case study is most useful<br />
when the focus of the study is on ''how'' and ''why''<br />
questions, when the behavior of those involved in<br />
the study cannot be manipulated, and when contextual<br />
conditions are relevant and the boundaries<br />
between the phenomena and context are not clear.<br />
<br />
===Retrospective Study===<br />
<br />
A retrospective study involves the analysis of historical<br />
data. Retrospective studies are also known<br />
as historical studies. This type of study uses data<br />
(regarding some phenomenon) that has been<br />
archived over time. This archived data is then analyzed<br />
in an attempt to find a relationship between<br />
variables, to predict future events, or to identify<br />
trends. The quality of the analysis results will<br />
depend on the quality of the information contained<br />
in the archived data. Historical data may be incomplete,<br />
inconsistently measured, or incorrect.<br />
<br />
==Statistical Analysis==<br />
{{RightSection|{{referenceLink|number=2|parts=c9s1, c2s1}} {{referenceLink|number=3|parts=c10s3}}}}<br />
<br />
In order to carry out their responsibilities, engineers<br />
must understand how different product<br />
and process characteristics vary. Engineers often<br />
come across situations where the relationship<br />
between different variables needs to be studied.<br />
An important point to note is that most of the<br />
studies are carried out on the basis of samples<br />
and so the observed results need to be understood<br />
with respect to the full population. Engineers<br />
must, therefore, develop an adequate understanding<br />
of statistical techniques for collecting reliable<br />
data in terms of sampling and analysis to arrive at<br />
results that can be generalized. These techniques<br />
are discussed below.<br />
<br />
===Unit of Analysis (Sampling Units), Population, and Sample===<br />
<br />
''Unit of analysis''. While carrying out any empirical<br />
study, observations need to be made on chosen<br />
units called the units of analysis or sampling<br />
units. The unit of analysis must be identified and<br />
must be appropriate for the analysis. For example,<br />
when a software product company wants to<br />
find the perceived usability of a software product,<br />
the user or the software function may be the unit<br />
of analysis.<br />
<br />
''Population''. The set of all respondents or items<br />
(possible sampling units) to be studied forms the<br />
population. As an example, consider the case of<br />
studying the perceived usability of a software<br />
product. In this case, the set of all possible users<br />
forms the population.<br />
<br />
While defining the population, care must be<br />
exercised to understand the study and target<br />
population. There are cases when the population<br />
studied and the population for which the results are being generalized may be different.<br />
For example, when the study population consists<br />
of only past observations and generalizations are<br />
required for the future, the study population and<br />
the target population may not be the same.<br />
<br />
''Sample''. A sample is a subset of the population.<br />
The most crucial issue towards the selection of<br />
a sample is its representativeness, including size.<br />
The samples must be drawn in a manner so as<br />
to ensure that the draws are independent, and<br />
the rules of drawing the samples must be predefined<br />
so that the probability of selecting a particular<br />
sampling unit is known beforehand. This<br />
method of selecting samples is called ''probability sampling''.<br />
<br />
''Random variable''. In statistical terminology,<br />
the process of making observations or measurements<br />
on the sampling units being studied is<br />
referred to as conducting the experiment. For<br />
example, if the experiment is to toss a coin 10<br />
times and then count the number of times the<br />
coin lands on heads, each 10 tosses of the coin<br />
is a sampling unit and the number of heads for a<br />
given sample is the observation or outcome for<br />
the experiment. The outcome of an experiment is<br />
obtained in terms of real numbers and defines the<br />
random variable being studied. Thus, the attribute<br />
of the items being measured at the outcome of<br />
the experiment represents the random variable<br />
being studied; the observation obtained from a<br />
particular sampling unit is a particular realization<br />
of the random variable. In the example of the coin<br />
toss, the random variable is the number of heads<br />
observed for each experiment. In statistical studies,<br />
attempts are made to understand population<br />
characteristics on the basis of samples.<br />
<br />
The set of possible values of a random variable<br />
may be finite or infinite but countable (e.g., the<br />
set of all integers or the set of all odd numbers).<br />
In such a case, the random variable is called a ''discrete random variable''. In other cases, the random<br />
variable under consideration may take values on<br />
a continuous scale and is called a ''continuous random variable''.<br />
<br />
''Event''. A subset of possible values of a random<br />
variable is called an event. Suppose X denotes<br />
some random variable; then, for example, we<br />
may define different events such as X ³ x or X <<br />
x and so on.<br />
<br />
''Distribution of a random variable''. The range<br />
and pattern of variation of a random variable is<br />
given by its distribution. When the distribution<br />
of a random variable is known, it is possible to<br />
compute the chance of any event. Some distributions<br />
are found to occur commonly and are used<br />
to model many random variables occurring in<br />
practice in the context of engineering. A few of<br />
the more commonly occurring distributions are<br />
given below.<br />
<br />
* Binomial distribution: used to model random variables that count the number of successes in ''n'' trials carried out independently of each other, where each trial results in success or failure. We make an assumption that the chance of obtaining a success remains constant [2*, c3s6].<br />
* Poisson distribution: used to model the count of occurrence of some event over time or space [2*, c3s9].<br />
* Normal distribution: used to model continuous random variables or discrete random variables by taking a very large number of values [2*, c4s6].<br />
<br />
''Concept of parameters''. A statistical distribution<br />
is characterized by some parameters. For example,<br />
the proportion of success in any given trial<br />
is the only parameter characterizing a binomial<br />
distribution. Similarly, the Poisson distribution is<br />
characterized by a rate of occurrence. A normal<br />
distribution is characterized by two parameters:<br />
namely, its mean and standard deviation.<br />
<br />
Once the values of the parameters are known,<br />
the distribution of the random variable is completely<br />
known and the chance (probability) of<br />
any event can be computed. The probabilities<br />
for a discrete random variable can be computed<br />
through the probability mass function, called<br />
the pmf. The pmf is defined at discrete points<br />
and gives the point mass—i.e., the probability<br />
that the random variable will take that particular<br />
value. Likewise, for a continuous random variable,<br />
we have the probability density function,<br />
called the pdf. The pdf is very much like density<br />
and needs to be integrated over a range to obtain<br />
the probability that the continuous random variable<br />
lies between certain values. Thus, if the pdf or pmf is known, the chances of the random variable<br />
taking certain set of values may be computed<br />
theoretically.<br />
<br />
''Concept of estimation'' [2*, c6s2, c7s1, c7s3].<br />
The true values of the parameters of a distribution<br />
are usually unknown and need to be estimated<br />
from the sample observations. The estimates are<br />
functions of the sample values and are called statistics.<br />
For example, the sample mean is a statistic<br />
and may be used to estimate the population mean.<br />
Similarly, the rate of occurrence of defects estimated<br />
from the sample (rate of defects per line of<br />
code) is a statistic and serves as the estimate of<br />
the population rate of rate of defects per line of<br />
code. The statistic used to estimate some population<br />
parameter is often referred to as the estimator<br />
of the parameter.<br />
<br />
A very important point to note is that the results<br />
of the estimators themselves are random. If we<br />
take a different sample, we are likely to get a different<br />
estimate of the population parameter. In the<br />
theory of estimation, we need to understand different<br />
properties of estimators—particularly, how<br />
much the estimates can vary across samples and<br />
how to choose between different alternative ways<br />
to obtain the estimates. For example, if we wish<br />
to estimate the mean of a population, we might<br />
use as our estimator a sample mean, a sample<br />
median, a sample mode, or the midrange of the<br />
sample. Each of these estimators has different<br />
statistical properties that may impact the standard<br />
error of the estimate.<br />
<br />
''Types of estimates'' [2*, c7s3, c8s1].There are<br />
two types of estimates: namely, point estimates<br />
and interval estimates. When we use the value<br />
of a statistic to estimate a population parameter,<br />
we get a point estimate. As the name indicates, a<br />
point estimate gives a point value of the parameter<br />
being estimated.<br />
<br />
Although point estimates are often used, they<br />
leave room for many questions. For instance, we<br />
are not told anything about the possible size of<br />
error or statistical properties of the point estimate.<br />
Thus, we might need to supplement a point<br />
estimate with the sample size as well as the variance<br />
of the estimate. Alternately, we might use<br />
an interval estimate. An interval estimate is a<br />
random interval with the lower and upper limits<br />
of the interval being functions of the sample observations as well as the sample size. The limits<br />
are computed on the basis of some assumptions<br />
regarding the sampling distribution of the<br />
point estimate on which the limits are based.<br />
<br />
''Properties of estimators''. Various statistical<br />
properties of estimators are used to decide about<br />
the appropriateness of an estimator in a given<br />
situation. The most important properties are that<br />
an estimator is unbiased, efficient, and consistent<br />
with respect to the population.<br />
<br />
''Tests of hypotheses'' [2*, c9s1].A hypothesis is<br />
a statement about the possible values of a parameter.<br />
For example, suppose it is claimed that a<br />
new method of software development reduces the<br />
occurrence of defects. In this case, the hypothesis<br />
is that the rate of occurrence of defects has<br />
reduced. In tests of hypotheses, we decide—on<br />
the basis of sample observations—whether a proposed<br />
hypothesis should be accepted or rejected.<br />
<br />
For testing hypotheses, the null and alternative<br />
hypotheses are formed. The null hypothesis is the<br />
hypothesis of no change and is denoted as H<sub>0</sub>. The<br />
alternative hypothesis is written as H<sub>1</sub>. It is important<br />
to note that the alternative hypothesis may be<br />
one-sided or two-sided. For example, if we have<br />
the null hypothesis that the population mean is not<br />
less than some given value, the alternative hypothesis<br />
would be that it is less than that value and we<br />
would have a one-sided test. However, if we have<br />
the null hypothesis that the population mean is<br />
equal to some given value, the alternative hypothesis<br />
would be that it is not equal and we would<br />
have a two-sided test (because the true value could<br />
be either less than or greater than the given value).<br />
<br />
In order to test some hypothesis, we first compute<br />
some statistic. Along with the computation<br />
of the statistic, a region is defined such that in<br />
case the computed value of the statistic falls in<br />
that region, the null hypothesis is rejected. This<br />
region is called the critical region (also known as<br />
the confidence interval). In tests of hypotheses,<br />
we need to accept or reject the null hypothesis<br />
on the basis of the evidence obtained. We note<br />
that, in general, the alternative hypothesis is the<br />
hypothesis of interest. If the computed value of<br />
the statistic does not fall inside the critical region,<br />
then we cannot reject the null hypothesis. This<br />
indicates that there is not enough evidence to<br />
believe that the alternative hypothesis is true. As the decision is being taken on the basis<br />
of sample observations, errors are possible; the<br />
types of such errors are summarized in the following<br />
table. <br />
{| class="wikitable"<br />
|'''Nature'''<br />
|'''Statistical Decision'''<br />
|-<br />
|<br />
|<br />
|-<br />
|<br />
|<br />
|<br />
|}</div>Daniel Robbins