Intro toRational Unified ProcessSoftware Process ImprovementMarion Lepmets8.12.2003

Tarkvara-arendus raamistik

Rational Unified Process - RUPSoftware development approach:

IterativeArchitecture-centricUse-case-drivenSoftware engineering process:

Who is responsible for whatHow things are doneWhen to do themProcess product:

Several out-of-the-box Process Configurations and Process Views that guide developers in sw development

RUP ApproachEssential Principles:

Attack major risks early and continuouslyEnsure that you deliver value to your customerStay focused on executable softwareAccommodate change early in the projectBaseline an executable architecture early onBuild your system with componentsWork together as one teamMake quality a way of life, not an afterthought

RUP Approach

RUP vs WaterfallWaterfall development approach

Development phases are in a strict sequenceLeaves key team members idle for extended period of timeLeaves testing to the end of the project lifecycleRUP approach

Iterative: a sequence of incremental steps or iterationsEach iteration includes most development disciplinesEach successive iteration builds on the work of previous iterationsEarly iterations focus on requirements, later iterations on implementation and testing

RUP Approach

Iterative approachIterative is superior to waterfall:

Accommodates changing requirementsIntegration is not one big bang at the end of the projectRisks are discovered and addressed during early integrationsReuse is facilitatedDefects can be found and corrected over several iterationsBetter use of project personnelTeam members learn along the wayThe development is improved along the wayThe number, duration and objectives of iterations need to be carefully plannedTasks and responsibilities of participants need to be defined

RUP Approach

RUP ProcessA well-defined software engineering processThe process has two structures:

Dynamic structure: shows how the process, expressed in terms of cycles, phases, iterations, and milestones, unfolds over the lifecycle of a project. Represents the time dimension.Static structure: shows how process elements activities, disciplines, artifacts and roles are logically grouped into core process disciplines (workflows).

RUP Process

Dynamic Structure of Rational Unified ProcessRUP divides a project into four phases:

Inception phase: Understand the scope of the projectBuild the business caseGet stakeholder buy-in to move aheadElaboration phase:Mitigate major technical risksCreate a baseline architectureUnderstand what it takes to build the systemConstruction phase:Build the first operation version of the productTransition phase:Build the final version of the product and deliver it to the customerEach phase contains one or more iterations

RUP Process

Static Structure of Rational Unified Process (1/2)How process elements are logically grouped into core process disciplinesProcess describes who is doing what, how and whenFour key modeling elements of the RUP:

The who Roles The how Activities:Thinking steps understanding the taskPerforming steps creating or updating artifactsReviewing steps inspecting results against a criteriaThe what Artifacts The when Workflows

RUP Process

Static Structure of Rational Unified Process (2/2)RUP Disciplines:

Business modelingRequirements managementAnalysis and designImplementationDeploymentTestProject managementChange managementEnvironment

RUP Process

RUP ProductRUP product constitutes a complete process framework composed of several integrated parts:

Best practicesProcess delivery toolsConfiguration toolsProcess authoring toolsCommunity/Marketplace

RUP Product

The Spirit of RUPAttack major risks early and continuouslyEnsure that you deliver value to your customerStay focused on executable softwareAccommodate change early in the projectBaseline an executable architecture early onBuild your system with componentsWork together as one teamMake quality a way of life, not an afterthought

Attack Risks EarlyAttack major risks early and continuously, or they will attack you!, Tom GilbUnaddressed risks

Correct architectureAccurate project estimationDeal with risks at the beginning of each iterationThe right architecture design, implement and test it in elaboration phaseAttack risks constantly

Deliver Value to Your CustomerContinuous feedback loops from customersUse case driven approach

Focus on users perspectiveValidate the design and implementation with respect of user requirements through sequence or collaboration diagramsSolid basis for writing user manuals

Focus on Executable SoftwareMeasure progress by measuring executable softwareArtifacts other than the actual software are supporting artifacts

Minimise the number of artifacts produced to reduce overhead

