By Walker RoyceSoftware Project Management

"Software Project Management" Walker Royce2/112Part 1Software Management RenaissanceTable of Contents (1)The Old Way (Conventional SPM)The Waterfall ModelConventional Software Management PerformanceEvolution of Software EconomicsSoftware EconomicsPragmatic Software Cost Estimation

"Software Project Management" Walker Royce3/112Part 1 Software Management RenaissanceTable of Contents (2)Improving Software EconomicsReducing Software Product SizeImproving Software ProcessesImproving Team EffectivenessImproving Automation through Software EnvironmentsAchieving Required QualityPeer Inspections: A Pragmatic ViewThe Old Way and the NewThe Principles of Conventional Software EngineeringThe Principles of Modern Software ManagementTransitioning to an Iterative Process

"Software Project Management" Walker Royce4/112The Old Way

"Software Project Management" Walker Royce5/112Part 1The Old WaySoftware crisis

The best thing about software is its flexibilityIt can be programmed to do almost anything.

The worst thing about software is also its flexibilityThe almost anything characteristic has made it difficult to plan, monitor, and control software development.

"Software Project Management" Walker Royce6/112Part 1The Old WayThe Waterfall ModelDrawbacks

Protracted integration and late design breakageLate risk resolutionRequirements - driven functional decompositionAdversarial stakeholder relationshipsFocus on document and review meetings

Analysis

Program design

Coding

Testing

Maintenance and reliance

Software requirements

System requirements

"Software Project Management" Walker Royce7/112Part 1The Old Way Conventional Software Management PerformanceFinding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases.You can compress software development schedules 25% of nominal, but no more.For every $1 you spend on development, you will spend $2 on maintenance.Software development and maintenance costs are primarily a function of the number of source lines of code.Variations among people account for the biggest differences in software productivity.The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985, 85:15.Only about 15% of software development effort is devoted to programming.Walkthroughs catch 60% of the errors.80% of the contribution comes from 20% of contributors."Software Project Management" Walker Royce8/112Part 1 Evolution of Software Economics

"Software Project Management" Walker Royce9/112Part 1Evolution of Software EconomicsMost software cost models can be abstracted into a function of five basic parameters:

Size (typically, number of source instructions)Process (the ability of the process to avoid non-value-adding activities)Personnel (their experience with the computer science issues and the applications domain issues of the project)Environment (tools and techniques available to support efficient software development and to automate process)Quality (performance, reliability, adaptability)"Software Project Management" Walker Royce10/112Part 1Evolution of Software EconomicsThree generations of software economics

Cost

Software size

1960s-1970sWaterfall modelFunctional designDiseconomy of scale

1980s-1990sProcess improvementEncapsulation-basedDiseconomy of scale

2000 and onIterative developmentComponent- basedReturn to investment

Environments/tools:Custom

Size:100% custom

Process:Ad hoc

Environments/tools:Off-the-shelf, separate

Size:30%component-based, 70% custom

Process:Repeatable

Environments/tools:Off-the-shelf, integrated

Size:70%component-based, 30% custom

Process:Managed/measured

Typical project performance

Predictably badAlways:-Over budget-Over schedule

UnpredictableInfrequently:-On budget-On schedule

PredictableUsually:-On budget-On schedule"Software Project Management" Walker Royce11/112Part 1Evolution of Software EconomicsThe predominant cost estimation process

Software manager, software architecture manager, software development manager,software assessment manager

Cost estimate

Cost modelers

Risks, options, trade-offs, alternatives

"Software Project Management" Walker Royce12/112Part 1Evolution of Software EconomicsPragmatic software cost estimationA good estimate has the following attributes:It is conceived and supported by the project manager, architecture team, development team, and test team accountable for performing the work.It is accepted by all stakeholders as ambitious but realizable.It is based on a well defined software cost model with a credible basis.It is based on a database of relevant project experience that includes similar processes, technologies, environments, quality requirements, and people.It is defined in enough detail so that its key risk areas are understood and the probability of success is objectively assessed.

"Software Project Management" Walker Royce13/112Part 1 Improving Software Economics Five basic parameters of the software cost model:Reducing the size or complexity of what needs to be developedImproving the development processUsing more-skilled personnel and better teams (not necessarily the same thing)Using better environments (tools to automate the process)Trading off or backing off on quality thresholds"Software Project Management" Walker Royce14/112Part 1 Improving Software EconomicsImportant trends in improving software economicsCost model parameters Trends

SizeAbstraction and component based development technologies

Higher order languages (C++, Java, Visual Basic, etc.)Object-oriented (Analysis, design, programming)ReuseCommercial components

ProcessMethods and techniques

Iterative developmentProcess maturity models Architecture-first developmentAcquisition reform

PersonnelPeople factors

Training and personnel skill developmentTeamwork Win-win cultures

EnvironmentAutomation technologies and tools

Integrated tools(Visual modeling, compiler, editor, etc)Open systemsHardware platform performanceAutomation of coding, documents, testing, analyses

QualityPerformance, reliability, accuracy

Hardware platform performanceDemonstration-based assessmentStatistical quality control"Software Project Management" Walker Royce15/112Part 1 Improving Software EconomicsReducing Software Product SizeThe most significant way to improve affordability and return on investment is usually to produce a product that achieves the design goals with the minimum amount of human-generated source material.

Reuse, object-oriented technology, automatic code production, and higher order programming languages are all focused on achieving a given system with fewer lines of human-specified source directives. "Software Project Management" Walker Royce16/112Part 1 Improving Software EconomicsReducing Software Product Size - Languages

LanguageSLOC per UFPAssembly320C128Fortran 77105Cobol 8591Ada 8371C++56Ada 9555Java55Visual Basic35UFP -Universal Function PointsThe basic units of the function pointsare external user inputs, external outputs,internal logic data groups, external data interfaces,and external inquiries.

