The document discusses the artifacts of the software project management process. It is organized into five sets: management set, engineering set, implementation set, test set, and deployment set. The management set includes artifacts like the work breakdown structure, business case, software development plan, and release specification. The engineering set contains the vision document, architecture description, and software user manual. The process focuses on creating traceable artifacts from the requirements through each phase of development.

1. Software Project
Management
Walker Royce
Ms. Munazza mah Jabeen
Assistant professor – computer science

2. Artifacts of the Process:
Conventional software projects focused on the sequential development of software
artefacts:
 Build the requirements.
 Construct a design model traceable to the requirements.
 Compile and test the implementation for deployment.
 This process can work for small-scale, purely custom developments in which the
design representation, implementation representation and deployment
representation are closely aligned.
 This approach is doesn't work for most of today’s s/w systems why because of
having complexity and are composed of numerous components some are custom,
some reused, some commercial products.

3. THE ARTIFACT SETS:
The artefacts of the process are organized into five sets:

4. THE MANAGEMENT SET:
The management set includes several artifacts :
 Work Breakdown Structure:
 vehicle for budgeting and collecting costs.
 The software project manager must have insight into project costs and how
they are expended. If the WBS is structured improperly, it can drive the evolving
design in the wrong direction.
 Business Case:
 It provides all the information necessary to determine whether the
project is worth investing in. It details the expected revenue,
expected cost, technical and management plans.

5. THE MANAGEMENT SET:
Typical Release Specification Outline:
Two important forms of requirements :
 vision statement (or user need) -
which captures the contract between
the development group and the
buyer.
 evaluation criteria – defined as
management-oriented requirements,
which may be represented by use
cases, use case realizations or
structured text representations.
 Iteration content
 Measurable objectives
 Evaluation criteria
 Follow-through approach
 Demonstration plan
 Schedule of activities
 Team responsibilities
 Operational scenarios (use cases
demonstrated)
 Demonstration procedures
 Traceability to vision and business
case

6.  Software Development Plan
 The defining document for the project’s process. It must comply with the contract,
comply with the organization standards, evolve along with the design and
requirements.
 Deployment
 Depending on the project, it could include several document subsets for transitioning
the product into operational status. It could also include computer system operations
manuals, software installation manuals, plans and procedures for cutover etc.
 Environment
 A robust development environment must support automation of the development
process.
 It should include :
 requirements management
 visual modeling
 document automation
 automated regression testing
THE MANAGEMENT SET:

7. THE ENGINEERING SET:
Generally there are three engineering artifacts :
 Vision document:
 It supports the contract between the funding authority and the development organization.
 It is written from the user’s perspective, focusing on the essential features of the system.
 It should contain at least two appendixes
 the first appendix should describe the operational concept using use cases
 the second should describe the change risks inherent in the vision statement.
 Architecture Description:
 it is extracted from the design model and includes views of the design, implementation, and deployment sets sufficient
to understand how the operational concept of the requirements set will be achieved.
 Software User Manual:
 it should include installation procedures, usage procedures and guidance, operational constraints, and a user interface
description.
 It should be written by members of the test team, who are more likely to understand the user’s perspective than the
development team.
 It also provides a necessary basis for test plans and test cases, and for construction of automated test suites.

8. Over the past 30 years, the quality of documents become more
important than the quality of the engineering information they
represented.
 The reviewer must be knowledgeable in the engineering
notation.
 Human-readable engineering artifacts should use rigorous
notations that are complete, consistent, and used in a self-
documenting manner.
 Paper is tangible, electronic artifacts are too easy to change.
 Short documents are more useful than long ones.
Pragmatic Artefacts: