Chapter 11: Software Engineering Professional Practice - Revision history

Daniel Robbins at 15:52, 29 August 2015

2015-08-29T15:52:54Z

Daniel Robbins at 15:52, 29 August 2015

2015-08-29T15:52:12Z

Daniel Robbins at 10:46, 29 August 2015

2015-08-29T10:46:29Z

Daniel Robbins at 10:45, 29 August 2015

2015-08-29T10:45:34Z

Daniel Robbins at 10:44, 29 August 2015

2015-08-29T10:44:21Z

Daniel Robbins: /* Presentation Skills */

2015-08-29T10:23:49Z

‎Presentation Skills

Daniel Robbins: /* Dealing with Multicultural Environments */

2015-08-29T10:20:40Z

‎Dealing with Multicultural Environments

Daniel Robbins: /* Individual Cognition */

2015-08-29T10:05:19Z

‎Individual Cognition

Daniel Robbins: /* Group Dynamics and Psychology */

2015-08-29T09:03:05Z

‎Group Dynamics and Psychology

Daniel Robbins: /* Codes of Ethics and Professional Conduct */

2015-08-29T08:54:10Z

‎Codes of Ethics and Professional Conduct

Show changes

@@ Line 11: / Line 11: @@
 {{Acronym|name=ISO|description=International Organization for Standardization}}
 {{Acronym|name=NDA|description=Non-Disclosure Agreement}}
-{{Acronym|name=WIPO|description=World Intellectual Property Organization}
+{{Acronym|name=WIPO|description=World Intellectual Property Organization}}
 {{Acronym|name=WTO|description=World Trade Organization}}
 }}

@@ Line 1: / Line 1: @@
 {{TOC}}
 {{Acronym|name=ACM|description=Association for Computing Machinery}}
 {{Acronym|name=BCS|description=British Computer Society}}

@@ Line 1: / Line 1: @@
 {{TOC}}
 {{Acronym|name=ACM|description=Association for Computing Machinery}}
-{{Acronyms|{{Acronym|name=ACM|description=Association for Computing Machinery}}
 {{Acronym|name=BCS|description=British Computer Society}}
 {{Acronym|name=CSDA|description=Certified Software Development Associate}}

@@ Line 1: / Line 1: @@
 {{TOC}}
-{{Acronym|name=ACM|description=Association for Computing Machinery}}
+{{Acronyms|{{Acronym|name=ACM|description=Association for Computing Machinery}}
 {{Acronym|name=BCS|description=British Computer Society}}
 {{Acronym|name=CSDA|description=Certified Software Development Associate}}

← Older revision		Revision as of 10:44, 29 August 2015
Line 1,005:		Line 1,005:
	talks about what the IP law is; it also explains		talks about what the IP law is; it also explains
	why it looks the way it does.}}		why it looks the way it does.}}
		+	{{EndSection\|title=References\|body=
		+	{{reference
		+	\|number=1
		+	\|author=F. Bott et al.
		+	\|article=
		+	\|publication=Professional Issues in Software Engineering
		+	\|edition=3rd ed.
		+	\|publisher=Taylor & Francis
		+	\|issue=
		+	\|date=2000
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=2
		+	\|author=Merriam-Webster’s Collegiate Dictionary
		+	\|article=
		+	\|publication=
		+	\|edition=11th ed
		+	\|publisher=
		+	\|issue=
		+	\|date=2003
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=3
		+	\|author=G. Voland
		+	\|article=
		+	\|publication=Engineering by Design
		+	\|edition=2nd ed.
		+	\|publisher=Prentice Hall
		+	\|issue=
		+	\|date=2003
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=4
		+	\|author=I. Sommerville
		+	\|article=
		+	\|publication=Software Engineering
		+	\|edition=9th ed.
		+	\|publisher=Addison-Wesley
		+	\|issue=
		+	\|date=2011
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=5
		+	\|author=S. McConnell
		+	\|article=
		+	\|publication=Code Complete
		+	\|edition=2nd ed.
		+	\|publisher=Microsoft Press
		+	\|issue=
		+	\|date=2004
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=6
		+	\|author=IEEE CS/ACM Joint Task Force onSoftware Engineering Ethics and Professional Practices
		+	\|article=Software Engineering Code of Ethics and Professional Practice (Version 5.2)
		+	\|publication=
		+	\|edition=
		+	\|publisher=
		+	\|issue=
		+	\|date=1999
		+	\|part=
		+	\|link=www.acm.org/serving/se/code.htm
		+	}}{{reference
		+	\|number=7
		+	\|author=J.W. Moore
		+	\|article=
		+	\|publication=The Road Map to Software Engineering: A Standards-Based Guide
		+	\|edition=
		+	\|publisher=Wiley-IEEE Computer Society Press
		+	\|issue=
		+	\|date=2006
		+	\|part=
		+	\|link=
		+	}}{{reference
		+	\|number=8
		+	\|author=S. Tockey
		+	\|article=
		+	\|publication=Return on Software: Maximizing the Return on Your Software Investment
		+	\|edition=
		+	\|publisher=Addison-Wesley
		+	\|issue=
		+	\|date=2004
		+	\|part=
		+	\|link=
		+	}}
		+	{{reference
		+	\|number=9
		+	\|author=R.E. Fairley
		+	\|article=
		+	\|publication=Managing and Leading Software Projects
		+	\|edition=
		+	\|publisher=Wiley-IEEE Computer Society Press
		+	\|issue=
		+	\|date=2009
		+	\|part=
		+	\|link=
		+	}}
		+	{{reference
		+	\|number=10
		+	\|author=G.M. Weinberg
		+	\|article=
		+	\|publication=The Psychology of Computer Programming: Silver Anniversary Edition
		+	\|edition=
		+	\|publisher=Dorset House
		+	\|issue=
		+	\|date=1998
		+	\|part=
		+	\|link=
		+	}}
		+	{{reference
		+	\|number=11
		+	\|author=Kinney and Lange, P.A.
		+	\|article=
		+	\|publication=Intellectual Property Law for Business Lawyers
		+	\|edition=
		+	\|publisher=Thomson West
		+	\|issue=
		+	\|date=2013
		+	\|part=
		+	\|link=
		+	}}
		+	{{ReferenceList}}
		+	}}