SLOC metrics are useful estimators for software after a candidate solution is formulated and an implementation language is known."Software Project Management" Walker Royce17/112Part 1 Improving Software EconomicsReducing Software Product Size Object-Oriented MethodsAn object-oriented model of the problem and its solution encourages a common vocabulary between the end users of a system and its developers, thus creating a shared understanding of the problem being solved.Here is an example of how object-oriented technology permits corresponding improvements in teamwork and interpersonal communications.The use of continuous integration creates opportunities to recognize risk early and make incremental corrections without destabilizing the entire development effort.This aspect of object-oriented technology enables an architecture-first process, in which integration is an early and continuous life-cycle activity.An object-oriented architecture provides a clear separation of concerns among disparate elements of a system, creating firewalls that prevent a change in one part of the system from rending the fabric of the entire architecture.This feature of object-oriented technology is crucial to the supporting languages and environments available to implement object-oriented architectures.

"Software Project Management" Walker Royce18/112Part 1 Improving Software EconomicsReducing Software Product Size ReuseNumber of Projects Using Reusable Components

Development Cost and Schedule Resources

1 Project Solution: $N and M months

2 Project Solution: 50% more cost and 100% more time

5 Project Solution: 125% more cost and 150% more time Many-project solution: Operating with high value per unit investment, typical of commercial products"Software Project Management" Walker Royce19/112Part 1 Improving Software EconomicsReducing Software Product Size Commercial Components

APPROACHADVANTAGESDISADVANTAGESCommercial componentsPredictable license costsBroadly used, mature technologyAvailable nowDedicated support organizationHardware/software independenceRich in functionalityFrequent upgradesUp-front license feesRecurring maintenance feesDependency on vendorRun-time efficiency sacrificesFunctionality constraintsIntegration not always trivialNo control over upgrades and maintenanceUnnecessary features that consume extra resourcesOften inadequate reliability and stabilityMultiple-vendor incompatibilityCustom developmentComplete change freedomSmaller, often simpler implementationsOften better performanceControl of development and enhancementExpensive, unpredictable developmentUnpredictable availability dateUndefined maintenance modelOften immature and fragileSingle-platform dependencyDrain on expert resources"Software Project Management" Walker Royce20/112Part 1 Improving Software EconomicsImproving Software Processes

AttributesMetaprocessMacroprocessMicroprocessSubjectLine of businessProjectIterationObjectivesLine-of-business profitabilityCompetitivenessProject profitabilityRisk managementProject budget, schedule, qualityResource managementRisk resolutionMilestone budget, schedule, qualityAudienceAcquisition authorities, customersOrganizational managementSoftware project managersSoftware engineersSubproject managersSoftware engineersMetricsProject predictabilityRevenue, market shareOn budget, on scheduleMajor milestone successProject scrap and reworkOn budget, on scheduleMajor milestone progressRelease/iteration scrap and reworkConcernsBureaucracy vs. standardizationQuality vs. financial performanceContent vs. scheduleTime scales6 to 12 months1 to many years1 to 6 monthsThree levels of processes and their attributes"Software Project Management" Walker Royce21/112

"Software Project Management" Walker Royce22/112Part 1 Improving Software EconomicsImproving Team Effectiveness (1)The principle of top talent: Use better and fewer people.The principle of job matching: Fit the task to the skills an motivation of the people available.The principle of career progression: An organization does best in the long run by helping its people to self-actualize.The principle of team balance: Select people who will complement and harmonize with one another.The principle of phase-out: Keeping a misfit on the team doesnt benefit anyone.

"Software Project Management" Walker Royce23/112Part 1 Improving Software EconomicsImproving Team Effectiveness (2)Important Project Manager Skills:Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the right job seems obvious but is surprisingly hard to achieve.Customer-interface skill. Avoiding adversarial relationships among stake-holders is a prerequisite for success.Decision-making skill. The jillion books written about management have failed to provide a clear definition of this attribute. We all know a good leader when we run into one, and decision-making skill seems obvious despite its intangible definition.Team-building skill. Teamwork requires that a manager establish trust, motivate progress, exploit eccentric prima donnas, transition average people into top performers, eliminate misfits, and consolidate diverse opinions into a team direction.Selling skill. Successful project managers must sell all stakeholders (including themselves) on decisions and priorities, sell candidates on job positions, sell changes to the status quo in the face of resistance, and sell achievements against objectives. In practice, selling requires continuous negotiation, compromise, and empathy. "Software Project Management" Walker Royce24/112Part 1 Improving Software EconomicsAchieving Required QualityKey practices that improve overall software quality:Focusing on driving requirements and critical use cases early in the life cycle, focusing on requirements completeness and traceability late in the life cycle, and focusing throughout the life cycle on a balance between requirements evolution, design evolution, and plan evolutionUsing metrics and indicators to measure the progress and quality of an architecture as it evolves from a high-level prototype into a fully compliant productProviding integrated life-cycle environments that support early and continuous configuration control, change management, rigorous design methods, document automation, and regression test automationUsing visual modeling and higher level language that support architectural control, abstraction, reliable programming, reuse, and self-documentationEarly and continuous insight into performance issues through demonstration-based evaluations"Software Project Management" Walker Royce25/112Part 1 The Old Way and the New

