�Software Project Management�(SPM)�

Unit-II Syllabus

• Life cycle phases: Engineering and production stages, inception, Elaboration, construction, transition phases.
• Artifacts of the process: The artifact sets, Management artifacts, Engineering artifacts, programmatic artifacts, A Management perspective and technical perspective.

Life cycle phases

Life cycle phases

• Characteristic of a successful software development process is the well-defined separation between "research and development" activities and "production" activities. Most unsuccessful projects exhibit one of the following characteristics:
• An overemphasis on research and development
• An overemphasis on production.
• A modern software development process must be defined to support the following:
• Evolution of the plans, requirements, and architecture, together with well defined synchronization points
• Risk management and objective measures of progress and quality
• Evolution of system capabilities through demonstrations of increasing functionality

Engineering And Production Stages

• To achieve economies of scale and higher returns on investment, we must move toward a software manufacturing process driven by technological improvements in process automation and component-based development. Two stages of the life cycle are:
• The engineering stage, driven by less predictable but smaller teams doing design and synthesis activities
• The production stage, driven by more predictable but larger teams doing construction, test, and deployment activities

​

Engineering And Production Stages

• The transition between engineering and production is a crucial event for the various stakeholders. The production plan has been agreed upon, and there is a good enough understanding of the problem and the solution that all stakeholders can make a firm commitment to go ahead with production.
• Engineering stage is decomposed into two distinct phases, inception and elaboration, and the production stage into construction and transition. These four phases of the life-cycle process are loosely mapped to the conceptual framework of the spiral model as shown in Figure 5-1

​

Engineering And Production Stages

Inception Phase

• The overriding goal of the inception phase is to achieve concurrence among stakeholders on the life-cycle objectives for the project.

Primary Objectives

• Establishing the project's software scope and boundary conditions, including an operational concept, acceptance criteria, and a clear understanding of what is and is not intended to be in the product
• Discriminating the critical use cases of the system and the primary scenarios of operation that will drive the major design trade-offs
• Demonstrating at least one candidate architecture against some of the primary scenarios
• Estimating the cost and schedule for the entire project (including detailed estimates for the elaboration phase)
• Estimating potential risks (sources of unpredictability)

​

Inception Phase

Essential Activities

• Formulating the scope of the project. The information repository should be sufficient to define the problem space and derive the acceptance criteria for the end product.
• Synthesizing the architecture. An information repository is created that is sufficient to demonstrate the feasibility of at least one candidate architecture and an, initial baseline of make/buy decisions so that the cost, schedule, and resource estimates can be derived.
• Planning and preparing a business case. Alternatives for risk management, staffing, iteration plans, and cost/schedule/profitability trade-offs are evaluated.

​

Inception Phase

Primary Evaluation Criteria

• Do all stakeholders concur on the scope definition and cost and schedule estimates?
• Are requirements understood, as evidenced by the fidelity of the critical use cases?
• Are the cost and schedule estimates, priorities, risks, and development processes credible?
• Do the depth and breadth of an architecture prototype demonstrate the preceding criteria? (The primary value of prototyping candidate architecture is to provide a vehicle for understanding the scope and assessing the credibility of the development group in solving the particular technical problem.)
• Are actual resource expenditures versus planned expenditures acceptable

​

​

Elaboration Phase

• It is easy to argue that the elaboration phase is the most critical of the four phases.
• The elaboration phase activities must ensure that the architecture, requirements, and plans are stable enough, and the risks sufficiently mitigated, that the cost and schedule for the completion of the development can be predicted within an acceptable range.
• During the elaboration phase, an executable architecture prototype is built in one or more iterations, depending on the scope, size, & risk.

​

Elaboration Phase

Primary Objectives

• Baselining the architecture as rapidly as practical (establishing a configuration-managed snapshot in which all changes are rationalized, tracked, and maintained).
• Baselining the vision.
• Baselining a high-fidelity plan for the construction phase.
• Demonstrating that the baseline architecture will support the vision at a reasonable cost in a reasonable time.

Essential Activities

• Elaborating the vision.
• Elaborating the process and infrastructure.
• Elaborating the architecture and selecting components.

​

​

​

Elaboration Phase

Primary Evaluation Criteria

