USDP (Unified Software Development Process)

Unified Software Development Process

DEFINITION

• Is an iterative and incremental software development framework from which a customized process can be defined.
• The framework contains many components and has been modified a number of times to create several variations.

The key characteristics

• -It is an iterative and incremental development framework
• -It is arch itectu re-centric with major work being done to define and validate an architectural
• design for most coding is done
• - lt is risk-focused and emphasiles that highest-risk factors be addressed in the earliest
• deliverables possible
• - lt is use-case and UML model driven with neaer all requirements being documented in one of
• those forms

Best Practices

• 1.- Development Software Iteratively
• 2.- Manage Requirements
• 3.- Use Component Based Architectures
• 4.- Visually Model Software
• 5.- Verify Software Quality
• 6.- Control Changes to Software

Components

• The undified process framework is made up to the dollowing components
• - Cycles
• - Phases
• - Iterations
• -Diciplines
• - Activities
• - Artifacts
• - Workers

Diciplines

• The diciplines are:
• - Business modeling
• - Requirements
• - Analisis and designe
• - Testing
• - Development
• - Configuration and change management
• - Enviroment

Phases

• The four phases are:
• - Inception Phase
• - Elaboration Phase
• - Construction Phase
• - Transistion Phase

The Diciplines

Business Modeling

• The business modeling diciplines focused on efforts to understand the organization, its processes, and the problem domain. The dicipline focuse on understanding the following factor and how they may impact or related to the software being considered:
• - Enterprise business rules
• - Enterprise business process model
• - Enterprise domain model
• - Enterprise mission statements
• - Enterprise vision
• - Organization model

Requirements

• The requirements discipline in RUP is like the requirements discipline in pretty much every other software process. The main difference is that RUP requirements are highly focused in the form of UML models and Use Cases.

Analysis and Design

• The Analysis and Design discipline would be better named the Solution Analysis and Design discipline. This is because the requirements are analysed from a solution design perspective, rather than a requirements analysis perspective. Specific activities that are part of the discipline include:
• - Understanding and analyzing the requirementss for the system
• - Defining a candidate architecture for a system
• - Constructing a proof of concept or prototype to validate a candidate architecture
• - Design of components , services and modules
• - Design of interfaces

Implementation

• The implementation discipline consists of coding, unit testing, and integration of the software

Testing

• The Testing discipline is focused on quality assurance of the software being released in that cycle or iteration. It includes such activities as:
• - Planning test efforts
• - Creating test cases
• - Running tests
• - Reporting defects

Deployment

• The Deployment discipline is focused on planning the deployment of, and actually deploying, the
• software that is being completed that cycle, phase or iterations It includes such activities as:
• - Planning the deployment
• - Developing support and operations materials
• - Planning alpha, beta, and pilot testing efforts
• - Deploying the software
• - Training end users
• - Managing acceptance testing efforts

Configuration and Change Management

• The Configuration and Change Management discipline is focused on managing change to the project’s work products. This includes such activities as:
• - Managing change requests
• - Setting up the Change Management process and environment
• - Planning configuration control
• - Monitoring and reporting the configuration status
• - Managing baselines and releases

Project Management

• The Project Management discipline is focused on standard project management activities such as:
• - Managing project staff
• - Stakeholder coordination and management
• - Managing project risks
• - Project estimating, planning, and scheduling
• - lteration planning
• - Project initiation and close—out

Environment

• The Environment discipline is focused on supporting the overall project and development efforts through managing environmental factors such as:
• - Processes
• - Standards
• - Tools (hardware, software, etc.)

The Phases

Inception Phase

• The Inception Phase is the part of the framework when the "why" of the development effort is defined. This includes such activities as:
• - Defining the business case
• - Creating a vision document with core requirements, features, and constraints
• - Creating an initial risk assessment
• - Creating early use cases (10-20% complete, mostly use-case models)
• - Creating 3 initial project plan
• - And the creation of one or more prototypes (especially architectural prototypes)
• The milestones (that together comprise the Lifecycle Objectives Milestone) that show completion
• of the Inception phase are:
• -Stakeholder agreement on business case, scope, and project cost and schedule estimates
• - Agreement that the content of the primary use cases is an accurate representation of what the
• software will deliver (at a high level)
• - That the final prototypes are sufficient indications of the correct future development goals

Elaboration Phase

• The Elaboration Phase is the part of the framework when more detailed analysis and planning are undertaken to better understand the problem domain, develop a more concrete project plan, identify and eliminate the high-risk elements of the effort, and to establish a solid architectural foundation for the software to be developed. The goal is to develop a "mile wide and inch deep"
• view of the system to be developed.
• The specific activities of this phase include:
• - The identification of all actors and use cases, with most use cases having been defined to at least 80% completion (use-case descriptions rather than models)
• - Supplementary requirements detailing the non-fu nctional requirements and any requirements not related to a use case are completed
• - A Software Architecture Description has been completed
• - The business case and risk lists have been updated with higher-confidence information
• - The project and development plans have been defined to at least a level that shows all iterations and the evaluation criteria for each iteration
• - An executable architecture prototype has been created and approved for use (this may involve creating more than one)
• - A preliminary user manual has been created (optional)

Folie 21

• The milestones (that together comprise the Lifecycle Architecture Milestone) that show completion
• of the Elaboration phase are:
• - The product vision is stable and approved
• - The product architecture is stable and approved
• - The executable architecture prototype shows that the major risk elements have been identified and credibly resolved
• - The project and development plans sufficiently detailed, accurate, and credible
• - All stakeholders agree that the vision can be achieved is the project and development plans are executed with the architecture specified

Construction Phase

• The Construction Phase is the part of the framework where software development, integration, and testing takes place. Because of the emphasis on component-based architectures and the significant attention paid to the architectural plan in the Inception and Elaboration phases, it should be possible to initiate multiple Construction Phases within a single cycle if the software to be developed is complex enough to support multiple discreet components.
• The specific activities of this phase include:
• - The software is built, integrated, and tested
• - The user manuals have been created (or updated)
• - The details of the software developed are documented and ready to be provided to end users or support staff (including changes, etc.)

Folie 23

• The milestones (that together comprise the Initial Operational Capability Milestone) that show completion of the Construction phase are:
• - The software product is stable and mature enough to be deployed to end users
• - All stakeholders are ready to transition to the new / updated software
• - ActuaI versus planned expenditures are still acceptable enough to move forward with the project
• - The outcome of the construction phase should be a product that is ready to put into the hands of end-users in at least a "beta" release state.

Transition Phase

• The Transition Phase of the framework is where the software is deployed to end users and is essentially a broad “beta” test of the application. Users begin to use the new software, issues are identified and potentially corrected, and any features that were delayed are finished and deployed.
• The transition phase can include multiple iterations of the software, including beta releases, bug
• fixes, and enhancements.
• The specific activities of this phase include:
• - ”beta testing" or "user acceptance testing" by end users to validate the new software against user expectations
• - Parallel operation with legacy systems (if in existence) that will be replaced
• -OperationaI databases are converted (if necessary)
• - Users and maintainers of the software are fully trained
• - The software is fully rolled-out
• - The milestones (that together comprise the Product Release Milestone) that show completion of the Transition phase are:
• - Users are satisfied with the software
• - Actual versus planned expenditures are still acceptable enough to move forward with the project