Software Production Layout_Se lect7 btech

Software Production Layout

Software ProcessSoftware Process

instantiated by ProjectProject

ProjectProject

ProjectProject

Project Management• Planning• Control

Project Management• Planning• Control

Project Execution• Analysis• Design• Implementation• Test

Project Execution• Analysis• Design• Implementation• Test

consists of consists of

ProjectManagementMethodology

ProjectManagementMethodology Software

DevelopmentMethodology

SoftwareDevelopmentMethodology

usesuses

System ofmethods forprojectmanagement

System ofmethods forsoftware productdevelopment

is a is a

A Definition of Process

Relationships of all tasks (workflow)

Tools Skills, Training,

Motivation, &Management

PROCESS

AB

CD

W. Humphrey and P. Feiler: "A process is a set of partially ordered steps intended to reach a goal..."(to produce and maintain requested software deliverables). A software process includes sets of related artifacts, human and computerized resources, organizational structures and constraints.

W. Humphrey and P. Feiler: "A process is a set of partially ordered steps intended to reach a goal..."(to produce and maintain requested software deliverables). A software process includes sets of related artifacts, human and computerized resources, organizational structures and constraints.

Rational Unified Process®

• The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.

The Unified Process of Software Development

• The key feature:Software development is done in a series of fixed periods, for example, between 2 and 6 weeks. Each period is called as iteration.

• At the end of each iteration, we have an executable system.

• Each iteration has its own requirement analysis, design, coding and testing.

• The software development is incremental. Implement New features added apart from the User’s suggested changes.

Rational Unified Process (RUP)

Project ManagementEnvironment

Supporting WorkflowsConfiguration & Change Mgmt

Business Modeling

Implementation

Test

Analysis & Design

Process Workflows

Deployment

Requirements

Preliminary Iteration(s)

Iter.#1

Phases

Iterations

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Elaboration TransitionInception Construction

time

co

nte

nt

completetargeted

requirements

Step n:Analyzerequirements

Step n+3: Test

Step n+2: Implement

Step n+1: Design

Product:classmodels +

Product: requirementsspecifications

Product: code + Product: test results +

Spiral Development

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Iteration No.

Incremental Development

Analyzerequirements

Test whole

Implement

Design

Test units

Integrate

1 2 3 867 868

Update SRS3

Update SDD2

Update source code

Update Test documentation

Update SPMP1

1 Software Project Mangement Plan (chapter 2); 2 Software Design Document (chapter 5); 3 Software Requirements Specification (chapter 3);


The Unified Software Development Process: Classification of Iterations

• Inception iterations: preliminary interaction with stakeholders– primarily customer– users– financial backers etc.

• Elaboration iterations : finalization of what’s wanted and needed; set architecture baseline

• Construction iterations : results in initial operational capability

• Transition iterations : completes product release


ElaborationInception Construction Transition

Requirements

Analysis

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

….. …..Prelim.iterations

USDP vs. Standard Terminology ½ (Booch, Jacobson & Rumbaugh)

Design

Implemen-tation

Test

USDP calls these “core workflows”

(Classically called “phases”)

Classification of iterations

Individual iteration

Elaboration

Unified Process Matrix

Inception Construction Transition

Requirements

Analysis

Jacobson et al: USDP

Prelim.iterations

Iter.#1

Iter.#n

Iter.#n+1

Iter.#m

Iter.#m+1

Iter.#k

….. …..

Design

Implemen-tation

Test

..

Amount of effort expendedon the requirements phaseduring the first Constructioniteration

The Six USDP Models (Views of the Application)

Use-casemodel

Analysismodel

Designmodel

Deploymentmodel

Implementationmodel

Testmodel

Graphics reproduced with permission from Corel.

Life of the Unified Process

12

Birth Death

Cycles

InceptionThe seed idea for the

development is brought to the point of being sufficiently

well founded to warrant entering into the elaboration

phase

ElaborationThe architecture

is defined

ConstructionThe software is brought

from an executable architectural baseline

to the point where it is ready to be transitioned to the user community

TransitionThe software is

turned over to the user community

Iteration 1 Iteration 2

... ...

... ...

Iteration nIteration n-1


development is brought tothe point of being sufficiently

well founded to warrantentering into the elaboration

phase


is defined


from an executablearchitectural baselineto the point where it isready to be transitionedto the user community


turned over to theuser community


... ...

... ...





phase


is defined






... ...

... ...





phase


is defined


from an executablearchitectural baseline

to the point where it isready to be transitionedto the user community




... ...

... ...





phase


is defined






... ...

... ...

Iteration nIteration n-1 ...

Unified Process Models

13

Use Case ModelModels Use Cases and their relationships to users

Analysis ModelRefines the use cases and makes an initial allocation of behavior to set of objects

Design ModelDefines the static structure of the system as subsystems, classes and interfaces and defines the use cases as collaborations of subsystems, classes and interfaces Implementation

ModelIncludes components (representing source code) and the mapping of classes to components

