NASA的软件开发项目经理手册

3星 · 超过75%的资源需积分: 10 66 浏览量更新于2024-07-28 收藏 617KB PDF 举报

"《项目经理手册之软件开发》是来源于网络工程领域的资料，文件格式为PDF，适用于Windows平台。这份手册经过了验证，免费提供给读者使用。由NASA/Goddard Space Flight Center的软件工程实验室（SEL）出版，修订版本为1，发布日期为1990年11月。它属于SOFTWARE ENGINEERING LABORATORY SERIES系列，旨在研究软件工程技术和方法在应用软件开发中的效果。" 《项目经理手册之软件开发》是一份深入探讨软件项目管理的专业指南，特别关注于NASA/GSFC环境下的软件开发过程。该手册的前言指出，软件工程实验室（SEL）是由NASA/GSFC与马里兰大学计算机科学系及Computer Sciences Corporation的Flight Dynamics Technology Group共同设立的机构，成立于1977年。其主要目标包括： 1. 理解NASA/GSFC环境中的软件开发过程：这涉及到对软件生命周期的全面了解，包括需求分析、设计、编码、测试和维护等各个阶段。 2. 测量不同方法论、工具和技术对这个过程的影响：手册可能涵盖了各种软件开发模型，如瀑布模型、迭代模型、敏捷开发等，并评估它们在实际项目中的效果。 3. 识别并推广成功的开发实践：通过实证研究，手册会总结出能够提高效率、降低成本、增强软件质量和可维护性的最佳实践。手册的内容可能包括但不限于以下几个方面： - 软件项目规划：如何制定合理的项目计划，包括时间表、预算、人力资源分配等。 - 风险管理：识别、评估和应对软件开发过程中可能出现的技术和管理风险。 - 团队协作与沟通：促进团队内部的有效沟通，确保信息流动顺畅。 - 质量保证：实施质量控制策略，确保软件产品的质量和可靠性。 - 变更管理：如何处理项目需求变更，以及变更对进度和成本的影响。 - 评估与度量：如何设置和使用关键性能指标（KPIs）来监控项目的进度和成果。 - 工具和技术选择：推荐和解释适用于不同阶段的开发工具和方法。 - 教育和培训：提升团队成员的技能和知识，以适应不断变化的软件开发环境。此外，手册可能还会分享来自SEL的实际案例研究，这些案例可以为项目经理提供宝贵的经验教训和实用建议。这份资源对于那些负责软件开发项目的项目经理来说，是一份非常有价值的参考资料，可以帮助他们更有效地管理和执行项目。

2-1

SECTION 2 — ORGANIZING AND PLANNING

The key to successful software management is to generate a realistic, usable plan and then follow

it. The critical early stages of organizing and planning lay the foundation for effective project

management and control.

ORGANIZING THE PROJECT

To get started, the manager must gain a clear understanding of the scope of the project and must

establish the basis for control. The major initial concerns relate to clarifying the requirements, the

deliverables, and the organizational framework. By addressing the four sets of questions below,

the manager will acquire an understanding of the key elements that will affect project planning.

Identifying the Requirements

What functions must the system perform?

How will the system be operated?

Are the boundaries of the system visible?

In what form does the job definition exist?

Is the current job definition understandable?

Does the project depend on external events or activities?

Identifying the Products and Deliverables

What documents, programs, and files are specified as deliverable products?

When must they be delivered?

In what form are the deliverables, e.g., draft copies or on tape?

Who will receive the deliverables and accept the final product?

What criteria will be used to judge the acceptability of the final product?

Preparing for Control

Is there a timetable for periodic reporting of project status?

What is the procedure for incorporating requirements changes that affect the scope of the

work?

What reviews will be necessary to mark the transitions between phases?

Are there technical or managerial risks to successful completion of the project?

What measures will be used to assess project health?

Establishing an Organizational Identity

Who will be the key contact people from the customer, developer, and support groups?

Do the different groups understand their areas of project responsibility?

Where will the development work be done?

Which development computers will be used?

What level of access to the computers will be required?

2-2

PRODUCING THE SOFTWARE DEVELOPMENT/MANAGEMENT PLAN

In many environments, the software management plan and the software development plan are

separate policy documents with different orientations. The management plan is directed toward the

broader aspects of administration and control, e.g., project-level monitoring of resource

expenditures and the functioning of the configuration control board (CCB). The development

plan focuses more on methods and approaches to software production, e.g., testing strategies and

programming methodologies. Although these differences exist between the two plans, there is

generally some material in common.

ln the flight dynamics environment of the SEL, the two plans are combined into a single

document, the software development/management plan. Although the remainder of this section

describes the contents of a single combined plan, the reader is encouraged to separate the contents

into two plans if that is more appropriate to the needs of his/her environment. In either case, the

items in this section must be formally addressed for a project to be successful.

The software development/management plan provides a disciplined approach to organizing and

managing the software project. A successful plan serves as

• A structured checklist of important questions

• Consistent documentation for project organization

• A baseline reference with which to compare actual project performance and experiences

• A detailed clarification of the management approach to be used

By completing the plan early in the life cycle, the manager becomes familiar with the essential

steps of organizing the development effort:

• Estimating resources

• Establishing schedules

• Assembling a staff

• Setting milestones

The plan should concentrate on information that is unique or tailored to the project at hand. If

standard policies, guidelines, or procedures will be applied to an aspect of the project, the plan

should reference the documents in which these are defined rather than restating them in detail.

Writing the plan can begin as soon as any information about the project definition and scope

