Software Engineering Body of Knowledge (v3) (2014) (811503), страница 55
Текст из файла (страница 55)
If the customer will acquire ownershipof the software source code or the right to modifythe code, the software engineer should providedocumentation of the functional specifications,the software design, the test suite, and the necessary operating environment for the software.The minimum length of time documents shouldbe kept is the duration of the software products’life cycle or the time required by relevant organizational or regulatory requirements.1.9. Tradeoff Analysis[3*, c1s2, c10] [9*, c9s5.10]Within the practice of software engineering, asoftware engineer often has to choose betweenalternative problem solutions. The outcome ofthese choices is determined by the software engineer’s professional evaluation of the risks, costs,and benefits of alternatives, in cooperation withstakeholders.
The software engineer’s evaluationis called “tradeoff analysis.” Tradeoff analysisnotably enables the identification of competing and complementary software requirementsin order to prioritize the final set of requirements defining the software to be constructed(see Requirements Negotiation in the SoftwareRequirements KA and Determination and Negotiation of Requirements in the Software Engineering Management KA).In the case of an ongoing software development project that is late or over budget, tradeoffanalysis is often conducted to decide which software requirements can be relaxed or droppedgiven the effects thereof.A first step in a tradeoff analysis is establishing design goals (see Engineering Design in theEngineering Foundations KA) and setting therelative importance of those goals.
This permitsidentification of the solution that most nearlymeets those goals; this means that the way thegoals are stated is critically important.Design goals may include minimization ofmonetary cost and maximization of reliability,performance, or some other criteria on a widerange of dimensions.
However, it is difficult toformulate a tradeoff analysis of cost against risk,especially where primary production and secondary risk-based costs must be traded against eachother.Software Engineering Professional Practice 11-9A software engineer must conduct a tradeoffanalysis in an ethical manner—notably by beingobjective and impartial when selecting criteria forcomparison of alternative problem solutions andwhen assigning weights or importance to thesecriteria. Any conflict of interest must be disclosedup front.2. Group Dynamics and PsychologyEngineering work is very often conducted in thecontext of teamwork. A software engineer mustbe able to interact cooperatively and constructively with others to first determine and thenmeet both needs and expectations.
Knowledge ofgroup dynamics and psychology is an asset wheninteracting with customers, coworkers, suppliers,and subordinates to solve software engineeringproblems.2.1. Dynamics of Working in Teams/Groups[3*, c1s6] [9*, c1s3.5, c10]Software engineers must work with others. Onone hand, they work internally in engineeringteams; on the other hand, they work with customers, members of the public, regulators, andother stakeholders. Performing teams—thosethat demonstrate consistent quality of work andprogress toward goals—are cohesive and possessa cooperative, honest, and focused atmosphere.Individual and team goals are aligned so that themembers naturally commit to and feel ownershipof shared outcomes.Team members facilitate this atmosphere bybeing intellectually honest, making use of groupthinking, 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 aboutwork products are framed in a constructive andnonpersonal way (see Reviews and Audits in theSoftware Quality KA). This allows all the members to pursue a cycle of continuous improvementand growth without personal risk. In general,members of cohesive teams demonstrate respectfor each other and their leader.One point to emphasize is that software engineers must be able to work in multidisciplinaryenvironments and in varied application domains.Since today software is everywhere, from a phoneto a car, software is impacting people’s lives farbeyond the more traditional concept of softwaremade for information management in a businessenvironment.2.2. Individual Cognition[3*, c1s6.5] [5*, c33]Engineers desire to solve problems.
The ability tosolve problems effectively and efficiently is whatevery engineer strives for. However, the limitsand processes of individual cognition affect problem solving. In software engineering, notably dueto the highly abstract nature of software itself,individual cognition plays a very prominent rolein problem solving.In general, an individual’s (in particular, a softwareengineer’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 ororganizational,• lack of ability to express the problem,• perceived working atmosphere, and• emotional status of the individual.The impact of these inhibiting factors can bereduced by cultivating good problem solvinghabits that minimize the impact of misleadingassumptions.
The ability to focus is vital, as isintellectual 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 useto facilitate problem solving (see Problem Solving Techniques in the Computing FoundationsKA). Breaking down problems and solving themone piece at a time reduces cognitive overload.Taking advantage of professional curiosity andpursuing continuous professional development11-10 SWEBOK® Guide V3.0through 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 ofprofessional development.2.3. Dealing with Problem Complexity[3*, c3s2] [5*, c33]Many, if not most, software engineering problems are too complex and difficult to address asa whole or to be tackled by individual softwareengineers.
When such circumstances arise, theusual means to adopt is teamwork and problemdecomposition (see Problem Solving Techniquesin the Computing Foundations KA).Teams work together to deal with complex andlarge problems by sharing burdens and drawing upon each other’s knowledge and creativity.When software engineers work in teams, different views and abilities of the individual engineerscomplement each other and help build a solutionthat is otherwise difficult to come by.
Some specific teamwork examples to software engineeringare pair programming (see Agile Methods in theSoftware Engineering Models and Methods KA)and code review (see Reviews and Audits in theSoftware Quality KA).2.4. Interacting with Stakeholders[9*, c2s3.1]Success of a software engineering endeavordepends upon positive interactions with stakeholders. They should provide support, information, and feedback at all stages of the softwarelife cycle process. For example, during the earlystages, it is critical to identify all stakeholders anddiscover how the product will affect them, so thatsufficient definition of the stakeholder requirements can be properly and completely captured.During development, stakeholders may provide feedback on specifications and/or earlyversions of the software, change of priority, aswell as clarification of detailed or new softwarerequirements.
Last, during software maintenanceand until the end of product life, stakeholders provide feedback on evolving or new requirementsas well problem reports so that the software maybe extended and improved.Therefore, it is vital to maintain open and productive communication with stakeholders for theduration of the software product’s lifetime.2.5. Dealing with Uncertainty and Ambiguity[4*, c24s4, c26s2] [9*, c9s4]As with engineers of other fields, software engineers must often deal with and resolve uncertainty and ambiguities while providing servicesand developing products.
The software engineermust attack and reduce or eliminate any lack ofclarity that is an obstacle to performing work.Often, uncertainty is simply a reflection of lackof knowledge. In this case, investigation throughrecourse to formal sources such as textbooks andprofessional journals, interviews with stakeholders, or consultation with teammates and peers canovercome it.When uncertainty or ambiguity cannot be overcome easily, software engineers or organizationsmay choose to regard it as a project risk. In thiscase, work estimates or pricing are adjusted tomitigate the anticipated cost of addressing it (seeRisk Management in the Software EngineeringManagement KA).2.6. Dealing with Multicultural Environments[9*, c10s7]Multicultural environments can have an impacton the dynamics of a group. This is especiallytrue when the group is geographically separatedor communication is infrequent, since such separation elevates the importance of each contact.Intercultural communication is even more difficult if the difference in time zones make oralcommunication less frequent.Multicultural environments are quite prevalentin software engineering, perhaps more than inother fields of engineering, due to the strong trendof international outsourcing and the easy shipmentof software components instantaneously acrossthe globe.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