"Software Project Management" Walker Royce26/112Part 1 The Old Way and the NewThe Principles of Conventional Software EngineeringMake quality #1. Quality must be quantified and mechanism put into place to motivate its achievement.High-quality software is possible. Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people.Give products to customers early. No matter how hard you try to learn users needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it.Determine the problem before writing the requirements. When faced with what they believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and dont be blinded by the obvious solution.Evaluate design alternatives. After the requirements are agreed upon, you must examine a variety of architectures and algorithms. You certainly do not want to use an architecture simply because it was used in the requirements specification.Use an appropriate process model. Each project must select a process that makes the most sense for that project on the basis of corporate culture, willingness to take risks, application area, volatility of requirements, and the extent to which requirements are well understood.Use different languages for different phases. Our industrys eternal thirst for simple solutions to complex problems has driven many to declare that the best development method is one that uses the same notation through-out the life cycle. Why should software engineers use Ada for requirements, design, and code unless Ada were optimal for all these phases?Minimize intellectual distance. To minimize intellectual distance, the softwares structure should be as close as possible to the real-world structure.Put techniques before tools. An undisciplined software engineer with a tool becomes a dangerous, undisciplined software engineer.Get it right before you make it faster. It is far easier to make a working program run than it is to make a fast program work. Dont worry about optimization during initial coding."Software Project Management" Walker Royce27/112Part 1 The Old Way and the NewThe Principles of Conventional Software EngineeringInspect code. Inspecting the detailed design and code is a much better way to find errors than testing.Good management is more important than good technology. The best technology will not compensate for poor management, and a good manager can produce great results even with meager resources. Good management motivates people to do their best, but there are no universal right styles of management.People are the key to success. Highly skilled people with appropriate experience, talent, and training are key. The right people with insufficient tools, languages, and process will succeed. The wrong people with appropriate tools, languages, and process will probably fail.Follow with care. Just because everybody is doing something does not make it right for you. It may be right, but you must carefully assess its applicability to your environment. Object orientation, measurement, reuse, process improvement, CASE, prototyping-all these might increase quality, decrease cost, and increase user satisfaction. The potential of such techniques is often oversold, and benefits are by no means guaranteed or universal.Take responsibility. When a bridge collapses we ask, what did the engineers do wrong? Even when software fails, we rarely ask this. The fact is that in any engineering discipline, the best methods can be used to produce awful designs, and the most antiquated methods to produce elegant design.Understand the customers priorities. It is possible the customer would tolerate 90% of the functionality delivered late if they could have 10% of it on time.The more they see, the more they need. The more functionality (or performance) you provide a user, the more functionality (or performance) the user wants.Plan to throw one away .One of the most important critical success factors is whether or not a product is entirely new. Such brand-new applications, architectures, interfaces, or algorithms rarely work the first time.Design for change. The architectures, components, and specification techniques you use must accommodate change.Design without documentation is not design. I have often heard software engineers say, I have finished the design. All that is left is the documentation. "Software Project Management" Walker Royce28/11221.Use tools, but be realistic. Software tools make Part 1 The Old Way and the NewThe Principles of Conventional Software EngineeringUse tools, but be realistic. Software tools make their users more efficient.Avoid tricks. Many programmers love to create programs with tricks- constructs that perform a function correctly, but in an obscure way. Show the world how smart you are by avoiding tricky code.Encapsulate. Information-hiding is a simple, proven concept that results in software that is easier to test and much easier to maintain.Use coupling and cohesion. Coupling and cohesion are the best ways to measure softwares inherent maintainability and adaptability.Use the McCabe complexity measure. Although there are many metrics available to report the inherent complexity of software, none is as intuitive and easy to use as Tom McCabes.Dont test your own software. Software developers should never be the primary testers of their own software.Analyze causes for errors. It is far more cost-effective to reduce the effect of an error by preventing it than it is to find and fix it. One way to do this is to analyze the causes of errors as they are detected.Realize that softwares entropy increases. Any software system that undergoes continuous change will grow in complexity and become more and more disorganized.People and time are not interchangeable. Measuring a project solely by person-months makes little sense.Expert excellence. Your employees will do much better if you have high expectations for them."Software Project Management" Walker Royce29/112Part 1 The Old Way and the NewThe Principles of Modern Software ManagementThe central design element

Architecture-first approach

Design and integration first, then production and testThe risk management element

Iterative life-cycle process

Risk control through ever-increasing function, performance, qualityThe technology element

Component-based development

Object-oriented methods, rigorous notations, visual modelingThe control element

Change management environment

Metrics, trends, process instrumentationThe automation element

Round-trip engineering

Complementary tools, integrated environments"Software Project Management" Walker Royce30/112Part 2 A Software Management Process Framework

"Software Project Management" Walker Royce31/112Part 2 A Software Management Process FrameworkTable of Contents (1)Life-Cycle PhasesEngineering and Production StagesInception PhaseElaboration PhaseConstruction PhaseTransition PhaseArtifacts of the ProcessThe Artifact SetsManagement ArtifactsEngineering ArtifactsPragmatic Artifacts

"Software Project Management" Walker Royce32/112Part 2 A Software Management Process FrameworkTable of Contents (2)Model-based software ArchitecturesArchitecture: A Management PerspectiveArchitecture: A Technical PerspectiveWorkflows of the ProcessSoftware Process WorkflowsIteration WorkflowsCheckpoints of the ProcessMajor MilestonesMinor MilestonesPeriodic Status Assessments

"Software Project Management" Walker Royce33/112Part 2 Life-Cycle PhasesEngineering and Production StagesTwo stages of the life-cycle :The engineering stage driven by smaller teams doingdesign and synthesis activities

LIFE-CYCLE ASPECTENGINEERING STAGE EMPHASISPRODUCTION STAGE EMPHASISRisk reductionSchedule, technical feasibilityCostProductsArchitecture baselineProduct release baselinesActivitiesAnalysis, design, planningImplementation, testingAssessmentDemonstration, inspection, analysisTestingEconomicsResolving diseconomies of scaleExploiting economics of scaleManagementPlanningOperations2. The production stage driven by larger teams doing construction, test, and deployment activities"Software Project Management" Walker Royce34/112Part 2 Life-Cycle PhasesEngineering and Production StagesAttributing only two stages to a life cycle is too coarse

Engineering StageProduction StageInceptionElaborationConstructionTransition

IdeaArchitectureBeta ReleasesProductsSpiral model [Boehm, 1998]"Software Project Management" Walker Royce35/112Part 2 Life-Cycle PhasesInception PhaseOverriding goal to achieve concurrence among stakeholders on the life-cycle objectives

Essential activities :Formulating the scope of the project (capturing the requirements and operational concept in an information repository)Synthesizing the architecture (design trade-offs, problem space ambiguities, and available solution-space assets are evaluated)Planning and preparing a business case (alternatives for risk management, iteration planes, and cost/schedule/profitability trade-offs are evaluated)

"Software Project Management" Walker Royce36/112Part 2 Life-Cycle PhasesElaboration PhaseDuring the elaboration phase, an executable architecture prototype is built

Essential activities :Elaborating the vision (establishing a high-fidelity understanding of the critical use cases that drive architectural or planning decisions)Elaborating the process and infrastructure (establishing the construction process, the tools and process automation support)Elaborating the architecture and selecting components (lessons learned from these activities may result in redesign of the architecture)

"Software Project Management" Walker Royce37/112Part 2 Life-Cycle PhasesConstruction PhaseDuring the construction phase :All remaining components and application features are integrated into the applicationAll features are thoroughly tested

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