Accommodate Change Early in the ProjectCost of change to business solutionCost of change to the architectureCost of change to the design and implementationCost of change to the scopeChange management

Baseline Executable Architecture Early OnPrimary objective of Elaboration phase - baseline a functioning architectureArchitecture comprises of software systems most important building blocks and their interfacesArchitecture provides a sceleton structure of the system 10-20% of final amount of code

Accurate assessments of resource and time estimates of the projectNew members are easily introduced to the projectReady-made solutions to common problems

Build Your System With ComponentsFunctional decomposition architectureComponent-based architecture

Systems more resilient to changes in requirements, technology and dataEncapsulationReuse

Work Together as One Team Teams are organised around architectureCommunication between team membersReduce the amount if documentation to the extent possible

Make Quality a Way of LifeIterative development allows to initiate testing much earlier than waterfall developmentRUP requires to test capabilities while implementing increase on qualityMore testingQuality in every development phase

Comparison of processes: RUP, agile methods and government standardsLow Ceremony: produces minimum supporting documentation and has little formalism in the working procedureHigh Ceremony: comprehensive supporting documentation and traceability maintained among artifactsWaterfall: linear approach with late integration and testingIterative: risk-driven development approach with early implementation of an architecture and early integration and testing

Agile Development: Low Ceremony, Iterative ApproachFlexibility and ability to adapt to evolving business environmentsRespond to changes that occur during the processIterative development with strong focus on executable softwareMinimising the ceremony surrounding software developmentIncreasingly complex projects require more ceremony than a small project

Process Assessment Frameworks: CMM, CMMI and ISO/IEC 15504Companies in need of high ceremony approaches:

Complex systemsDistributed teamsCost of maintenance is lowCost of development is highTime to market slower than for low-ceremony approaches

The RUP: Iterative Approach with an Adaptable Level of CeremonyRUP is a customisable process frameworkUsers can produce a variety of processes or RUP configurations:

Light RUP configurations with low ceremonyAverage RUP configurations with an average level of ceremonyLarge, more formal RUP configurations with high ceremony

How Iterative Do You Want to Be?For a highly iterative, risk-driven approach with continuous integration and testing you need:

Know-howGood process supportGood tool support

How Much Ceremony Do You Want?Project factors for lower ceremony:

Operating in a rapidly changing marketplaceCo-located teamsSmall teamsLess technical complexityProject factors for higher ceremony:

Large-scale developmentDistributed developmentTechnically complex projectsComplex stakeholder relationships

SPI Software Process ImprovementSoftware Process AssessmentSoftware Process ImprovementBenefits of SPI:

Increase in productivity (10-30% - judged by companies)Lifecycle of production shortensTraceability of results possible transparency Personnel skills and know-how growingThe management and roles in organisation clarified

Tarkvaraprotsesside parandamise etapid

(Part 2)

Software Process Models and StandardsISO/IEC 15504 Information Technology: Process AssessmentCMM-SW Capability Maturity Model for SoftwareCMMI staged and continuous representationISO 9001 Quality systems-Model for quality assurance in design, development, production, installation and servicingBOOTSTRAP model and methodologyISO/IEC 12207 International Standard of Software Life-cycle Processes

DefinitionsProcess: a set of interrelated activities, which transform inputs into outputsPractice: a software engineering or management activity that contributes to the creation of the output (work products) of a process or enhances the capability of a processProcess assessment: a disciplined evaluation of an organisations software processes against a model compatible with the reference modelProcess improvement: action taken to change an organisations processes so that they meet the organisations business needs and achieve its business goals more effectivelyProcess capability: the ability of a process to achieve a required goalProcess performance: the extent to which the execution of a process achieves its purpose

Marion Lepmets

Tallinna TehnikalikoolArvutitehnika instituutRaja 15, Tallinn 12617Telefon: +372 6202 260Email: marion.lepmets@ttu.eewww: http://www.pori.tut.fi/~marion