becomes available. The plan should be completed by the end of the requirements analysis phase,

except for information available only at later phases. If items in the software development/

management plan are missing for any reason, the manager should indicate who will supply the

information and when it will be supplied.

Copies of the plan should be provided to all levels of project management and the project's

technical staff.

Figure 2-l presents the suggested format and contents for the software development/management

plan, including several references to sections of this handbook for detailed descriptions. The

format is intended as a guide. Depending on the application environment, a different arrangement

of items or the addition of new material may be appropriate.

2-3

SOFTWARE DEVELOPMENT/MANAGEMENT PLAN

Sections in italics describe material that is to be regularly added to the plan during the life of the

project. Other sections should be revised and reissued if circumstances require significant changes in

approach.

TITLE PAGE — document number, project and task names, report title, and report date.

LEAD SHEET — document identification numbers, project and task names, report title, customer

name, preparers, contract and task identifiers, and report date.

TABLE OF CONTENTS — list of subsection titles and page numbers.

1. INTRODUCTION

1.1 Purpose — brief statement of the project's purpose.

1.2 Background — brief description that shows where the software products produced

by the project fit in the overall system.

1.3 Organization and Responsibilities

1.3.1 Project Personnel

—

explanation and diagram of how the development team

will organize activities and personnel to carry out the project: types and numbers

of personnel assigned, reporting relationships, and team members' authorities and

responsibilities (see Section 3 for guidelines on team composition).

1.3.2 Interfacing Groups — list of interfacing groups, points of contact, and group

responsibilities.

2. STATEMENT OF PROBLEM — brief elaboration of the key requirements, the steps to

be done, the steps (numbered) necessary to do it, and the relation (if any) to other

projects.

3. TECHNICAL APPROACH

3.1 Reuse Strategy — description of the current plan for reusing software from

existing systems.

3.2 Assumptions and Constraints

—

that govern the manner in which the work

will be performed.

3.3 Anticipated and Unresolved Problems

—

that may affect the work and the

expected effect on each phase.

3.4 Development Environment — target development machine and programming

languages.

3.5 Activities, Tools, and Products

— for each phase, a matrix showing: a) the

major activities to be performed, b) the development methodologies and tools to be

applied, and c) the products of the phase (see Section 4). Includes discussion of

any unique approaches or activities.

3.6 Build Strategy — what portions of the system will be implemented in which

builds and the rationale.

Updated at the end of detailed design and after each build.

4. MANAGEMENT APPROACH

4.1 Assumptions and Constraints — that affect the management approach,

including project priorities.

4.2 Resource Requirements

—

tabular lists of estimated levels of resources

required, including estimates of system size (new and reused LOC and modules), staff

effort (managerial, programmer, and support) by phase, training requirements, and

computer resources (see Section 3). Includes estimation methods or rationale used.

Updated estimates are added at the end of each phase.

Figure 2-1. Software Development/Management Plan Contents (1 of 2)

2-6

4.3 Milestones and Schedules

—

list of work to be done, who will do it, and when it

will be completed. Includes development life cycle (phase start and finish dates);

build/release dates; delivery dates of required external interfaces; schedule for

integration of externally developed software and hardware; list of data, information,

documents, software, hardware, and support to be supplied by external sources and

delivery dates; list of data, information, documents, software, and support to be

delivered to the customer and delivery dates; and schedule for reviews (internal and

external).

Updated schedules are added at the end of each phase.

4.4 Metrics — a table showing, by phase, which metrics will be collected to capture

project data for historical analysis and which will be used by management to

monitor progress and product quality (see Section 6 and Reference 3). If standard

metrics will be collected, references to the relevant standards and procedures will

suffice. Describes any measures or data collection methods unique to the project.

4.5 Risk Management — statements of each technical and managerial risk or

concern and how it is to be mitigated.

Updated at the end of each phase to

incorporate any new concerns.

5. PRODUCT ASSURANCE

5.1 Assumptions and Constraints — that affect the type and degree of quality

control and configuration management to be employed.

5.2 Quality Assurance (QA) — table of methods and standards used to ensure the

quality of the development process and products (by phase). Where these do not

deviate from published methods and standards, the table references the appropriate

documentation.

Means of ensuring or promoting quality that are innovative or

unique to the project are described explicitly. Identifies the person(s) responsible for

QA on the project, and defines his/her functions and products by phase.

5.3 Configuration Management (CM) — table showing products controlled, tools and

procedures used to ensure the integrity of the system configuration: when the

system is under control, how changes are requested, who makes the changes, etc.

Unique procedures are discussed in detail. If standard CM practices are to be

applied, references to the appropriate documents are sufficient. Identifies the

person responsible for CM and describes this role.

Updated before the beginning of

each new phase with detailed CM procedures for the phase, including naming

conventions, CM directory designations, reuse libraries, etc.

6. REFERENCES

7. PLAN UPDATE HISTORY —

development plan lead sheets from each update indicating

which sections were updated.

Figure 2-1. Software Development/Management Plan Contents (2 of 2)

剩余78页未读，继续阅读

windsfan

粉丝: 0
资源: 1

NASA的软件开发项目经理手册

软件开发经理手册：实践与策略(修订版)

《项目经理手册》：解决管理困惑，提升流程效率

软件项目经理实战指南：保质保量完成开发

项目经理手册(软件交付)

软件项目经理手册--对项目开发与管理有帮助

软件项目经理手册.docx

软件项目经理手册范本.docx

医疗软件项目经理手册.doc

软件项目经理必读手册

项目经理手册（项目经理要做的工作）

最新资源