This preview shows page 1. Sign up to view the full content.
Unformatted text preview: Chapter 3 Improving Software Economics
Part 1 of 2 23 1 Balanced Attack Can improve software economics Easy to do so and have poor results Key is a `balanced' approach; patient Five Key Initiatives In Order: Reducing the size and/or complexity of application Improving the development process itself Using moreskilled personnel and creation of better teams Creating better `environments' with appropriate tools and technology to foster improvement Relooking at Quality
23 2 This lecture We will concentrate on Reducing the Size (most slides), and a little on Looking at the Process. 23 3 Cost Model Parameters
Size Abstraction and component-based development technologies Trends
Higher Order Languages (C++, Java, VB, OO (analysis, design, programming) Reuse Commercial Components Iterative Development Process Maturity Models Architecture-first development Acquisition reform Process Methods and techniques Personnel People factors Training and personnel skill development Teamwork Win-win cultures Integrated tools (visual modeling, compiler, editors, debuggers, CMS, .... Open Systems Hardware platform performance Automation of coding, documents, testing, analyses Environment Automation technologies and tools Quality Performance, reliability, accuracy Hardware platform performance Demonstration-based assessment Statistical quality control 23 4 Comments on Overall Approaches Significant interdependencies are apparent! Examples: Some tools (environment) can bring about a reduction in size and process improvement (process). UI and GUIs today (tools environment) GUI Builders, affect process and quality... Improved process (usecase driven...) => end user functionality drives the process thus favorably impacting quality.... A `host' of other interdependencies... 23 5 1. Reducing Software Product Size The larger the product, the more expensive it is `per line.' Fact. Complicated due to Componentbased development Automatic code generation "Instruction Explosion" GUI builders 4GLs Modeling Languages Executable code size often increases!
23 6 1. Reducing Software Product Size: A. Languages Function Point metrics: SLOC metrics: Language independent! External user inputs, outputs, internal logical data groups, external data interfaces, and external inquiries. useful after a candidate solution is formulated and implementation language is known. Many comparisons of function points to lines of code.
23 7 Comparison Table
Assembler Language C Fortran 77 Cobol 85 Ada 83 C++ Ada 95 Java Visual Basic SLOC PER UFP
320 128 105 91 71 56 55 55
23 35 8 More on Comparisons: Languages Use table as a general comparison guide only. Languages (in general) are often best suited for `classes of problems' (domain of usage) Webbased apps: Java vs COBOL Transaction processing: Java vs COBOL Systems programming: Assembler vs C vs Java Prototyping UI: VB versus Java (varies...) Shows `level of expressiveness.' Read through comparisons... pros and cons: C to C++ Java 23 9 More on Comparisons: Languages Function Points focus more on `functionality.' The implementing programming language size can be inferred from function point count. Not simple to compute function points tho... Automatic code generators (CASE; GUI) can reduce size of `human generated' code less time; fewer team members...(helps cost; efficiency of automatic code generators? Function point computation?) Commercial DBMSs, GUI Builders, middleware, ... reduce the amount of code to be developed... Size may be larger! How are fpoints computed here??? Others!!
23 10 Level of abstraction and functionality benefits and `expressiveness' Reducing size changes `level of abstraction' allowing us to focus on architecture, ... easier to understand, reuse, maintain. (may import packages of classes and objects...) We can talk about layers, dependencies, interfaces, services! Can talk about classes, subsystems, packages. These are serious abstractions! But, these higherlevel abstractions are often high users of storage, and communications bandwidth... 23 11 A package is a general purpose mechanism for organizing elements into groups (use cases; classes, other model elements...) Package is a model element which can contain other model elements
Packages may contain many model elements: use case models, classes, objects, subsystems, components, other packages. Package Expressiveness Package Name General grouping for organizational purposes May have tremendous `expressiveness' Think Math class in Java...
23 12 A combination of a package Subsystem - Expressiveness groups similar model elements and a class has behaviors via its methods. (classes provide / encapsulate behaviors or services) Subsystems Realize one or more interfaces which define its behaviors
<<subsystem>> Subsystem Name nterface Interface (a class)
23 Generally has classes associated that provide the holistic service of the subsystem...
13 Subsystem Subsystems and Components Components are the physical realization of an abstraction in the design physical realization can exist on many levels consider the realization of a presentaton layer modeled as a `component.' Components (in the implementation model) can be used to represent the subsystems from the design model.
<<subsystem>> Component Name Implementation Model
14 Component Interface 23 Component Interface 1. Reducing Software Product Size: B. OO Methods and Visual Modeling Assertions abound re benefits of OO methods on productivity and quality Not terribly locked in concrete yet High costs of OO training using OOSE, modeling languages like UML and comprehensive, configurable processes like the RUP and many technologies... OO technology reduces size (among other things), but there is no free lunch. 23 15 B. OO Methods and Visual Modeling Size is not everything... OO technology approaches so many other benefits: Encourage a common vocabulary Support continuous integration Glossary; domain model; artifacts ; object `concepts' and terms Easy to talk about subsystems, classes, interfaces... Architecture first approach for stability, planning teams, iteration plans, ... Architecture provides a clear separation of concerns for development in parallel; configuration; integrity of development... And then, when you consider the RUP as a process built around OO technology, there are a host of additional benefits.... 23 16 1. Reducing Software Product Size: C. Reuse Always had `reuse' with stored functions/subpgms Many forms of reuse: Differences in platforms / environments has hurt reuse potential Old stuff: data descriptions; documents, and a host of similar, old artifacts, designs, architectures... from all phases of software development Common architectures; processes, common environments... Very common during monolithic type development. Common Microsoft platforms: counter example Linux; MACs, resulting from distributing applications!
23 17 C. Reuse (continued) Main reason for Reuse or `lack' thereof: money. (not addressing commercial components...) Costs to build reusable and configure reusable components. Must be able to justify. Can reuse be justified across many projects? Some commercial organizations focused on selling commercial components. Very few success stories for software component reuse Most developers do undertake some kind of reuse just perhaps not as formalized...
23 18 exceptions: operation systems, middleware, GUI Builders, other obvious ones. 1. Reducing Software Product Size: D. Commercial Components Major trend buy commercial components. Saves custom development Usually needs tailoring Certainly pros and cons. Bottom line: may well have global impacts on: quality cost supportability, and the architecture. 23 19 Advantages and Disadvantages of Commercial Components versus Custom Software
APPROACH Commercial Components ADVANTAGES Predictable license costs Broadly used, mature technology Available now Dedicated support organizations Hardware/software independence Rich in functionality DISADVANTAGES Frequent upgrades Up-front license fees Recurring maintenance fees Dependency on vendor Run-time efficiency sacrifices Functionality constraints Integration not always trivial No control over upgrades or maintenance Unnecessary features that consume extra resources Often inadequate reliability and stability Multiple vendor incompatibilities Custom Development Complete change freedom Smaller, often simpler implementations Often better performance 23 Expensive, unpredictable development Unpredictable availability date Underdefined maintenance model 20 2. Improving Software Processes Development projects are complex undertakings Some activities done in parallel; others sequential. Some activities: overhead; some production. Objective: minimize overhead and direct these energies toward production activities.
23 Production activities the project itself requirements elicitation and modeling, analysis, design, implementation... Overhead activities planning, progress monitoring, risk assessment, financial assessments, configuration control, quality assessment, integration, testing, late rework, management, personnel training, etc.... 21 2. Improving Software Processes (cont.) It is all about process! A highquality process reduces: Required effort and thus schedule Project time yet with improved quality. Three generic improvement scenarios: Improve efficiency of each step in process Eliminate some steps in the process Undertake the same number of steps, but 23
22 2. Improving Software Processes continued First approach We want the highest quality system with fewest iterations in least time. more efficient steps older approach is good, more ROI on second (fewer steps) and third (concurrency in activities) Must eliminate rework and late scrap fixing things up! Integration testing is culprit. Fixing things up as a result of integration and system tests are killers!!! Our Process must reduce the probability of late rework! Does the RUP facilitate this? If so, How? 23 23 ...
View Full Document
This document was uploaded on 07/29/2011.
- Spring '09