"Software Project Management" Walker Royce38/112Part 2 Life-Cycle PhasesTransition PhaseThe transition phase is entered when baseline is mature enough to be deployed in the end-user domainThis phase could include beta testing, conversion of operational databases, and training of users and maintainers

Essential activities :Synchronization and integration of concurrent construction into consistent deployment baselinesDeployment-specific engineering (commercial packaging and production, field personnel training)Assessment of deployment baselines against the complete vision and acceptance criteria in the requirements set"Software Project Management" Walker Royce39/112Part 2 Life-Cycle PhasesEvaluation Criteria :Is the user satisfied?Are actual resource expenditures versus planned expenditures acceptable?Each of the four phases consists of one or more iterations in which some technical capability is produced in demonstrableform and assessed against a set of the criteriaThe transition from one phase to the nest maps more to a significant business decision than to the completion of specific software activity."Software Project Management" Walker Royce40/112Part 2 Artifacts of the Process

RequirementsSet1.Vision document2.Requirements model(s)Design Set

1.Design model(s)2.Test model3.Software architecture description

ImplementationSet

1.Source code baselines2.Associated compile-time files3.Component executablesDeploymentSet

1.Integrated product executable baselines2.Associated run-time files3.User manual

Management SetPlanning Artifacts Operational Artifacts1.Work breakdown structure 5.Release descriptions2.Bussines case 6.Status assessments3.Release specifications 7.Software change order database4.Software development plan 8.Deployment documents9.Enviorement"Software Project Management" Walker Royce41/112Part 2 Artifacts of the ProcessManagement ArtifactsThe management set includes several artifacts :Work Breakdown Structure vehicle for budgeting and collecting costs.The software project manager must have insight into project costsand how they are expended.If the WBS is structured improperly, it can drive the evolving designin the wrong direction.

Business Case 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."Software Project Management" Walker Royce42/112Part 2 Artifacts of the ProcessManagement ArtifactsRelease Specifications

I. Iteration contentII. Measurable objectivesA. Evaluation criteriaB. Follow-through approachDemonstration planA. Schedule of activitiesB. Team responsibilitiesOperational scenarios (use cases demonstrated)A. Demonstration proceduresB. Traceability to vision and business caseTypical 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 realizationsor structured text representations."Software Project Management" Walker Royce43/112Part 2 Artifacts of the ProcessManagement ArtifactsSoftware Development Plan the defining document for the projects 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 documentsubsets 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 modelingdocument automationautomated regression testing "Software Project Management" Walker Royce44/112Part 2 Artifacts of the ProcessEngineering ArtifactsIn general review, there are three engineering artifacts :Vision document supports the contract between the funding authority and the development organization.It is written from the users 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 setwill be achieved."Software Project Management" Walker Royce45/112Part 2 Artifacts of the ProcessEngineering ArtifactsSoftware 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 users perspective thanthe development team.It also provides a necessary basis for test plans and test cases, and for construction of automated test suites.

Architecture overview A. ObjectivesB. ConstraintsC. FreedomsArchitecture viewsA. Design viewB. Process viewC. Component viewD. Deployment view

III. Architectural interactionsA. Operational concept under primary scenariosB. Operational concept under secondary scenariosC. Operational concept under anomalous scenarios

Architecture performance

Rationale, trade-offs, and other substantiation

Typical architecture description outline :"Software Project Management" Walker Royce46/112Part 2 Artifacts of the ProcessPragmatic ArtifactsOver the past 30 years, the quality of documents become more important than the quality of the engineering informationthey represented.The reviewer must be knowledgeable in the engineering notation.

Human-readable engineering artifacts should use rigorous notationsthat 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."Software Project Management" Walker Royce47/112Part 2 Model-Based Software Architectures A Management PerspectiveFrom a management perspective, there are three different aspects of an architecture : An architecture (the intangible design concept) is the designof software system, as opposed to design of a component.

An architecture baseline (the tangible artifacts) is a sliceof information across the engineering artifact sets sufficient tosatisfy all stakeholders that the vision can be achieved withinthe parameters of the business case (cost, profit, time, people).

An architecture description (a human-readable representationof an architecture) is an organizes subsets of information extracted from the design set model."Software Project Management" Walker Royce48/112Part 2 Model-Based Software Architectures A Management PerspectiveThe importance of software architecture can be summarizedas follows: Architecture representations provide a basis for balancing the trade-offs between the problem space and the solution space.

Poor architectures and immature processes are often given asreasons 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 intellectualsteps that map the problem to a solution without violating the constraints."Software Project Management" Walker Royce49/112Part 2 Model-Based Software Architectures A Technical Perspective

An architecture is described through several views, which are extracts of design models that capture the significant structures, collaborations, and behaviors.

Architecture DescriptionDocumentDesign viewProcess viewUse case viewComponent viewDeployment viewOther views (optional)

DesignViewProcessViewComponentViewDeploymentView

Use CaseView

The model which draws on the foundation of architecture developed at Rational Software Corporation and particularlyon Philippe Kruchtens concepts of software architecture : "Software Project Management" Walker Royce50/112Part 2 Model-Based Software Architectures A Technical PerspectiveThe use case view describes how the systems critical use cases are realizedby elements of the design model. It is modeled statically using case diagrams, and dynamically using any of the UML behavioral diagrams.

The design view addresses the basic structure and the functionality of the solution.The process view addresses the run-time collaboration issues involved inexecuting the architecture on a distributed deployment model, including the logical software network topology, interprocess communicationand state management. The component view describes the architecturally significant elements of the implementation set and addresses the software source code realizationof the system from perspective of the project's integrators and developers.

The deployment view addresses the executable realization of the system,including the allocation of logical processes in the distribution view to physical resources of the deployment network."Software Project Management" Walker Royce51/112Part 2 Workflows of the Process Software Process WorkflowsThere are seven top-level workflows:

