Project Management of Large Software-Intensive Systems

Marvin Gechman

• Publisher: CRC Press
• Year: 2019
• Topic: Computer Science
• eBook ISBN:
  9780429648168
• Subtopic: Information Technology
• Index: Computer Science

The book describes how to manage and successfully deliver large, complex, and expensive systems that can be composed of millions of line of software code, being developed by numerous groups throughout the globe, that interface with many hardware items being developed by geographically dispersed companies, where the system also includes people, policies, constraints, regulations, and a myriad of other factors. It focuses on how to seamlessly integrate systems, satisfy the customer's requirements, and deliver within the budget and on time. The guide is essentially a "shopping list" of all the activities that could be conducted with tailoring guidelines to meet the needs of each project.

SOFTWARE PROJECT MANAGEMENT FUNDAMENTALS

1

1 Software Project Management Introduction

2 Software Project Management Activities

3 System and Software Life Cycle Processes

4 Software Development Methodologies

Chapter 1

Software Project Management Introduction

The beginning of wisdom is the definition of terms.

—Socrates (470–399 BC)

The essence of this introduction is indeed the beginning, or basic foundation, of what you need to know in order to better understand the rest of this Guidebook. Chapter 1 briefly covers the key Software Project Management fundamentals in the following ten sections:

■ Why You Should Read This Chapter First: To understand the terminology and acronyms (1.1).

■ Business Operations, Programs and Projects: Definition of a project and its relationship to programs and business operations (1.2).

■ What Is Project Management: Why projects must be planned, executed and managed (1.3).

■ A System Perspective: Why it is imperative that Software Project Managers have a system perspective, plus definitions of Systems Engineering, software-intensive systems, system boundaries, System of Systems, an overview of the System Life Cycle (SLC), and the value of a one-page big picture overview (1.4).

■ Software Project Planning: An introduction to the importance of the two key software planning documents: the Software Development Plan (SDP) and Work Breakdown Structure (WBS) (1.5).

■ The Software Project Team: Discussions of project organization, software roles, team organization, and the importance of the Chief Software Engineer (CSwE) and the Software Integrated Product Team (SwIPT) (1.6).

■ A Customer Focus: Why you must figure out how to please your customer (1.7).

■ Software Classes and Categories: Describes why having a mechanism to assign proper designations to each software entity will result in major cost savings by eliminating unnecessary documents, reviews, measurements and testing (1.8).

■ Software Development Standards: Needed to produce consistent software work products (1.9).

■ Why Software-Intensive Systems Fail or Overrun: The core success factors needed for successful development and delivery of software-intensive projects (1.10).

1.1 Why You Should Read This Chapter First

All users of this Guidebook should read this introductory chapter first as it establishes a basic understanding of the terminology used and it briefly describes the Guidebook infrastructure that constitutes a foundation for understanding the principles of Software Project Management.

Lessons Learned. This Guidebook is not a standard! Therefore, there are no mandatory “shalls” as you will find in a typical technical standard. There are many variables involved with managing software projects. This Guidebook does not contain prescriptive directions as to precisely how to manage software-intensive system development. What it does provide is approaches, techniques and recommendations for managing software-intensive systems based on many years of proven practices and successful developments. Use new approaches where they fit, but please don’t abandon the wisdom gained from experience.

Acronyms. Acronyms are used extensively in this Guidebook. Appendix A contains a list of all acronyms used in this Guidebook. Table 1.1 is a list of the most common acronyms used throughout the Guidebook; memorizing this set of acronyms will speed up and facilitate reading the Guidebook.

Table 1.1 Common Acronyms

CSwE	Chief Software Engineer	SDP	Software Development Plan
CCB	Configuration Control Board	SDR	Software Discrepancy Report
COTS	Commercial Off-the-Shelf	SEIT	Systems Engineering, Integration & Test
C/R	COTS/Reuse (a software class)	SEPG	Software Engineering Process Group
CUT	Coding and Unit Testing	SI-SU	Software Item–Software Unit
IT&V	Integration, Testing and Verification	SIP	Software Implementation Process
IMP	Integrated Master Plan	SLC	System Life Cycle
IMS	Integrated Master Schedule	SPM	Software Project Manager
JMR	Joint Management Review	SPR	Software Peer Review
JTR	Joint Technical Review	SQA	Software Quality Assurance
MSDL	Master SDL	SE	Systems Engineering
SCS	System Critical Software (a Sw class)	SS	Support Software (a software class)
SCM	Software Configuration Management	SwIPT	Software Integrated Product Team
SCR	Software Change Request (or Report)	SwE	Software Engineering
SDF	Software Development File (or Folder)	TIM	Technical Interchange Meeting
SDL	Software Development Library	UI&T	Unit Integration and Test
SDLC	Software Development Life Cycle	WBS	Work Breakdown Structure

It is expected that, when this Guidebook is used a reference, readers will revisit individual sections for reminders when needed. Consequently, acronyms are typically redefined when first encountered in each chapter. Definitions of key terms used in this Guidebook are included in Appendix B.

Learning acronyms is almost like learning another language. Those who balk at learning a lot of acronyms must realize that, if they want to work in the Software Engineering profession, acronyms are an inherent part of the daily life of a software engineer. The pinnacle of acronym usage is in government and military work because, for example, it is much easier to say “DIACAP” than it is to say, “Department of Defense Information Assurance Certification and Accreditation Process.”

Terminology. The Guidebook is focused on large software system developments with the intention that smaller sized systems will tailor out what does not apply to them. Essentially, the Guidebook is a “shopping list” of what must be done, what should be done, what can be done, and what may be done (if applicable to your project). In that context, the following terms—and what they mean—are used throughout this Guidebook:

■ Must: Highly recommended for compliance with most software standards and as a best practice.

■ Should: Recommended for accuracy and completeness.

■ Can: Discretionary but should be seriously considered for inclusion.

■ May: Discretionary or used to show examples; Using the term “may” implies that other good options exist—choosing between them is left up to the Project Manager.

1.2 Business Operations, Programs and Projects

Business Operations. A project should not be confused with general business operations that are ongoing, repetitive, or essentially permanent functional activities of your organization that produces products or services. A simplistic example: If a boat company has a speedboat division that manufactures and sells speedboats, the daily activities of that division is an ongoing business operation. When that division decides to design and build a new model speedboat, that effort is a project.

Programs. Likewise, projects should not be confused with programs since programs typically consist of multiple projects. In your company, there may be only a subtle difference between programs ...

Table of contents

• Cover
• Half-Title
• Title
• Copyright
• Contents
• Foreword
• Preface
• Acknowledgements
• Author
• SECTION 1 SOFTWARE PROJECT MANAGEMENT FUNDAMENTALS
• SECTION 2 SOFTWARE MANAGEMENT AND QUALITY DOMAINS
• SECTION 3 SOFTWARE RESOURCES DOMAIN
• SECTION 4 SYSTEMS AND SOFTWARE ENGINEERING DOMAINS
• SECTION 5 CRITICAL SOFTWARE ELEMENTS DOMAIN
• Appendix A: Software Acronyms
• Appendix B: Software Definitions
• Appendix C: Software Roles and Responsibilities for Skill Groups
• Appendix D: Criteria for Evaluating Commercial Off-the-Shelf (COTS) and Reusable Software Products
• Appendix E: Pre-Milestone A Plans and Strategies
• Appendix F: Annotated Outline of the Software Development Plan (SDP)
• Appendix G: Exit Criteria for Software Reviews
• Appendix H: Chapter Highlights
• Appendix I: References by Category
• Index