← Older revision		Revision as of 10:23, 29 August 2015
Line 991:		Line 991:
	technical whitepapers, and any other material		technical whitepapers, and any other material
	utilized for knowledge creation.		utilized for knowledge creation.
		+
		+	{{EndSection\|title=Further Readings\|body=
		+
		+	Gerald M. Weinberg, ''The Psychology of Computer Programming'' [10].
		+
		+	This was the first major book to address programming
		+	as an individual and team effort and became
		+	a classic in the field.
		+
		+	Kinney and Lange, P.A., ''Intellectual Property Law for Business Lawyers'' [11].
		+
		+	This book covers IP laws in the US. It not only
		+	talks about what the IP law is; it also explains
		+	why it looks the way it does.}}

← Older revision		Revision as of 10:20, 29 August 2015
Line 859:		Line 859:
	able to communicate with teammates in their		able to communicate with teammates in their
	native language could be very beneficial.		native language could be very beneficial.
		+
		+	==Communication Skills==
		+
		+	It is vital that a software engineer communicate
		+	well, both orally and in reading and writing. Successful
		+	attainment of software requirements and
		+	deadlines depends on developing clear understanding
		+	between the software engineer and
		+	customers, supervisors, coworkers, and suppliers.
		+	Optimal problem solving is made possible
		+	through the ability to investigate, comprehend,
		+	and summarize information. Customer product
		+	acceptance and safe product usage depend on the
		+	provision of relevant training and documentation.
		+	It follows that the software engineer’s own career
		+	success is affected by the ability to consistently
		+	provide oral and written communication effectively
		+	and on time.
		+
		+	===Reading, Understanding, and Summarizing===
		+	{{RightSection\|{{referenceLink\|number=5\|parts=c33}}}}
		+
		+	Software engineers are able to read and understand
		+	technical material. Technical material
		+	includes reference books, manuals, research
		+	papers, and program source code.
		+
		+	Reading is not only a primary way of improving
		+	skills, but also a way of gathering information
		+	necessary for the completion of engineering
		+	goals. A software engineer sifts through accumulated
		+	information, filtering out the pieces that
		+	will be most helpful. Customers may request that
		+	a software engineer summarize the results of
		+	such information gathering for them, simplifying
		+	or explaining it so that they may make the final
		+	choice between competing solutions.
		+
		+	Reading and comprehending source code is
		+	also a component of information gathering and
		+	problem solving. When modifying, extending, or rewriting software, it is critical to understand
		+	both its implementation directly derived from the
		+	presented code and its design, which must often
		+	be inferred.
		+
		+	===Writing===
		+	{{RightSection\|{{referenceLink\|number=3\|parts=c1s5}}}}
		+
		+	Software engineers are able to produce written
		+	products as required by customer requests or generally
		+	accepted practice. These written products
		+	may include source code, software project plans,
		+	software requirement documents, risk analyses,
		+	software design documents, software test plans,
		+	user manuals, technical reports and evaluations,
		+	justifications, diagrams and charts, and so forth.
		+
		+	Writing clearly and concisely is very important
		+	because often it is the primary method of communication
		+	among relevant parties. In all cases,
		+	written software engineering products must be
		+	written so that they are accessible, understandable
		+	and relevant for their intended audience(s).
		+
		+	===Team and Group Communication===
		+	{{RightSection\| {{referenceLink\|number=3\|parts=c1s6.8}} {{referenceLink\|number=4\|parts=c22s3}} {{referenceLink\|number=5\|parts=c27s1}} {{referenceLink\|number=9\|parts=c10s4}}}}
		+
		+	Effective communication among team and group
		+	members is essential to a collaborative software
		+	engineering effort. Stakeholders must be consulted,
		+	decisions must be made, and plans must
		+	be generated. The greater the number of team
		+	and group members, the greater the need to
		+	communicate.
		+
		+	The number of communication paths, however,
		+	grows quadratically with the addition of
		+	each team member. Further, team members
		+	are unlikely to communicate with anyone perceived
		+	to be removed from them by more than
		+	two degrees (levels). This problem can be more
		+	serious when software engineering endeavors or
		+	organizations are spread across national and continental
		+	borders.
		+
		+	Some communication can be accomplished in
		+	writing. Software documentation is a common
		+	substitute for direct interaction. Email is another
		+	but, although it is useful, it is not always enough;
		+	also, if one sends too many messages, it becomes
		+	difficult to identify the important information.
		+	Increasingly, organizations are using enterprise collaboration tools to share information. In addition,
		+	the use of electronic information stores,
		+	accessible to all team members, for organizational
		+	policies, standards, common engineering
		+	procedures, and project-specific information, can
		+	be most beneficial.
		+
		+	Some software engineering teams focus on
		+	face-to-face interaction and promote such interaction
		+	by office space arrangement. Although
		+	private offices improve individual productivity,
		+	colocating team members in physical or virtual
		+	forms and providing communal work areas is
		+	important to collaborative efforts.
		+
		+	===Presentation Skills===
		+	{{RightSection\| {{referenceLink\|number=3\|parts=c1s5}} {{referenceLink\|number=4\|parts=c22}} {{referenceLink\|number=9\|parts=c10s7–c10s8}}}}
		+
		+	Software engineers rely on their presentation
		+	skills during software life cycle processes. For
		+	example, during the software requirements phase, software engineers may walk customers
		+	and teammates through software requirements
		+	and conduct formal requirements reviews (see
		+	Requirement Reviews in the Software Requirements
		+	KA). During and after software design,
		+	software construction, and software maintenance,
		+	software engineers lead reviews, product walkthroughs
		+	(see Review and Audits in the Software
		+	Quality KA), and training. All of these require the
		+	ability to present technical information to groups
		+	and solicit ideas or feedback.
		+
		+	The software engineer’s ability to convey
		+	concepts effectively in a presentation therefore
		+	influences product acceptance, management,
		+	and customer support; it also influences the ability
		+	of stakeholders to comprehend and assist in
		+	the product effort. This knowledge needs to be
		+	archived in the form of slides, knowledge writeup,
		+	technical whitepapers, and any other material
		+	utilized for knowledge creation.