1. Management workflow: controlling the process and ensuring win conditions for all stakeholders2. Environment workflow: automating the process and evolving the maintenance environmentRequirements workflow: analyzing the problem space and evolving the requirements artifactsDesign workflow: modeling the solution and evolving the architecture anddesign artifactsImplementation workflow: programming the components and evolvingthe implementation and deployment artifactsAssessment workflow: assessing the trends in process and product qualityDeployment workflow: transitioning the end products to the userThe term workflow is used to mean a thread of cohesive and most sequential activities."Software Project Management" Walker Royce52/112Part 2 Workflows of the Process Software Process WorkflowsArchitecture-first approach: implementing and testing the architecture must precede full-scale development and testingand must precede the downstream focus on completeness and quality of the product features.Iterative life-cycle process: the activities and artifacts of any givenworkflow may require more than one pass to achieve adequateresults.Roundtrip engineering: Raising the environment activities to a first-class workflow is critical; the environment is the tangibleembodiment of the projects process and notations for producingthe artifacts.Demonstration-based approach: Implementation and assessmentactivities are initiated nearly in the life-cycle, reflecting the emphasis on constructing executable subsets of the involving architecture.Four basic key principles:"Software Project Management" Walker Royce53/112Part 2 Workflows of the Process Iteration Workflows

Management

Requirements

Design

Implementation

Assessment

Deployment

Results for the nextiteration

Allocated usage scenarios

Results from thePrevious iteration

An iteration consist of sequential set of activities in various proportions, depending on where the iteration is located in the development cycle.An individual iterations workflow:"Software Project Management" Walker Royce54/112Part 2 Workflows of the Process Iteration Workflows

Management

Requirements

Design

Implementation

Assessment

Deployment

Management

Requirements

Design

Implementation

Assessment

Deployment

Management

Requirements

Design

Implementation

Assessment

Deployment Inception and Elaboration PhasesConstruction PhaseTransition Phase"Software Project Management" Walker Royce55/112Part 2 Checkpoints of the ProcessIt is important to have visible milestones in the life cycle , wherevarious stakeholders meet to discuss progress and planes.The purpose of this events is to:Synchronize stakeholder expectations and achieve concurrence on the requirements, the design, and the plan.Synchronize related artifacts into a consistent and balanced stateIdentify the important risks, issues, and out-of-rolerance conditionsPerform a global assessment for the whole life-cycle."Software Project Management" Walker Royce56/112Part 2 Checkpoints of the ProcessMajor milestones provide visibility to systemwide issues, synchronize the management and engineering perspectives and verify that the aims of the phase have been achieved.

Three types of joint management reviews are conducted throughout the process:3. Status assessments periodic events provide management with frequent and regular insight into the progress being made.2. Minor milestones iteration-focused events, conducted to review the content of an iteration in detailand to authorize continued work."Software Project Management" Walker Royce57/112Part 3Software Management Disciplines

"Software Project Management" Walker Royce58/112Part 3Software Management DisciplinesTable of Contents (1)Iterative Process PlanningWork Breakdown StructuresPlanning GuidelinesThe Cost and Schedule Estimating ProcessThe Iteration Planning ProcessPragmatic PlanningProject Organizations and ResponsibilitiesLine-of-Business organizationsProject OrganizationsEvolution OrganizationsProcess AutomationTools: Automation Building BlocksThe Project Environment

"Software Project Management" Walker Royce59/112Part 3 Software Management DisciplinesTable of Contents (2)Project Control and Process InstrumentationThe Seven Core MetricsManagement IndicatorsQuality IndicatorsLife-Cycle ExpectationsPragmatic Software MetricsMetrics AutomationTailoring the ProcessProcess DiscriminantsExample: Small-Scale Project Versus Large-scale Project

"Software Project Management" Walker Royce60/112Part 3Iterative Process PlanningWork Breakdown StructuresThe development of a work breakdown structure is dependent on the project management style, organizational culture, customer preference, financialconstraints and several other hard-to-define parameters.A WBS is simply a hierarchy of elements that decomposesthe project plan into the discrete work tasks.A WBS provides the following information structure:A delineation of all significant workA clear task decomposition for assignment of responsibilitiesA framework for scheduling, budgeting, and expendituretracking."Software Project Management" Walker Royce61/112Part 3Iterative Process PlanningPlanning GuidelinesTwo simple planning guidelines should be consideredwhen a project plan is being initiated or assessed.The first guideline prescribes a default allocation of costs among the first-level WBS elementsThe second guideline prescribes the allocation of effort and schedule across the life-cycle phases

FIRST-LEVELWBS ELEMENTDEFAULT BUDGETManagement10%Environment10%Requirements10%Design15%Implementation25%Assessment25%Deployment5%Total100%

DOMAININCEPTIONELABORATIONCONSTRUCTIONTRANSITIONEffort5%20%65%10%Schedule10%30%50%10%"Software Project Management" Walker Royce62/112Part 3Iterative Process PlanningThe Cost and Schedule Estimating ProcessProject plans need to be derived from two perspectives.Forward-looking:1. The software project manager develops a characterizationof the overall size, process, environment, people, and quality required for the project2. A macro-level estimate of the total effort and schedule is developed using a software cost estimation model3. The software project manager partitions the estimate for the effort into a top-level WBS, also partitions the schedule into major milestone dates and partitions the effort into a staffing profile4. At this point, subproject managers are given the responsibility for decomposing each of the WBS elements into lower levels usingtheir top-level allocation, staffing profile, and major milestone datesas constraints."Software Project Management" Walker Royce63/112Part 3Iterative Process PlanningThe Cost and Schedule Estimating ProcessBackward-looking:1. The lowest level WBS elements are elaborated into detailed tasks, for which budgets and schedules are estimated by the responsibleWBS element manager. 2. Estimates are combined and integrated into higher level budgetsand milestones. 3. Comparisons are made with the top-down budgets and schedule milestones. Gross differences are assessed and adjustments are made in order to converge on agreement between the top-down and the bottom-up estimates."Software Project Management" Walker Royce64/112Part 3Iterative Process PlanningThe Iteration Planning Process

Engineering StageProduction StageInception ElaborationConstruction Transition

Engineering stage planning emphasis:Macro-level task estimation for production-stage artifactsMicro-level task estimation for engineering artifactsStakeholder concurrenceCoarse-grained variance analysis of actual vs. planned expendituresTuning the top-down project-independent planning guidelines into project-specific planning guidelines.Production stage planning emphasis:Micro-level task estimation for production-stage artifactsMacro-level task estimation for engineering artifactsStakeholder concurrenceFine-grained variance analysis of actual vs. planned expenditures

Feasibility iterations

Architecture iterations

Usable iterations

