Software Engineering Body of Knowledge (v3) (2014) (811503), страница 56
Текст из файла (страница 56)
For example, it is rather common for asoftware project to be divided into pieces acrossnational and cultural borders, and it is also quitecommon for a software project team to consist ofpeople from diverse cultural backgrounds.For a software project to be a success, teammembers must achieve a level of tolerance,Software Engineering Professional Practice 11-11acknowledging that some rules depend on societal norms and that not all societies derive thesame solutions and expectations.This tolerance and accompanying understanding can be facilitated by the support of leadershipand management.
More frequent communication,including face-to-face meetings, can help to mitigate geographical and cultural divisions, promotecohesiveness, and raise productivity. Also, beingable to communicate with teammates in theirnative language could be very beneficial.3. Communication SkillsIt is vital that a software engineer communicatewell, both orally and in reading and writing. Successful attainment of software requirements anddeadlines depends on developing clear understanding between the software engineer andcustomers, supervisors, coworkers, and suppliers. Optimal problem solving is made possiblethrough the ability to investigate, comprehend,and summarize information.
Customer productacceptance and safe product usage depend on theprovision of relevant training and documentation.It follows that the software engineer’s own careersuccess is affected by the ability to consistentlyprovide oral and written communication effectively and on time.3.1. Reading, Understanding, and Summarizing[5*, c33s3]Software engineers are able to read and understand technical material.
Technical materialincludes reference books, manuals, researchpapers, 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 engineeringgoals. A software engineer sifts through accumulated information, filtering out the pieces thatwill be most helpful. Customers may request thata software engineer summarize the results ofsuch information gathering for them, simplifyingor explaining it so that they may make the finalchoice between competing solutions.Reading and comprehending source code isalso a component of information gathering andproblem solving.
When modifying, extending,or rewriting software, it is critical to understandboth its implementation directly derived from thepresented code and its design, which must oftenbe inferred.3.2. Writing[3*, c1s5]Software engineers are able to produce writtenproducts as required by customer requests or generally accepted practice. These written productsmay 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 importantbecause often it is the primary method of communication among relevant parties.
In all cases,written software engineering products must bewritten so that they are accessible, understandable and relevant for their intended audience(s).3.3. Team and Group Communication[3*, c1s6.8] [4*, c22s3] [5*, c27s1][9*, c10s4]Effective communication among team and groupmembers is essential to a collaborative softwareengineering effort.
Stakeholders must be consulted, decisions must be made, and plans mustbe generated. The greater the number of teamand group members, the greater the need tocommunicate.The number of communication paths, however, grows quadratically with the addition ofeach team member. Further, team membersare unlikely to communicate with anyone perceived to be removed from them by more thantwo degrees (levels). This problem can be moreserious when software engineering endeavors ororganizations are spread across national and continental borders.Some communication can be accomplished inwriting.
Software documentation is a commonsubstitute for direct interaction. Email is anotherbut, although it is useful, it is not always enough;also, if one sends too many messages, it becomesdifficult to identify the important information.Increasingly, organizations are using enterprise11-12 SWEBOK® Guide V3.0collaboration tools to share information. In addition, the use of electronic information stores,accessible to all team members, for organizational policies, standards, common engineeringprocedures, and project-specific information, canbe most beneficial.Some software engineering teams focus onface-to-face interaction and promote such interaction by office space arrangement.
Althoughprivate offices improve individual productivity,colocating team members in physical or virtualforms and providing communal work areas isimportant to collaborative efforts.3.4. Presentation Skills[3*, c1s5] [4*, c22] [9*, c10s7–c10s8]Software engineers rely on their presentationskills during software life cycle processes. Forexample, during the software requirementsphase, software engineers may walk customersand teammates through software requirementsand conduct formal requirements reviews (seeRequirement 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 SoftwareQuality KA), and training. All of these require theability to present technical information to groupsand solicit ideas or feedback.The software engineer’s ability to conveyconcepts effectively in a presentation thereforeinfluences product acceptance, management,and customer support; it also influences the ability of stakeholders to comprehend and assist inthe product effort.
This knowledge needs to bearchived in the form of slides, knowledge writeup, technical whitepapers, and any other materialutilized for knowledge creation.Software Engineering Professional Practice 11-13IEEE-CS/ACM 1999[6*]c33*c1s2c35s1Fairley 2009[9*]McConnell 2004[5*]c1s2Tockey 2004[8*]Sommerville 2011[4*]c8Moore 2006[7*]Voland 2003[3*]Bott et al. 2000[1*]MATRIX OF TOPICS VS. REFERENCE MATERIAL1. Professionalism1.1. Accreditation,Certification, andLicensing1.2. Codes of Ethicsand ProfessionalConduct1.3. Nature andRole of ProfessionalSocieties1.4. Nature andRole of SoftwareEngineeringStandards1.5. EconomicImpact of Software1.6. EmploymentContracts1.7. Legal Issuesc1s4.1,c1s5.1–c1s5.4c1s6–c1s9c1s1–c1s2c5s3.2,c10s2.1c32s6c10s8c1s1.1c1s2c1c7c6, c111.8. Documentation c10s5.81.9. TradeoffAnalysis2. Group Dynamicsand Psychology2.1. Dynamics ofWorking in Teams/Groups2.2. IndividualCognition2.3. 2.3 Dealing withProblem Complexity2.4. Interacting withStakeholdersc5s3–c5s4c1s5c1s2,c10c1s10c32c9s5.10c1s3.5,c10c1s6c1s6.5c33c3s2c33c2s3.12.5. Dealing withUncertainty andAmbiguity2.6. Dealing withMulticulturalEnvironments3. CommunicationSkills3.1. Reading,Understanding, andSummarizing3.2. Writing3.3. Team and GroupCommunication3.4. PresentationSkillsc24s4,c26s2Fairley 2009[9*]Tockey 2004[8*]Moore 2006[7*]IEEE-CS/ACM 1999[6*]McConnell 2004[5*]Sommerville 2011[4*]Voland 2003[3*]Bott et al.
2000[1*]11-14 SWEBOK® Guide V3.0c9s4c10s7c33s3c1s5c1s6.8c22s3c1s5c22c27s1c10s4c10s7–c10s8Software Engineering Professional Practice 11-15FURTHER READINGSREFERENCESGerald M. Weinberg, The Psychology ofComputer Programming [10].[1*] F. Bott et al., Professional Issues inSoftware Engineering, 3rd ed., Taylor &Francis, 2000.This was the first major book to address programming as an individual and team effort and becamea classic in the field.[2] Merriam-Webster’s Collegiate Dictionary,11th ed., 2003.Kinney and Lange, P.A., Intellectual PropertyLaw for Business Lawyers [11].[3*] G. Voland, Engineering by Design, 2nd ed.,Prentice Hall, 2003.This book covers IP laws in the US.
It not onlytalks about what the IP law is; it also explainswhy it looks the way it does.[4*] I. Sommerville, Software Engineering, 9thed., Addison-Wesley, 2011.[5*] S. McConnell, Code Complete, 2nd ed.,Microsoft Press, 2004.[6*] IEEE CS/ACM Joint Task Force onSoftware Engineering Ethics andProfessional Practices, “SoftwareEngineering Code of Ethics andProfessional Practice (Version 5.2),” 1999;www.acm.org/serving/se/code.htm.[7*] J.W. Moore, The Road Map to SoftwareEngineering: A Standards-Based Guide,Wiley-IEEE Computer Society Press, 2006.[8*] S.
Tockey, Return on Software: Maximizingthe Return on Your Software Investment,Addison-Wesley, 2004.[9*] R.E. Fairley, Managing and LeadingSoftware Projects, Wiley-IEEE ComputerSociety Press, 2009.[10] G.M. Weinberg, The Psychologyof Computer Programming: SilverAnniversary Edition, Dorset House, 1998.[11] Kinney and Lange, P.A., IntellectualProperty Law for Business Lawyers,Thomson West, 2013.CHAPTER 12SOFTWARE ENGINEERING ECONOMICSACRONYMSEVMIRRMARRSDLCSPLCROIROCETCOEarned Value ManagementInternal Rate of ReturnMinimum Acceptable Rate ofReturnSoftware Development Life CycleSoftware Product Life CycleReturn on InvestmentReturn on Capital EmployedTotal Cost of OwnershipINTRODUCTIONSoftware engineering economics is about making decisions related to software engineering in abusiness context.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