• Is the vision stable?
• Is the architecture stable?
• Does the executable demonstration show that the major risk elements have been addressed and credibly resolved?
• Is the construction phase plan of sufficient fidelity, and is it backed up with a credible basis of estimate?
• Do all stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system in the context of the current architecture?
• Are actual resource expenditures versus planned expenditures acceptable?

​

​

Construction Phase

• During the construction phase, all remaining components and application features are integrated into the application, and all features are thoroughly tested. Newly developed software is integrated where required.
• The construction phase represents a production process, in which emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality.

​

Construction Phase

Primary Objectives

• Minimizing development costs by optimizing resources and avoiding unnecessary scrap and rework.
• Achieving adequate quality as rapidly as practical.
• Achieving useful versions (alpha, beta, and other test releases) as rapidly as practical.

Essential Activities

• Resource management, control, and process optimization.
• Complete component development and testing against evaluation criteria.
• Assessment of product releases against acceptance criteria of the vision.

​

​

​

​

Construction Phase

Primary Evaluation Criteria

• Is this product baseline mature enough to be deployed in the user community?
• Is this product baseline stable enough to be deployed in the user community?
• Are the stakeholders ready for transition to the user community?
• Are actual resource expenditures versus planned expenditures acceptable?

​

​

Transition Phase

• The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain.
• This phase could include any of the following activities:
• Beta testing to validate the new system against user expectations.
• Beta testing in parallel with legacy system to be replaced
• Conversion of operational databases.
• Training of users and maintainers.

​

​

​

​

Transition Phase

Primary Objectives

• Achieving user self-supportability.
• Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision
• Achieving final product baselines as rapidly and cost-effectively as practical.

​

Transition Phase

Essential Activities

• Synchronization and integration of concurrent construction increments into consistent deployment baselines.
• Deployment-specific engineering (cutover, commercial packaging and production, sales rollout kit development, field personnel training)
• Assessment of deployment baselines against the complete vision and acceptance criteria in the requirements set.

Evaluation Criteria

• Is the user satisfied?
• Are actual resource expenditures versus planned expenditures acceptable?

​

​

​

​

​

Artifacts of the process

Artifacts of the process

• An artifact is one of many kinds of tangible by-product produced during the development of software. Some artifacts (e.g., use cases, class diagrams, and other UML models, requirements and design documents) help describe the function, architecture, and design of software.
• Other artifacts are concerned with the process of development itself—such as project plans, business cases, and risk assessments.

The Artifact Sets

• To make the development of a complete software system manageable, distinct collections of information are organized into artifact sets.
• Artifact represents cohesive information that typically is developed and reviewed as a single entity.
• Software Artifacts are organized into five distinct sets that are roughly partioned by the underlying language of the set: Management set, Requirement set, Design set, Implementation set, Deployment set.
• The Requirement set, Design set, Implementation set, Deployment set are combinely called as Engineering Set.
• The artifact sets are shown in Figure 6-1.

​

Management Set

• The Management Set captures the artifacts associated with process planning and execution.
• These artifacts use ad hoc notations, including text, graphics, or whatever representation is required to capture the "contracts" among project personnel, among stakeholders, and between project personnel and stakeholders.
• These artifacts are mainly designed to capture data associated with process planning and execution.

​

Management Set

• Management Set artifacts are evaluated, assessed and measured through a combination of the following:

--> Relevant stakeholder review.

--> Analysis of changes between current version of artifact and previous versions.

--> Major Milestone demonstrations of the balance among the artifacts and, in particular, the accuracy of the business case and vision artifacts.

​

Engineering Set

• In the Engineering Set, the primary mechanism for evaluating the evolving quality of these artifact sets is in the transitioning of information from set to set thereby maintaining a balance of understanding among the requirements, design, implementation and deployement artifacts.
• The Engineering Set consists of Requirement set, Design set, Implementation set, Deployment set

​

Engineering Set

Requirement Set:The Requirement set is the primary engineering context for evaluating the other three artifact sets and is the basis for test cases.

• Requirements artifacts are evaluated, assessed, and measured through a combination of the following:
• Analysis of consistency with the release specifications of the management set
• Analysis of consistency between the vision and the requirements models
• Mapping against the design, implementation, and deployment sets to evaluate the consistency and completeness
• Analysis of changes between the current version of the design model and previous versions
• Subjective review of other dimensions of quality

​

​

​

​

Engineering Set

Design Set:UML notation is used to engineer the design models for the solution.

• The design set is evaluated, assessed, and measured through a combination of the following:
• Analysis of the internal consistency and quality of the design model
• Analysis of consistency with the requirements models
• Translation into implementation and deployment sets and notations to evaluate the consistency and completeness
• Analysis of changes between the current version of the design model and previous versions
• Subjective review of other dimensions of quality

​

​

Engineering Set

Implementation set:The implementation set includes source code (programming language notations) that represents the tangible implementations of components.

• Implementation sets are human-readable formats that are evaluated, assessed, and measured through a combination of the following:
• Analysis of consistency with the design models
• Translation into deployment set notations to evaluate the consistency and completeness among artifact sets
• Assessment of component source or executable files against relevant evaluation criteria through inspection, analysis, demonstration, or testing
• Analysis of changes between the current version of the implementation set and previous versions
• Subjective review of other dimensions of quality

​

​

​

​

Engineering Set

Deployment Set:The deployment set includes user deliverables and machine language notations, executable software, and the build scripts, installation scripts, and executable target specific data necessary to use the product in its target environment.

• Deployment sets are evaluated, assessed, and measured through a combination of the following:
• Testing against the usage scenarios and quality attributes defined in the requirements set
• Testing against the defined usage scenarios in the user manual such as installation, user-oriented dynamic reconfiguration, mainstream usage, and anomaly management
• Analysis of changes between the current version of the deployment set and previous versions
• Subjective review of other dimensions of quality

​

​

​

Engineering Set

• Each artifact set is the predominant development focus of one phase of the life cycle; the other sets take on check and balance roles.
• As illustrated in Figure 6-2, each phase has a predominant focus: Requirements are the focus of the inception phase; design, the elaboration phase; implementation, the construction phase; and deploy- ment, the transition phase. The management artifacts also evolve, but at a fairly constant level across the life cycle.

​

Most of today's software development tools map closely to one of the five artifact sets.

• Management: scheduling, workflow, defect tracking, change management, documentation, spreadsheet, resource management, and presentation tools
• Requirements: requirements management tools
• Design: visual modeling tools
• Implementation: compiler/debugger tools, code analysis tools, test coverage analysis tools, and test management tools
• Deployment: test coverage and test automation tools, network management tools, commercial components (operating systems, GUIs, RDBMS, networks, middleware), and installation tools.

​

​

​

Implementation Set versus Deployment Set

• The separation of the implementation set (source code) from the deployment set (executable code) is important because there are very different concerns with each set.
• The structure of the information delivered to the user (and typically the test organization) is very different from the structure of the source code information.
• Engineering decisions that have an impact on the quality of the deployment set but are relatively incomprehensible in the design and implementation sets include the following:
• Dynamically reconfigurable parameters (buffer sizes, color palettes, number of servers, number of simultaneous clients, data files, run-time parameters)

​

Implementation Set versus Deployment Set

• Effects of compiler/link optimizations (such as space optimization versus speed optimization)
• Performance under certain allocation strategies (centralized versus distributed, primary and shadow threads, dynamic load balancing, hot backup versus checkpoint/rollback)
• Virtual machine constraints (file descriptors, garbage collection, heap size, maximum record size, disk file rotations)
• Process-level concurrency issues (deadlock and race conditions)
• Platform-specific differences in performance or behavior

​

Artifact Evolution Over The Life Cycle

• Each state of development represents a certain amount of precision in the final system description. Early in the life cycle, precision is low and the representation is generally high.
• Eventually, the precision of representation is high and everything is specified in full detail. Each phase of development focuses on a particular artifact set.
• At the end of each phase, the overall system state will have progressed on all sets, as illustrated in Figure 6-3.
• The inception phase focuses mainly on critical requirements. During the elaboration phase, there is much greater depth in requirements, much more breadth in the design set.
• The main focus of the construction phase is design and implementation. The main focus of the transition phase is on achieving consistency and completeness of the deployment set in the context of the other sets.

​

Test Artifacts