@@ Line 748: / Line 748: @@
 * emotional status of the individual.
-The impact of these inhibiting factors can be
+===Dealing with Problem Complexity===
-reduced by cultivating good problem solving
+{{RightSection|{{referenceLink|number=3|parts=c3s2}} {{referenceLink|number=5|parts=c33}}}}
-habits that minimize the impact of misleading
-assumptions. The ability to focus is vital, as is
-intellectual humility: both allow a software engineer
-to suspend personal considerations and consult
-with others freely, which is especially important
-when working in teams.
-There is a set of basic methods engineers use
+Many, if not most, software engineering problems
-to facilitate problem solving (see Problem Solving
+are too complex and difficult to address as
-Techniques in the Computing Foundations
+a whole or to be tackled by individual software
-KA). Breaking down problems and solving them
+engineers. When such circumstances arise, the
-one piece at a time reduces cognitive overload.
+usual means to adopt is teamwork and problem
-Taking advantage of professional curiosity and
+decomposition (see Problem Solving Techniques
-pursuing continuous professional development through training and study add skills and knowledge
+in the Computing Foundations KA).
-to the software engineer’s portfolio; reading,
-networking, and experimenting with new tools,
+Teams work together to deal with complex and
-techniques, and methods are all valid means of
+large problems by sharing burdens and drawing
-professional development.
+upon each other’s knowledge and creativity.

