Software Engineering Body of Knowledge (v3) (2014) (811503), страница 34
Текст из файла (страница 34)
At maturity level 2, itsuggests configuration management activities.[2*] IEEE Std. 828-2012, Standard forConfiguration Management in Systems andSoftware Engineering, IEEE, 2012.[3*] A.M.J. Hass, Configuration ManagementPrinciples and Practices, 1st ed., AddisonWesley, 2003.[4*] I. Sommerville, Software Engineering, 9thed., Addison-Wesley, 2011.[5*] J.W. Moore, The Road Map to SoftwareEngineering: A Standards-Based Guide,Wiley-IEEE Computer Society Press, 2006.[6] S.P. Berczuk and B. Appleton, SoftwareConfiguration Management Patterns:Effective Teamwork, Practical Integration,Addison-Wesley Professional, 2003.[7] CMMI Product Team, “CMMI forDevelopment, Version 1.3,” SoftwareEngineering Institute, 2010; http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9661.CHAPTER 7SOFTWARE ENGINEERING MANAGEMENTACRONYMSPMBOK®GuideSDLCSEMGuide to the Project ManagementBody of KnowledgeSoftware Development Life CycleSoftware Engineering ManagementSQASoftware Quality AssuranceSWXWBS• Clients often don’t know what is needed orwhat is feasible.• Clients often lack appreciation for the complexities inherent in software engineering,particularly regarding the impact of changing requirements.• It is likely that increased understanding andchanging conditions will generate new orchanged software requirements.• As a result of changing requirements, software is often built using an iterative processrather than as a sequence of closed tasks.• Software engineering necessarily incorporates creativity and discipline.
Maintainingan appropriate balance between the two issometimes difficult.• The degree of novelty and complexity isoften high.• There is often a rapid rate of change in theunderlying technology.Software Extension to the PMBOK®GuideWork Breakdown StructureINTRODUCTIONSoftware engineering management can be definedas the application of management activities—planning, coordinating, measuring, monitoring, controlling, and reporting1—to ensure that softwareproducts and software engineering services aredelivered efficiently, effectively, and to the benefitof stakeholders.
The related discipline of management is an important element of all the knowledgeareas (KAs), but it is of course more relevant tothis KA than to other KAs. Measurement is also animportant aspect of all KAs; the topic of measurement programs is presented in this KA.In one sense, it should be possible to managea software engineering project in the same wayother complex endeavors are managed.
However,there are aspects specific to software projectsand software life cycle processes that complicateeffective management, including these:Software engineering management activitiesoccur at three levels: organizational and infrastructure management, project management,and management of the measurement program.The last two are covered in detail in this KAdescription. However, this is not to diminish theimportance of organizational and infrastructuremanagement issues. It is generally agreed thatsoftware organizational engineering managersshould be conversant with the project management and software measurement knowledgedescribed in this KA. They should also possesssome target domain knowledge. Likewise, it isalso helpful if managers of complex projects andprograms in which software is a component ofthe system architecture are aware of the differences that software processes introduce into project management and project measurement.1 The terms Initiating, Planning, Executing,Monitoring and Controlling, and Closing are used todescribe process groups in the PMBOK® Guide andSWX.7-17-2 SWEBOK® Guide V3.0Figure 7.1.
Breakdown of Topics for the Software Engineering Management KAOther aspects of organizational managementexert an impact on software engineering (forexample, organizational policies and proceduresthat provide the framework in which softwareengineering projects are undertaken). These policies and procedures may need to be adjusted bythe requirements for effective software development and maintenance. In addition, a number ofpolicies specific to software engineering mayneed to be in place or established for effectivemanagement of software engineering at the organizational level.
For example, policies are usuallynecessary to establish specific organization-wideprocesses or procedures for software engineeringtasks such as software design, software construction, estimating, monitoring, and reporting. Suchpolicies are important for effective long-termmanagement of software engineering projectsacross an organization (for example, establishinga consistent basis by which to analyze past project performance and implement improvements).Another important aspect of organizationalmanagement is personnel management policiesand procedures for hiring, training, and mentoring personnel for career development, not only atthe project level, but also to the longer-term success of an organization.
Software engineering personnel may present unique training or personnelmanagement challenges (for example, maintainingcurrency in a context where the underlying technology undergoes rapid and continuous change).Communication management is also oftenmentioned as an overlooked but important aspectof the performance of individuals in a field whereprecise understanding of user needs, softwarerequirements, and software designs is necessary.Furthermore, portfolio management, which provides an overall view, not only of software currently under development in various projects andprograms (integrated projects), but also of software planned and currently in use in an organization, is desirable. Also, software reuse is a keySoftware Engineering Management 7-3factor in maintaining and improving productivityand competitiveness.
Effective reuse requires astrategic vision that reflects the advantages anddisadvantages of reuse.In addition to understanding the aspects ofmanagement that are uniquely influenced by software projects, software engineers should havesome knowledge of the more general aspects ofmanagement that are discussed in this KA (evenin the first few years after graduation).Attributes of organizational culture and behavior, plus management of other functional areasof the enterprise, have an influence, albeit indirectly, on an organization’s software engineeringprocesses.Extensive information concerning softwareproject management can be found in the Guideto the Project Management Body of Knowledge(PMBOK® Guide) and the Software Extension tothe PMBOK® Guide (SWX) [1] [2].
Each of theseguides includes ten project management KAs:project integration management, project scopemanagement, project time management, projectcost management, project quality management,project human resource management, projectcommunications management, project risk management, project procurement management, andproject stakeholder management. Each KA hasdirect relevance to this Software EngineeringManagement KA.Additional information is also provided in theother references and further readings for this KA.This Software Engineering Management KAconsists of the software project management processes in the first five topics in Figure 7.1 (Initiation and Scope Definition, Software Project Planning, Software Project Enactment, Review andEvaluation, Closure), plus Software EngineeringMeasurement in the sixth topic and SoftwareEngineering Management Tools in the seventhtopic.
While project management and measurement management are often regarded as beingseparate, and indeed each does possess manyunique attributes, the close relationship has led tocombined treatment in this KA.Unfortunately, a common perception of the software industry is that software products are delivered late, over budget, of poor quality, and withincomplete functionality. Measurement-informedmanagement—a basic principle of any true engineering discipline (see Measurement in the Engineering Foundations KA)—can help improvethe perception and the reality.
In essence, management without measurement (qualitative andquantitative) suggests a lack of discipline, andmeasurement without management suggests alack of purpose or context. Effective managementrequires a combination of both measurement andexperience.The following working definitions are adoptedhere:• Management is a system of processes andcontrols required to achieve the strategicobjectives set by the organization.• Measurement refers to the assignment of values and labels to software engineering workproducts, processes, and resources plus themodels that are derived from them, whetherthese models are developed using statisticalor other techniques [3* , c7, c8].The software engineering project managementsections in this KA make extensive use of thesoftware engineering measurement section.This KA is closely related to others in theSWEBOK Guide, and reading the following KAdescriptions in conjunction with this one will beparticularly helpful:• The Engineering Foundations KA describessome general concepts of measurement thatare directly applicable to the Software Engineering Measurement section of this KA.In addition, the concepts and techniquespresented in the Statistical Analysis sectionof the Engineering Foundations KA applydirectly to many topics in this KA.• The Software Requirements KA describessome of the activities that should be performed during the Initiation and Scope definition phase of the project.• The Software Configuration ManagementKA deals with identification, control, statusaccounting, and auditing of software configurations along with software release management and delivery and software configuration management tools.7-4 SWEBOK® Guide V3.0• The Software Engineering Process KAdescribes software life cycle models and therelationships between processes and workproducts.• The Software Quality KA emphasizes quality as a goal of management and as an aim ofmany software engineering activities.• The Software Engineering Economics KAdiscusses how to make software-relateddecisions in a business context.BREAKDOWN OF TOPICS FORSOFTWARE ENGINEERINGMANAGEMENTBecause most software development life cyclemodels require similar activities that may be executed in different ways, the breakdown of topicsis activity-based.
That breakdown is shown inFigure 7.1. The elements of the top-level breakdown shown in that figure are the activities thatare usually performed when a software development project is being managed, independent ofthe software development life cycle model (seeSoftware Life Cycle Models in the SoftwareEngineering Process KA) that has been chosen fora specific project.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