• Test teams built system test plan documents, system test procedures documents, integration test plan documents, unit test plan documents, and unit test procedures documents before building any test drivers, stubs or instrumentation.
• A modern process is to use exactly the same set, notations, and artifacts for the products of test activities as are used for product development.
• By doing this, we have forced several engineering disciplines into the process.
• The test artifacts must be developed concurrently with the product from inception through deployment.
• The test artifacts are communicated, engineered, and developed within the same artifact sets as the developed product.

​

Test Artifacts

• The test artifacts must be developed concurrently with the product from inception through deployment.
• The test artifacts are communicated, engineered, and developed within the same artifact sets as the developed product.
• The test artifacts are implemented in programmable and repeatable formats.
• The test artifacts are documented in the same way that the product is documented.
• Developers of the test artifacts use the same tools, techniques, and training as the software engineers developing the product.

​

​

Management Artifacts

• The management set includes several artifacts that capture intermediate results and ancillary information necessary to document the product/process legacy, maintain the product, improve the product, and improve the process.
• Business Case
• Software Development Plan
• Work Breakdown Structure
• Software change Order Database
• Release Specifications
• Release Descriptions
• Status Assessments
• Environment
• Deployment

​

​

​

Business Case

• The business case artifact 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, and backup data necessary to demonstrate the risks and realism of the plans.
• The main purpose is to transform the vision into economic terms so that an organization can make an accurate ROI assessment.
• Figure 6-4 provides a default outline for a business case.

​

Software Development Plan

• The software development plan (SDP) elaborates the process framework into a fully detailed plan.
• Two indications of a useful SDP are periodic updating and understanding and acceptance by managers and practitioners alike.
• Figure 6-5 provides a default outline for a software development plan.

​

Work Breakdown Structure

• Work breakdown structure (WBS) is the vehicle for budgeting and collecting costs.
• To monitor and control a project's financial performance, the software project manager must have insight into project costs and how they are expended.
• The structure of cost accountability is a serious project planning constraint.

Software Change Order Database

• Managing change is one of the fundamental primitives of an iterative development process.
• With greater change freedom, a project can iterate more productively.
• This flexibility increases the content, quality, and number of iterations that a project can achieve within a given schedule.
• Change freedom has been achieved in practice through automation, and today's iterative development environments carry the burden of change management.

Release Specifications

• The scope, plan, and objective evaluation criteria for each baseline release are derived from the vision statement as well as many other sources.
• These artifacts are intended to evolve along with the process, achieving greater fidelity as the life cycle progresses and requirements understanding matures.
• Figure 6-6 provides a default outline for a release specification.

Release Descriptions

• Release description documents describe the results of each release, including performance against each of the evaluation criteria in the corresponding release specification.
• Release baselines should be accompanied by a release description document that describes the evaluation criteria for that configuration baseline and provides substantiation (through demonstration, testing, inspection, or analysis) that each criterion has been addressed in an acceptable manner.
• Figure 6-7 provides a default outline for a release description.

Status Assessments

• Status assessments provide periodic snapshots of project health and status, including the software project manager's risk assessment, quality indicators, and management indicators.
• Typical status assessments should include a review of resources, personnel staffing, financial data (cost and revenue), top 10 risks, technical progress (metrics snapshots), major milestone plans and results, total project or product scope & action items.

Environment

• An important emphasis of a modern approach is to define the development and maintenance environment as a first-class artifact of the process.
• A robust, integrated development environment must support automation of the development process.
• This environment should include requirements management, visual modeling, document automation, host and target programming tools, automated regression testing, and continuous and integrated change management, and feature and defect tracking.

​

Deployment

• A deployment document can take many forms. Depending on the project, it could include several document subsets for transitioning the product into operational status.
• Deployment artifacts may include computer system operations manuals, software installation manuals, plans and procedures for cutover (from a legacy system), site surveys, and so forth.
• For commercial software products, deployment artifacts may include marketing plans, sales rollout kits, and training courses.

​

Management Artifact Sequences

• In each phase of the life cycle, new artifacts are produced and previously developed artifacts are updated to incorporate lessons learned and to capture further depth and breadth of the solution.
• Figure 6-8 identifies a typical sequence of artifacts across the life-cycle phases.

​

Engineering Artifacts