Deployment ModelDefines the physical nodes of computers and the mapping of the components to those nodes

Test ModelDescribes the test cases that verify the use cases

specified by verified by

realized by distributed by

implemented by

The Four Ps in Software Development - People, Project, Product and Process

• People - The architects, developers, testers and the supporting management, users, customers, and stakeholders - Actual Humans!

• Project - The organizational element through which software is managed.

• Product - Artifacts that are created during the life of the project, e.g., models, source code.

• Process - A definition of the complete set of activities needed to transform users’ requirements into a product. A process is a template for creating projects.– Tools - Software that is used to automate the activities defined in the

process.

14

Cycles and Phases

The development cycle is divided in four consecutive phases• Inception: a good idea is developed into a vision of the end

product and the business case for the product is presented.• Elaboration: most of the product requirements are specified

and the system architecture is designed.• Construction: the product is built – completed software is

added to the skeleton (architecture)• Transition: the product is moved to user community (beta

testing, training …)

Each cycle results in a new release of the system, and each is a product ready for delivery. This product has to accommodate the specified needs.

Each cycle results in a new release of the system, and each is a product ready for delivery. This product has to accommodate the specified needs.

Inception phase

• Establishing the project's software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not.

• Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design tradeoffs.

• Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios.

• Estimating the overall cost and schedule for the entire project (and more detailed estimates for the elaboration phase that will immediately follow).

• Estimating potential risks (the sources of unpredictability) • Preparing the supporting environment for the project.

Elaboration phase

• Defining, validating and baselining the architecture as rapidly as practical.

• Refining the Vision, based on new information obtained during the phase, establishing a solid understanding of the most critical use cases that drive the architectural and planning decisions.

• Creating and baselining detailed iteration plans for the construction phase.

• Refining the development case and putting in place the development environment, including the process, tools and automation support required to support the construction team.

• Refining the architecture and selecting components. Potential components are evaluated and the make/buy/reuse decisions sufficiently understood to determine the construction phase cost and schedule with confidence. The selected architectural components are integrated and assessed against the primary scenarios.

Construction phase

• Resource management, control and process optimization

• Complete component development and testing against the defined evaluation criteria

• Assessment of product releases against acceptance criteria for the vision.

Transition phase

• Executing deployment plans. • Finalizing end-user support material.• Testing the deliverable product at the development site. • Creating a product release. • Getting user feedback. • Fine-tuning the product based on feedback.

• Making the product available to end users.

Rational Unified Process®

Best Practices:

• Develop software iteratively

• Manage requirements

• Use component-based architectures

• Visually model software

• Verify software quality

• Control changes to software

1. Manage Your Requirements• Elicit, organize, and document required

functionality and constraints• Track and document tradeoffs and decisions • Business requirements are easily captured and

communicated through use cases• Use cases are important planning instruments

Design Model

Implementation Model Test Model

verifiesrealization influenced by

Use-Case Model

2. Develop Software Iteratively

–An initial design will likely be flawed with respect to its key requirements

–Late-phase discovery of design defects results in costly over-runs and/or project cancellation

InitialInitialPlanningPlanning

PlanningPlanning

RequirementsRequirements

Analysis & DesignAnalysis & Design

ImplementationImplementation

TestTest

DeploymentDeployment

EvaluationEvaluation

ManagementManagementEnvironmentEnvironment

Waterfall Development

T I M E

Subsystem Testing

System Testing

Code & Unit Testing

Design

Requirements Analysis

Waterfall Development: Risk vs. Time

RISK

T I M E

Subsystem Testing

System Testing

Code & Unit Testing

Design

Requirements

Analysis

Risk Profile of an Iterative Development

TransitionTransition

RiskRisk

InceptionInception

ElaborationElaboration

ConstructionConstruction

PreliminaryPreliminaryIterationIteration

Architect.Architect.IterationIteration

Architect.Architect.IterationIteration

Devel. Devel. IterationIteration



TransitionTransitionIterationIteration

TransitionTransitionIterationIteration

Post-Post-deploymentdeployment

WaterfallWaterfall

TimeTime

Iterative Development Characteristics

– Critical risks are resolved before making large investments

– Initial iterations enable early user feedback – Testing and integration are continuous – Objective milestones provide short-term focus– Progress is measured by assessing

implementations– Partial implementations can be deployed

3. Employ Component-based Architecture

• Design, implement and test your architecture up-front!

• A systematic approach to define a “good” architecture

Resilient to change by using well-defined interfaces

By using and reverse engineering components

Derived from top rank use cases

• Design, implement and test your architecture up-front!

• A systematic approach to define a “good” architecture

Resilient to change by using well-defined interfaces

By using and reverse engineering components

Derived from top rank use cases

System-System-softwaresoftware

MiddlewareMiddleware

Business-Business-specificspecific

Application-Application-specificspecific

Component-based Architecture with layers

4. Model Software Visually• Aiding understanding of complex systems

• Exploring and comparing design alternatives at a low cost