Product releases"Software Project Management" Walker Royce65/112Part 3Project Organizations and ResponsibilitiesLine-of-Business OrganizationsDefault roles in a software line-of-business organizations

Project A Manager

Project B Manager

Project N Manager

Organization Manager

Software Engineering Process Authority

Software Engineering Environment Authority

Project Review Authority

Infrastructure

Process definitionProcess improvementProcess automationProject compliancePeriodic risk assessmentProject administrationEngineering skill centersProfessional development"Software Project Management" Walker Royce66/112Part 3Project Organizations and ResponsibilitiesProject OrganizationsSoftware Management TeamArtifactsBusiness caseVisionSoftware development planWork breakdown structureStatus assessmentsRequirements setSystems EngineeringFinancial AdministrationQuality AssuranceResponsibilitiesResource commitmentsPersonnel assignmentsPlans, priorities,Stakeholder satisfactionScope definitionRisk managementProject control

InceptionElaborationConstructionTransitionElaboration phase planningTeam formulatingContract base liningArchitecture costsConstruction phase planningFull staff recruitmentRisk resolutionProduct acceptance criteriaConstruction costsTransition phase planningConstruction plan optimizationRisk managementCustomer satisfactionContract closureSales supportNext-generation planningLife-Cycle Focus"Software Project Management" Walker Royce67/112Part 3Project Organizations and ResponsibilitiesProject OrganizationsSoftware Architecture TeamArtifactsArchitecture descriptionRequirements setDesign setRelease specificationsDemonstrationsUse-case modelersDesign modelersPerformance analystsResponsibilitiesRequirements trade-offsDesign trade-offsComponent selectionInitial integrationTechnical risk solution

InceptionElaborationConstructionTransitionArchitecture prototypingMake/buy trade-offsPrimary scenario definitionArchitecture evaluation criteria definitionArchitecture base liningPrimary scenario demonstrationMake/buy trade-offs base liningArchitecture maintenanceMultiple-component issue resolutionPerformance tuningQuality improvements

Architecture maintenanceMultiple-component issue resolutionPerformance tuningQuality improvementsLife-Cycle Focus"Software Project Management" Walker Royce68/112Part 3Project Organizations and ResponsibilitiesProject OrganizationsSoftware Development TeamArtifactsDesign setImplementation setDeployment setComponent teamsResponsibilitiesComponent designComponent implementationComponent stand-alone testComponent maintenanceComponent documentation

InceptionElaborationConstructionTransitionPrototyping supportMake/buy trade-offsCritical component designCritical component implementation and testCritical component base lineComponent designComponent implementation Component stand-alone testComponent maintenance

Component maintenanceComponent documentation

Life-Cycle Focus"Software Project Management" Walker Royce69/112Part 3Project Organizations and ResponsibilitiesProject OrganizationsSoftware Assessment TeamArtifactsDeployment setSCO databaseUser manualEnvironmentRelease specificationsRelease descriptionsDeployment documentsRelease testingChange managementDeploymentEnvironment supportResponsibilitiesProject infrastructureIndependent testingRequirements verificationMetrics analysisConfiguration controlChange managementUser deployment

InceptionElaborationConstructionTransitionInfrastructure planningPrimary scenario prototypingInfrastructure base liningArchitecture release testing Change managementInitial user manualInfrastructure upgradesRelease testingChange managementUser manual base lineRequirements verificationInfrastructure maintenanceRelease base liningChange managementDeployment to usersRequirements verificationLife-Cycle Focus"Software Project Management" Walker Royce70/112Part 3Project Organizations and ResponsibilitiesEvolution of Organizations

Software management50%

Software assessment10%

Software development20%

Software architecture20%

Software management10%

Software assessment20%

Software development20%

Software architecture50%

Software management10%

Software assessment50%

Software development35%

Software architecture5%

Software management10%

Software assessment30%

Software development50%

Software architecture10%

Inception

Elaboration

Transition

Construction

"Software Project Management" Walker Royce71/112Part 3Process AutomationComputer-aided software engineeringComputer-aided software engineering (CASE) is software to support software development and evolution processes.Activity automationGraphical editors for system model development;Data dictionary to manage design entities;Graphical UI builder for user interface construction;Debuggers to support program fault finding;Automated translators to generate new versions of a program."Software Project Management" Walker Royce72/112Part 3Process AutomationComputer-aided software engineering (CASE) TechnologyCase technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predictedSoftware engineering requires creative thought - this is not readily automated;Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these."Software Project Management" Walker Royce73/112Part 3Process AutomationCASE ClassificationClassification helps us understand the different types of CASE tools and their support for process activities.Functional perspectiveTools are classified according to their specific function.Process perspectiveTools are classified according to process activities that are supported.Integration perspectiveTools are classified according to their organisation into integrated units. "Software Project Management" Walker Royce74/112Part 3Process AutomationFunctional Tool Classification

"Software Project Management" Walker Royce75/112Part 3Process AutomationCASE IntegrationToolsSupport individual process tasks such as design consistency checking, text editing, etc.WorkbenchesSupport a process phase such as specification or design, Normally include a number of integrated tools.EnvironmentsSupport all or a substantial part of an entire software process. Normally include several integrated workbenches."Software Project Management" Walker Royce76/112Part 3Process AutomationTools, Workbenches, Environments

"Software Project Management" Walker Royce77/112Part 3Project Control and Process InstrumentationThe Core Metrics

METRICPURPOSEPERSPECTIVESWork and progressIteration planning, plan vs. actuals, management indicatorSLOC, function points, object points, scenarios, test cases, SCOsBudget cost and expendituresFinancial insight, plan vs. actuals, management indicatorCost per month, full-time staff per month, percentage of budget expendedStaffing and team dynamicsResource plan vs. actuals, hiring rate, attrition ratePeople per month added, people per month leavingChange traffic and stabilityIteration planning, management indicator of schedule convergenceSoftware changesBreakage and modularityConvergence, software scrap, quality indicatorReworked SLOC per change, by type, by release/component/subsystemRework and adoptabilityConvergence, software rework, quality indicator

Average hours per change, by type, by release/component/subsystem

"Software Project Management" Walker Royce78/112Part 3Tailoring the ProcessProcess DiscriminantsThe two primary dimensions of process variability