← Older revision		Revision as of 09:03, 29 August 2015
Line 682:		Line 682:
	and subordinates to solve software engineering		and subordinates to solve software engineering
	problems.		problems.
		+
		+	===Dynamics of Working in Teams/Groups===
		+	{{RightSection\|{{referenceLink\|number=3\|parts=c1s6}} {{referenceLink\|number=9\|parts=c1s3.5, c10}}}}
		+
		+	Software engineers must work with others. On
		+	one hand, they work internally in engineering
		+	teams; on the other hand, they work with customers,
		+	members of the public, regulators, and
		+	other stakeholders. Performing teams—those
		+	that demonstrate consistent quality of work and
		+	progress toward goals—are cohesive and possess
		+	a cooperative, honest, and focused atmosphere.
		+	Individual and team goals are aligned so that the
		+	members naturally commit to and feel ownership
		+	of shared outcomes.
		+
		+	Team members facilitate this atmosphere by
		+	being intellectually honest, making use of group
		+	thinking, admitting ignorance, and acknowledging
		+	mistakes. They share responsibility, rewards,
		+	and workload fairly. They take care to communicate
		+	clearly, directly to each other and in documents,
		+	as well as in source code, so that information
		+	is accessible to everyone. Peer reviews about
		+	work products are framed in a constructive and
		+	nonpersonal way (see Reviews and Audits in the
		+	Software Quality KA). This allows all the members
		+	to pursue a cycle of continuous improvement
		+	and growth without personal risk. In general,
		+	members of cohesive teams demonstrate respect
		+	for each other and their leader.
		+
		+	One point to emphasize is that software engineers
		+	must be able to work in multidisciplinary
		+	environments and in varied application domains.
		+	Since today software is everywhere, from a phone
		+	to a car, software is impacting people’s lives far
		+	beyond the more traditional concept of software
		+	made for information management in a business
		+	environment.
		+
		+	===Individual Cognition===
		+	{{RightSection\|{{referenceLink\|number=3\|parts=c1s6.5}} {{referenceLink\|number=5\|parts=c33}}}}
		+
		+	Engineers desire to solve problems. The ability to
		+	solve problems effectively and efficiently is what
		+	every engineer strives for. However, the limits
		+	and processes of individual cognition affect problem
		+	solving. In software engineering, notably due
		+	to the highly abstract nature of software itself,
		+	individual cognition plays a very prominent role
		+	in problem solving.
		+
		+	In general, an individual’s (in particular, a software
		+	engineer’s) ability to decompose a problem and creatively
		+	develop a solution can be inhibited by
		+
		+	* need for more knowledge,
		+	* subconscious assumptions,
		+	* volume of data,
		+	* fear of failure or consequence of failure,
		+	* culture, either application domain or organizational,
		+	* lack of ability to express the problem,
		+	* perceived working atmosphere, and
		+	* emotional status of the individual.
		+
		+	The impact of these inhibiting factors can be
		+	reduced by cultivating good problem solving
		+	habits that minimize the impact of misleading
		+	assumptions. The ability to focus is vital, as is
		+	intellectual humility: both allow a software engineer
		+	to suspend personal considerations and consult
		+	with others freely, which is especially important
		+	when working in teams.
		+
		+	There is a set of basic methods engineers use
		+	to facilitate problem solving (see Problem Solving
		+	Techniques in the Computing Foundations
		+	KA). Breaking down problems and solving them
		+	one piece at a time reduces cognitive overload.
		+	Taking advantage of professional curiosity and
		+	pursuing continuous professional development through training and study add skills and knowledge
		+	to the software engineer’s portfolio; reading,
		+	networking, and experimenting with new tools,
		+	techniques, and methods are all valid means of
		+	professional development.