CS 501: Software Engineering Fall 1999

CS 501: Software EngineeringFall 1999 Lecture 22 (a) Managing the Software Process (b) Software Reuse

Administration  Assignment 5 due date changed  No recitation next week

Cost Estimation See Sommerville, Chapter 29 Categories of cost:  Hardware and software  Professional staff (salaries and benefits)  Miscellaneous (e.g., travel and training)  Indirect (e.g., space, support staff, technical infrastructure, marketing and management)  Profit

Cost Estimation The challenges in cost estimation are:  How long will it take?  How many people will be required? These are reflected in the costs for:  Professional staff  Indirect costs

Pricing For in-house development, costs and pricing are directly related by some formula. Example: Federally funded university research For commercial development, price charged may differ from costs:  Market penetration (new fields, foot in door)  Contingency to cover uncertainty  Ownership of software product  Financial health

Productivity Productivity =(units of output) (resources input) But what is the unit of output?  Size related measures lines of code (what is a line?)  Function related measures e.g., UML nodes and arcs

Team Productivity  Staff ability and expertise  Domain expertise  Process quality  Project size  Technology support  Working environment Microsoft is the world's greatest software company, but Windows 2000 is two years behind schedule.

Cost Estimation Techniques The following techniques have been suggested. See Sommerville for details  Algorithmic cost modeling  Expert judgment  Estimation by analog  Parkinson's Law / pricing to win All these methods work reasonably in familiar domains. None work well in strange domains.

Algorithmic Cost Estimation Factors to take into account:  Complexity  Computer attributes (e.g., embedded, networked)  Product metric (size or functionality)  Personnel attributes (e.g., experience, ability)

Quality Management "Total Quality Management": A management fad of the early 1990s. Buzz words, consultants, books, training programs, awards, standards. But some good concepts:  Customer satisfaction, not internal measures  Staff development and participation in management (e.g., US Navy)  Continuous improvement of processes  Measurements and comparison with other industries

Quality in Software Emphasis has been on:  process standards e.g., documentation standards  software process metrics Very valuable within organizations. Little success across organizations.

Software with Monitoring Software can measure aspects of its use and performance:  Networking and distributed computing Example: SNMP  Monitoring user interfaces Which features are never used?  Logging and data mining

Process Improvement Processes: project management, scheduling, communications, documentation, testing, reporting, recruiting, training, etc.  Understand the existing processes and practices actual practice may differ from official  Decide the appropriate level of processes big project => more process inexperienced team => more process  Improve and consolidate one step at a time acceptance => leadership

Software Engineering Institute Process Maturity Model Categorization of contractors for DoD software: 1. Initial -- no effective management processes 2. Repeatable -- requirements management, project planning, scheduling and tracking, quality assurance, configuration control 3. Defined -- conformity to defined processes, design and code reviews, communication procedures, personnel development 4. Managed -- software quality management, quantitative process management 5. Optimizing -- continuous improvement of processes

Software Processes How important are processes to the development of good software?

Software Processes and Good Software  Processes do not guarantee good software ... but they help  Larger projects need more formality of management  There is no consensus about preferred processes  The keys to success are: high-quality professional staff good leadership realistic goals communication with client

Software Reuse Potential benefits of reuse:Better software at lower cost  Reduce development time and cost  Improved reliability of mature components  Shared maintenance cost Potential disadvantages of reuse:  Difficulty in finding appropriate components  Components may be a poor fit for application

Software Reuse Examples Software developers rely heavily on software components provided by others System software  device drivers  file systems  exception handling  task management  network protocols Database management systems

Software Reuse Examples (Tools) Standard functions  mathematical methods  formatting User interface toolkits (e.g., Macintosh)  Graphics tools (Quickdraw)  Dialogs  WIMP -- windows, icons, menus, mouse tracking

Software Reuse (Application Packages)  Package supports a standard application (e.g., payroll, user interface to Internet information)  Functionality can be enhanced by: => configuration parameters (e.g., table driven) => extensibility at defined interfaces => custom written sources code extensions

Extensibility in Web Browsers  Data types: helper applications, plug-ins  Protocols HTTP, WAIS, Gopher, FTP, etc. proxies  Executable code CGI scripts at server JavaScript at client Java applets  Style sheets

Reuse and Object Object Oriented Languages Example: Java is a relatively straightforward language with a very rich set of class hierarchies.  Java programs derive much of their functionality from standard classes  Learning and understanding the classes is difficult.  Java experts can write complex systems quickly  Inexperienced Java programmers write inelegant and buggy programs

Reading Before next class, read Sommerville Chapters 17, pages 319 to 346

CS 501: Software Engineering Fall 1999