Higher technical complexityEmbedded, real-time, distributed, fault-tolerantHigh-performance, portableUnprecedented, architecture re-engineering

Lower technical complexityStraightforward automation, single threadInteractive performance, single platformMany precedent systems, application re-engineering

Higher management complexityLarge scaleContractualMany stakeholdersProjects

Lower management complexitySmaller scaleInformalFew stakeholdersProducts

Average software project5 to 10 people10 to 12 months3 to 5 external interfacesSome unknowns, risks"Software Project Management" Walker Royce79/112Part 3Tailoring the ProcessExample: Small-Scale Project vs. Large-Scale ProjectDifferences in workflow priorities between small and large projects

RankSmall Commercial ProjectLarge Complex Project1DesignManagement2ImplementationDesign3DeploymentRequirements4RequirementsAssessment5AssessmentsEnvironment6ManagementImplementation7EnvironmentDeployment"Software Project Management" Walker Royce80/112Part 4 Looking Forward

"Software Project Management" Walker Royce81/112Part 4 Looking ForwardTable of ContentsModern Project ProfilesContinuous IntegrationEarly Risk ResolutionEvolutionary RequirementsTeamwork Among StakeholdersTop 10 Software Management PrinciplesSoftware Management Best PracticesNext-Generation Software EconomicsNext-Generation Cost ModelsModern Software EconomicsModern Process TransitionsCulture ShiftsDenouement"Software Project Management" Walker Royce82/112Part 4 Modern Project ProfilesContinuous IntegrationDifferences in workflow cost allocations between a conventional process and a modern process

SOFTWAREENGINEERINGWORKFLOWSCONVENTIONALPROCESSEXPENDITURESMODERNPROCESSEXPENDITURESManagement5%10%Environment5%10%Requirements5%10%Design10%15%Implementation30%25%Assessment40%25%Deployment5%5%Total100%100%"Software Project Management" Walker Royce83/112Part 4 Modern Project ProfilesContinuous IntegrationThe continuous integration inherent in an iterative development process enables better insight into quality trade-offs.System characteristics that are largely inherent in the architecture (performance, fault tolerance, maintainability) are tangible earlier in the process, when issues are still correctable."Software Project Management" Walker Royce84/112Part 4 Modern Project ProfilesEarly Risk ResolutionConventional projects usually do the easy stuff first,modern process attacks the important 20% of the requirements, use cases, components, and risks.The effect of the overall life-cycle philosophy on the 80/20 lessons provides a useful risk managementperspective.80% of the software cost is consumed by 20% of the components.80% of the engineering is consumed by 20% of the requirements.80% of the errors are caused by 20% of the components.80% of the progress is made by 20% of the people."Software Project Management" Walker Royce85/112Part 4 Modern Project ProfilesEvolutionary RequirementsConventional approaches decomposed system requirementsinto subsystem requirements, subsystem requirements intocomponent requirements, and component requirements intounit requirements.The organization of requirements was structured so traceability was simple.Most modern architectures that use commercial components,legacy components, distributed resources and object-oriented methods are not trivially traced to the requirements they satisfy.The artifacts are now intended to evolve along with the process,with more and more fidelity as the life-cycle progresses andthe requirements understanding matures."Software Project Management" Walker Royce86/112Part 4 Modern Project ProfilesTeamwork among stakeholdersMany aspects of the classic development process cause stakeholder relationships to degenerate into mutual distrust,making it difficult to balance requirements, product features,and plans.The process with more-effective working relationships between stakeholders requires that customers, users and monitors have bothapplications and software expertise, remain focused on the deliveryof a usable systemIt also requires a development organization that is focused on achieving customer satisfaction and high product quality in a profitable manner.

The transition from the exchange of mostly paper artifacts to demonstration of intermediate results is one of the crucial mechanisms for promoting teamwork among stakeholders."Software Project Management" Walker Royce87/112Part 4 Modern Project ProfilesTop 10 Software Management Principles1. Base the process on an architecture-first approach rework rates remain stable over the project life cycle.2. Establish an iterative life-cycle process that confronts risk early3. Transition design methods to emphasize component-based development4. Establish a change management environment the dynamicsof iterative development, including concurrent workflows by different teams working on shared artifacts, necessitate highly controlled baselines5. Enhance change freedom through tools that support round-trip engineering"Software Project Management" Walker Royce88/112Part 4 Modern Project ProfilesTop 10 Software Management Principles6. Capture design artifacts in rigorous, model-based notation7. Instrument the process for objective quality control and progress assessment8. Use a demonstration-based approach to asses intermediate artifacts9. Plan intermediate releases in groups of usage scenarios with evolving levels of detail10. Establish a configurable process that is economicallyscalable"Software Project Management" Walker Royce89/112Part 4 Modern Project ProfilesSoftware Management Best PracticesThere is nine best practices:1. Formal risk management2. Agreement on interfaces3. Formal inspections4. Metric-based scheduling and management5. Binary quality gates at the inch-pebble level6. Program-wide visibility of progress versus plan.7. Defect tracking against quality targets8. Configuration management9. People-aware management accountability"Software Project Management" Walker Royce90/112Part 4 Next-Generation Software EconomicsNext-Generation Cost ModelsSoftware experts hold widely varying opinions about software economics and its manifestation in software cost estimation models:source lines of codefunction points

productivity measuresobject-orientedquality measuresJavaC++functionally oriented

VERSUS