• Most of the engineering artifacts are captured in rigorous engineering notations such as UML, programming languages, or executable machine codes.
• Three engineering artifacts are explicitly intended for more general review, and they deserve further elaboration.
• Vision Document
• Architecture Description
• Software User Manual

​

​

​

Vision Document

• The vision document provides a complete vision for the software system under development and supports the contract between the funding authority and the development organization.
• A project vision is meant to be changeable as understanding evolves of the requirements, architecture, plans, and technology.
• good vision document should change slowly.
• Figure 6-9 provides a default outline for a vision document.

​

Architecture Description

• The architecture description provides an organized view of the software architecture under development.
• It is extracted largely 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.
• The breadth of the architecture description will vary from project to project depending on many factors.
• Figure 6-10 provides a default outline for an architecture description.

Software User Manual

• The software user manual provides the user with the reference documentation necessary to support the delivered software.
• The user manual should include installation procedures, usage procedures and guidance, operational constraints, and a user interface description, at a minimum.
• The user manual should be written by members of the test team, who are more likely to understand the user's perspective than the development team.

​

Pragmatic Artifacts

• A more effective approach is to redirect this documentation effort to improving the rigor and understandability of the information source and allowing on-line review of the native information source by using smart browsing and navigation tools.
• Such an approach eliminate a huge, unproductive source of scrap and rework in the process and allow for continuous review by everyone who is directly concerned with the evolving on-line artifacts.
• This philosophy raises the following cultural issues.
• People want to review information but don't understand the language of the artifact.
• People want to review the information but don't have access to the tools.

Pragmatic Artifacts

• Human-readable engineering artifacts should use rigorous notations that are complete, consistent, and used in a self-documenting manner.
• Useful documentation is self-defining: It is documentation that gets used.
• Paper is tangible; electronic artifacts are too easy to change.

​

Model based software architecture

Architecture: A Management Perspective

• The most critical technical product of a software project is its architecture.
• If a software development team is to be successful, the inter project communications, as captured in the software architecture, must be both accurate and precise
• From a management perspective, there are three different aspects of architecture.
• An architecture is the design of a software system this includes all engineering necessary to specify a complete bill of materials.
• An architecture baseline is a slice of information across the engineering artifact sets sufficient to satisfy all stakeholders that the vision can be achieved within the parameters of the business case

​

​

Architecture: A Management Perspective

• An architecture description is an organized subset of information extracted from the design set model(s). The architecture description communicates how the intangible concept is realized in the tangible artifacts.
2. The importance of software architecture and its close linkage with modern software development processes can be summarized as follows:
1. Achieving a stable software architecture represents a significant project milestone.
2. Architecture representations provide a basis for balancing the trade-offs between the problem space and the solution space.

​

Architecture: A Management Perspective

• The architecture and process encapsulate many of the important (high-payoff or high-risk) communications among individuals, teams, organizations, and stakeholders.
• Poor architectures and immature processes are often given as reasons for project failures.
• A mature process, an understanding of the primary requirements, and a demonstrable architecture are important prerequisites for predictable planning.
• Architecture development and process definition are the intellectual steps that map the problem to a solution.

Architecture: A Technical Perspective

• An architecture framework is defined in terms of views that are abstractions of the UML models in the design set.
• An architecture view is an abstraction of the design model; it contains only the architecturally significant information.
• Most real-world systems require four views: design, process, component, and deployment. The purposes of these views are as follows:
• Design: describes architecturally significant structures and functions of the design model
• Process: describes concurrency and control thread relationships among the design, component, and deployment views

​

Architecture: A Technical Perspective

• Component: describes the structure of the implementation set
• Deployment: describes the structure of the deployment set

​

• Figure 7-1 summarizes the artifacts of the design set, including the architecture views and architecture description.

​

​

​

Architecture: A Technical Perspective

• Generally, an architecture baseline should include the following:
• Requirements: critical use cases, system-level quality objectives, and priority relationships among features and qualities
• Design: names, attributes, structures, behaviors, groupings, and relationships of significant classes and components
• Implementation: source component inventory and bill of materials (number, name, purpose, cost) of all primitive components
• Deployment: executable components sufficient to demonstrate the critical use cases and the risk associated with achieving the system qualities

​