• Forming a foundation for implementation

• Capturing requirements precisely

• Communicating decisions unambiguously

Code

Classes

Sub Systems

Visual Modelingraises the levelof abstraction

5. Verify Software Quality• Create tests for each key scenario to ensure that all

requirements are properly implemented

• Unacceptable application performance hurts as much as unacceptable reliability

• Verify software reliability - memory leaks, bottle necks

• Test every iteration - automate test!

Development Deployment

CostSoftware problemsare 100 to 1000 timesmore costly to findand repair after deployment

6. Control Changes to Software

• Control, track and monitor changes to enable iterative development

• Establish secure workspaces for each developer

– Provide isolation from changes made in other workspaces

– Control all software artifacts - models, code, docs, etc.

• Automate integration and build management

ALERTREPORT

WorkspaceManagement

Process Integration

Parallel Development

Build Management

CM is more than just check-in and check-out

Summary: Best Practices of Software Engineering

• The result is software that is– On Time– On Budget – Meets Users Needs

ProjectManager

PerformanceEngineer

ReleaseEngineer

Analyst

DeveloperTesterBestPracticesBestPractices

Develop IterativelyDevelop Iteratively

Manage Manage RequirementsRequirements

Model VisuallyModel Visually

Use Component Use Component ArchitecturesArchitectures

Verify QualityVerify Quality

Control Control ChangeChange

Static Structure of the Process

• A process describes who is doing what, how, and when using certain modeling elements:

Elements of a process

• Workers (Roles) define the behavior and responsibilities of an individual (designer, analyst, programmer ...), or a group of individuals working together as a team.

• Artifacts are things that are produced, modified, or used by a process (model, document, source code …).

• Activities are performed by workers to create or update some artifacts (review design, compile code, perform test …).

• Workflows are sequences of activities that produce results of observable value (business modeling, implementation …).

33

Management and Technical Artifacts

Technical artifacts may be divided into:• Requirements set: business, domain, use case, and

analysis models• Design set: design, and test models• Implementation set: implementation model, source

code, configuration, and data files• Deployment set: deployment model, information about

the way software is actually packaged

The most important kind of artifact are models.

A model is a simplification of reality, created to better understand the system being created.A model is a simplification of reality, created to better understand the system being created.

Core Engineering Workflows

• Business modeling describes the structure and dynamics of the organization

• Requirement describe the use case-based method for eliciting requirements

• Analysis and design describe the multiple architectural views

• Implementation takes into account sw development, unit test, and integration

• Test describes test cases and procedures• Deployment covers the deliverable system configuration

Workflows and Models

Business Process Model Domain Model

Use Case Model

Analysis Model

Desing Model Deployment Model

Implementation Model

Test Model

Business ModelingBusiness Modeling

RequirementsRequirements

AnalysisAnalysis

DesignDesign

ImplementationImplementation

TestTest

UML diagrams provide views into

each model

Each workflow is associated with one or more models

Brief summary of supporting workflows

– Configuration & Change Management– Project Management– Environment

Configuration & Change Management

• Supports development methods• Maintains product integrity• Ensures completeness & correctness of configured

product• Provides stable environment within which to develop

product• Restricts changes to artifacts based on project policies• Provides an audit trail on why, when & by whom any

artifact was changed

Project Management

• A framework for managing software-intensive projects

• Practical guidelines for planning, staffing, executing & monitoring projects

• A framework for managing risk

Environment

• Design, implement and manage the project’s required

technical environments

• Define the technical architectures for the development,

system validation, testing & staging/release management

environments

• When possible, standard architectural models for given

types of platforms should be utilized when defining the

production environment

Bringing It All Together...

Project ManagementEnvironment

Business Modeling

ImplementationTest

Analysis & Design

Preliminary Iteration(s)

Iter.#1

Phases

Process Workflows

Iterations

Supporting Workflows

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Configuration & Change Mgmt

Requirements

Elaboration TransitionInception Construction

In an iteration, you walk through all workflows

Tools

• The success of process adoption is significantly improved by the use of appropriate supporting tools.

• Tool Mentors provide detailed descriptions of how to perform specific process activities or steps, or produce a particular artifact or report, using one or more tools.

Tools

• Rational Unified Process • RUP Builder • Rational Process Workbench • Rational Administrator • Rational Suite AnalystStudio • Rational ClearCase • Rational ClearQuest • Rational ProjectConsole • Rational PurifyPlus • Rational QualityArchitect

Tools

• Rational RequisitePro • Rational Robot • Rational Rose • Rational Rose RealTime • Rational SoDA • Rational TestManager • Rational Test RealTime • Rational TestFactory • Rational XDE Developer - Java Platform Edition • Rational XDE Developer - .NET Edition

Predictive versus adaptive approaches to the SDLC

Choose Appropriate Life CycleChoose Appropriate Life Cycle

• TCL is highly predictive

• Prototyping, Spiral and UP life cycle models are highly

adaptive

Education

Software Production Layout_Se lect7 btech