It will be difficult to improve empirical estimation models while the project data going into these models are noisyand highly uncorrelated, and are based on differing process and technology foundations."Software Project Management" Walker Royce91/112Part 4 Next-Generation Software EconomicsNext-Generation Cost ModelsSome of todays popular software cost models are not well matchedto an iterative software process focused an architecture-first approachMany cost estimators are still using a conventional process experiencebase to estimate a modern project profileA next-generation software cost model should explicitly separatearchitectural engineering from application production, just as an architecture-first process does.Two major improvements in next-generation software cost estimation models:Separation of the engineering stage from the production stagewill force estimators to differentiate between architectural scale and implementation size.Rigorous design notations such as UML will offer an opportunityto define units of measure for scale that are more standardized andtherefore can be automated and tracked."Software Project Management" Walker Royce92/112Part 4 Next-Generation Software EconomicsModern Software EconomicsChanges that provide a good description of what an organizational manager should strive for in making the transition to a modern process:1. Finding and fixing a software problem after delivery costs 100 times more than fixing the problem in early design phases2. You can compress software development schedules 25% of nominal, but no more.3. For every $1 you spend on development, you will spend $2 on maintenance.4. Software development and maintenance costs are primarily a function of the number of source lines of code."Software Project Management" Walker Royce93/112Part 4 Next-Generation Software EconomicsModern Software Economics6. The overall ratio of software to hardware costs is still growing in 1955 it was 15:85; in 1985 85:15.7. Only about 15% of software development effort is devoted to programming.8. Software systems and products typically cost 3 times as much per SLOC as individual software programs.9. Walkthroughs catch 60% of the errors.10. 80% of the contribution comes from 20% of the contributors.5. Variations among people account for the biggest differences in software productivity."Software Project Management" Walker Royce94/112Part 4 Modern Process TransitionsCulture ShiftsLower level and mid-level managers are performersSeveral culture shifts must be overcome to transition successfully to a modern software management process:Requirements and designs are fluid and tangibleGood and bad project performance is much more obvious earlierin the life cycleArtifacts are less important early, more important laterReal issues are surfaced and resolved systematicallyQuality assurance is everyones job, not a separate disciplinePerformance issues arise early in the life cycleInvestments in automation is necessaryGood software organization should be more profitable"Software Project Management" Walker Royce95/112Part 4 Modern Process TransitionsDenouementGood way to transition to a more mature iterative development process that supports automation technologiesand modern architectures is to take the following shot:Ready. Do your homework. Analyze modern approaches and technologies. Define your process. Support it with mature environments, tools, and components. Plan thoroughly.Execute the organizational and project-level plans with vigor and follow-through.Select a critical project. Staff it with the right team of complementary resources and demand improved results.Aim. Fire. "Software Project Management" Walker Royce96/112Appendix

"Software Project Management" Walker Royce97/112AppendixUse Case AnalysisWhat is a Use Case?A sequence of actions a system performs that yields a valuable result for a particular actor.What is an Actor?A user or outside system that interacts with the system being designed in order to obtain some value from that interactionUse Cases describe scenarios that describe the interaction between users of the system and the system itself.Use Cases describe WHAT the system will do, but never HOW it will be done."Software Project Management" Walker Royce98/112Appendix Whats in a Use Case?Define the start state and any preconditions that accompany itDefine when the Use Case startsDefine the order of activity in the Main Flow of EventsDefine any Alternative Flows of EventsDefine any Exceptional Flows of EventsDefine any Post Conditions and the end stateMention any design issues as an appendixAccompanying diagrams: State, Activity, Sequence DiagramsView of Participating Objects (relevant Analysis Model Classes)Logical View: A View of the Actors involved with this Use Case, and any Use Cases used or extended by this Use Case"Software Project Management" Walker Royce99/112Use Cases describe WHAT the system will do, but never HOW it will be done.Use Cases are Analysis Products, not Design Products.

Appendix Use Cases Describe Function not Form"Software Project Management" Walker Royce100/112Appendix Use Cases Describe Function not FormUse Cases describe WHAT the system should do, but never HOW it will be doneUse cases are Analysis products, not design products"Software Project Management" Walker Royce101/112Appendix Benefits of Use CasesUse cases are the primary vehicle for requirements capture in RUPUse cases are described using the language of the customer (language of the domain which is defined in the glossary)Use cases provide a contractual delivery process (RUP is Use Case Driven)Use cases provide an easily-understood communication mechanismWhen requirements are traced, they make it difficult for requirements to fall through the cracksUse cases provide a concise summary of what the system should do at an abstract (low modification cost) level."Software Project Management" Walker Royce102/112Appendix Difficulties with Use CasesAs functional decompositions, it is often difficult to make the transition from functional description to object description to class designReuse at the class level can be hindered by each developer taking a Use Case and running with it. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficultUse Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?)Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious"Software Project Management" Walker Royce103/112Appendix Use Case Model SurveyThe Use Case Model Survey is to illustrate, in graphical form, the universe of Use Cases that the system is contracted to deliver.Each Use Case in the system appears in the Survey with a short description of its main function.Participants:Domain ExpertArchitectAnalyst/Designer (Use Case author)Testing Engineer

"Software Project Management" Walker Royce104/112Appendix Sample Use Case Model Survey

"Software Project Management" Walker Royce105/112Appendix Analysis ModelIn Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the detailsAgain, the Analysis Model is still focusing on WHAT were going to do, not HOW were going to do it (Design Model). But what were going to do is drawn from the point of view of the developer, not from the point of view of the customerWhereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer:Boundary ClassesEntity ClassesControl Classes"Software Project Management" Walker Royce106/112Appendix Why spend time on the Analysis Model, why not just face the cliff?By performing analysis, designers can inexpensively come to a better understanding of the requirements of the systemBy providing such an abstract overview, newcomers can understand the overall architecture of the system efficiently, from a birds eye view, without having to get bogged down with implementation details.The Analysis Model is a simple abstraction of what the system is going to do from the point of view of the developers. By speaking the developers language, comprehension is improved and by abstracting, simplicity is achievedNevertheless, the cost of maintaining the AM through construction is weighed against the value of having it all along."Software Project Management" Walker Royce107/112Appendix Boundary ClassesBoundary classes are used in the Analysis Model to model interactions between the system and its actors (users or external systems)Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.)Boundary classes can often be abstractions of external APIs (in the case of an external system actor)Every boundary class must be associated with at least one actor:

"Software Project Management" Walker Royce108/112Appendix Entity ClassesEntity classes are used within the Analysis Model to model persistent informationOften, entity classes are created from objects within the business object model or domain model

"Software Project Management" Walker Royce109/112Appendix Control ClassesThe Great Et CeteraControl classes model abstractions that coordinate, sequence, transact, and otherwise control other objectsIn Smalltalk MVC mechanism, these are controllersControl classes are often encapsulated interactions between other objects, as they handle and coordinate actions and control flows.

"Software Project Management" Walker Royce110/112LiteratureSoftware Project ManagementA Unified Framework Walker Royce Software ProcessesIan Sommerville 2004Process and Method:An Introduction to the Rational Unified Process