Chapter 1 - The Product

Overview

• Software is designed and built by software engineers. • Software is used by virtually everyone in society. • Software engineers have a moral obligation to build reliable software that does no harm to

other people. • Software engineers view computer software, as being made up of the programs, documents,

and data required to design and build the system. • Software users are only concerned with whether or not software products meet their

expectations and make their tasks easier to complete.

Software characteristics

• Software is both a product and a vehicle for developing a product. • Software is engineered not manufactured. • Software does not wear out, but it does deteriorate. • Currently, most software is still custom-built.

Software Application Types

• System software • Real-time software • Business software • Engineering and scientific software • Embedded software • Personal computer software • Web-based software • Artificial intelligence software

Software Crisis

• Software failures receive a lot more publicity than software engineering success stories. • The software crisis predicted thirty years ago has never materialized and software engineering

successes outnumber the failures. • The problems that afflict software development are associated more with how to develop and

support software properly, than with simply building software that functions correctly.

Software Myths

• Software standards provide software engineers with all the guidance they need. The reality is the standards may be outdated and rarely referred to.

• People with modern computers have all the software development tools. The reality is that CASE tools are more important than hardware to producing high quality software, yet they are rarely used effectively.

• Adding people is a good way to catch up when a project is behind schedule. The reality is that adding people only helps the project schedule when is it done in a planned, well-coordinated manner.

• Giving software projects to outside parties to develop solves software project management problems. The reality is people who can?t manage internal software development problems will struggle to manage or control the external development of software too.

• A general statement of objectives from the customer is all that is needed to begin a software project. The reality is without constant communication between the customer and the developers it is impossible to build a software product that meets the customer's real needs.

• Project requirements change continually and change is easy to accommodate in the software design. The reality is that every change has far-reaching and unexpected consequences. Changes to software requirements must be managed very carefully to keep a software project on time and under budget.

• Once a program is written, the software engineer's work is finished. The reality is that maintaining a piece of software is never done, until the software product is retired from service.

• There is no way to assess the quality of a piece of software until it is actually running on some machine. The reality is that one of the most effective quality assurance practices (formal technical reviews) can be applied to any software design product and can serve as a quality filter very early in the product life cycle.

• The only deliverable from a successful software project is the working program. The reality is the working program is only one of several deliverables that arise from a well-managed software project. The documentation is also important since it provides a basis for software support after delivery.

• Software engineering is all about the creation of large and unnecessary documentation. The reality is that software engineering is concerned with creating quality. This means doing things right the first time and not having to create deliverables needed to complete or maintain a software product. This practice usually leads to faster delivery times and shorter development cycles.

Chapter 2 - The Process

Overview

• The roadmap to building high quality software products is software process. • Software processes are adapted to meet the needs of software engineers and managers as they

undertake the development of a software product. • A software process provides a framework for managing activities that can very easily get out of

control. • Different projects require different software processes. • The software engineer's work products (programs, documentation, data) are produced as

consequences of the activities defined by the software process. • The best indicators of how well a software process has worked are the quality, timeliness, and

long-term viability of the resulting software product.

Software Engineering

• Software engineering encompasses a process, management techniques, technical methods, and the use of tools.

Generic Software Engineering Phases

• Definition phase - focuses on what (information engineering, software project planning, and requirements analysis).

• Development phase - focuses on how (software design, code generation, software testing). • Support phase - focuses on change (corrective maintenance, adaptive maintenance, perfective

maintenance, preventative maintenance).

Software Engineering Umbrella Activities

• Software project tracking and control • Formal technical reviews • Software quality assurance • Software configuration management • Document preparation and production • Reusability management • Measurement • Risk management

Common Process Framework

• Software engineering work tasks • Project milestones • Work products • Quality assurance points

Software Engineering Institute (SEI) Capability Maturity Model (CMM)

• Level 1: Initial (ad hoc software processes) • Level 2: Repeatable (able to repeat earlier successes) • Level 3: Defined (management and engineering processes documented, standardized, and

integrated into organization-wide software process) • Level 4; Managed (software process and products are quantitatively understood and controlled

using detailed measures) • Level 5: Optimizing (continuous process improvement is enabled by quantitative feedback

from the process and testing innovative ideas)

Software Process Models

• Linear Sequential Model (old fashioned but reasonable approach when requirements are well understood)

• Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product)

• Rapid Application and Development (RAD) Model (makes heavy use of reusable software components with an extremely short development cycle)

• Incremental Model (delivers software in small but usable pieces, each piece builds on pieces already delivered)

• Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model)

• Win-Win Spiral Model (eliciting software requirements defined through negotiation between customer and developer, where each party attempts to balance technical and business constraints)

• Concurrent Development Model (similar to spiral model often used in development of client/server applications)

• Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes)

• Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computer-based systems)

• Fourth Generation (4GT) Techniques (software tool is used to generate the source code for a software system from a high level specification representation)

Chapter 3 - Project Management Concepts

Overview

• Project management involves the planning, monitoring, and control of people, process, and events that occur during software development.

• Everyone manages, but the scope of each person's management activities varies according his or her role in the project.

• Software needs to be managed because it is a complex undertaking with a long duration time. • Managers must focus on the fours P's to be successful (people, product, process, and project). • A project plan is a document that defines the four P's in such a way as to ensure a cost

effective, high quality software product. • The only way to be sure that a project plan worked correctly is by observing that a high quality

product was delivered on time and under budget.

Management Spectrum

• People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development)

• Product (product objectives, scope, alternative solutions, constraint tradeoffs) • Process (framework activities populated with tasks, milestones, work products, and QA points) • Project (planning, monitoring, controlling)

People

• Players (senior managers, technical managers, practitioners, customers, end-users) • Team leadership model (motivation, organization, skills) • Characteristics of effective project managers (problem solving, managerial identity,

achievement, influence and team building)

Software Team Organization

• Democratic decentralized (rotating task coordinators and group consensus) • Controlled decentralized (permanent leader, group problem solving, subgroup implementation

of solutions) • Controlled centralized (top level problem solving and internal coordination managed by team

leader)

Factors Affecting Team Organization

• Difficulty of problem to be solved • Size of resulting program • Team lifetime • Degree to which problem can be modularized • Required quality and reliability of the system to be built • Rigidity of the delivery date • Degree of communication required for the project

Coordination and Communication Issues

• Formal, impersonal approaches (e.g. documents, milestones, memos) • Formal interpersonal approaches (e.g. review meetings, inspections) • Informal interpersonal approaches (e.g. information meetings, problem solving) • Electronic communication (e.g. e-mail, bulletin boards, video conferencing) • Interpersonal network (e.g. informal discussion with people other than project team members)

The Product

• Software scope (context, information objectives, function, performance) • Problem decomposition (partitioning or problem elaboration - focus is on functionality to be

delivered and the process used to deliver it)

The Process

• Process model chosen must be appropriate for the: customers and developers, characteristics of the product, and project development environment

• Project planning begins with melding the product and the process • Each function to be engineered must pass though the set of framework activities defined for a

software organization • Work tasks may vary but the common process framework (CPF) is invariant (project size does

not change the CPF) • The job of the software engineer is to estimate the resources required to move each function

though the framework activities to produce each work product • Project decomposition begins when the project manager tries to determine how to accomplish

each CPF activity

The Project

• Start on the right foot • Maintain momentum • Track progress • Make smart decisions • Conduct a postmortem analysis

W5HH Principle

• Why is the system being developed? • What will be done by When? • Who is responsible for a function? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource is needed?

Critical Practices

• Formal risk management • Empirical cost and schedule estimation • Metric-based project management • Earned value tracking • Defect tracking against quality targets • People-aware program management

Chapter 4 - Software Process and Project Metrics

Overview

• Software process and project metrics are quantitative measures that enable software engineers to gain insight into the efficiency of the software process and the projects conducted using the process framework. In software project management, we are primarily concerned with productivity and quality metrics. The four reasons for measuring software processes, products, and resources (to characterize, to evaluate, to predict, and to improve).

Measures, Metrics, and Indicators

• Measure - provides a quantitative indication of the size of some product or process attribute • Measurement - is the act of obtaining a measure • Metric - is a quantitative measure of the degree to which a system, component, or process

possesses a given attribute

Process and Project Indicators

• Metrics should be collected so that process and product indicators can be ascertained • Process indicators enable software project managers to: assess project status, track potential

risks, detect problem area early, adjust workflow or tasks, and evaluate team ability to control product quality

Process Metrics

• Private process metrics (e.g. defect rates by individual or module) are known only to the individual or team concerned.

• Public process metrics enable organizations to make strategic changes to improve the software process.

• Metrics should not be used to evaluate the performance of individuals. • Statistical software process improvement helps and organization to discover where they are

strong and where are week.

Project Metrics

• Software project metrics are used by the software team to adapt project workflow and technical activities.

• Project metrics are used to avoid development schedule delays, to mitigate potential risks, and to assess product quality on an on-going basis.

• Every project should measure its inputs (resources), outputs (deliverables), and results (effectiveness of deliverables).

Software Measurement

• Direct measures of software engineering process include cost and effort. • Direct measures of the product include lines of code (LOC), execution speed, memory size,

defects per reporting time period. • Indirect measures examine the quality of the software product itself (e.g. functionality,

complexity, efficiency, reliability, maintainability).

Size-Oriented Metrics

• Derived by normalizing (dividing) any direct measure (e.g. defects or human effort) associated with the product or project by LOC.

• Size oriented metrics are widely used but their validity and applicability is widely debated.

Function-Oriented Metrics

• Function points are computed from direct measures of the information domain of a business software application and assessment of its complexity.

• Once computed function points are used like LOC to normalize measures for software productivity, quality, and other attributes.

• Feature points and 3D function points provide a means of extending the function point concept to allow its use with real-time and other engineering applications.

• The relationship of LOC and function points depends on the language used to implement the software.

Software Quality Metrics

• Factors assessing software quality come from three distinct points of view (product operation, product revision, product modification).

• Software quality factors requiring measures include correctness (defects per KLOC), maintainability (mean time to change), integrity (threat and security), and usability (easy to learn, easy to use, productivity increase, user attitude).

• Defect removal efficiency (DRE) is a measure of the filtering ability of the quality assurance and control activities as they are applied through out the process framework.

Integrating Metrics with Software Process

• Many software developers do not collect measures. • Without measurement it is impossible to determine whether a process is improving or not. • Baseline metrics data should be collected from a large, representative sampling of past

software projects. • Getting this historic project data is very difficult, if the previous developers did not collect data

in an on-going manner.

Statistical Process Control

• It is important to determine whether the metrics collected are statistically valid and not the result of noise in the data.

• Control charts provide a means for determining whether changes in the metrics data are meaningful or not.

• Zone rules identify conditions that indicate out of control processes (expressed as distance from mean in standard deviation units).

Metrics for Small Organizations

• Most software organizations have fewer than 20 software engineers. • Best advice is to choose simple metrics that provide value to the organization and don?t require

a lot of effort to collect. • Even small groups can expect a significant return on the investment required to collect metrics,

if this activity leads to process improvement.

Establishing a Software Metrics Program

• Identify business goal • Identify what you want to know • Identify subgoals • Identify subgoal entities and attributes • Formalize measurement goals • Identify quantifiable questions and indicators related to subgoals • Identify data elements needed to be collected to construct the indicators • Define measures to be used and create operational definitions for them • Identify actions needed to implement the measures • Prepare a plan to implement the measures

Chapter 5 - Software Project Planning

Overview

• Software planning involves estimating how much time, effort, money, and resources will be required to build a specific software system. After the project scope is determined and the problem is decomposed into smaller problems, software managers use historical project data (as well as personal experience and intuition) to determine estimates for each. The final estimates are typically adjusted by taking project complexity and risk into account. The resulting work product is called a project management plan.

Estimation Reliability Factors

• Project complexity • Project size • Degree of structural uncertainty (degree to which requirements have solidified, the ease with

which functions can be compartmentalized, and the hierarchical nature of the information processed)

• Availability of historical information

Project Planning Objectives

• To provide a framework that enables software manager to make a reasonable estimate of resources, cost, and schedule.

• Project outcomes should be bounded by 'best case' and 'worst case' scenarios. • Estimates should be updated as the project progresses.

Software Scope

• Describes the data to be processed and produced, control parameters, function, performance, constraints, external interfaces, and reliability.

• Often functions described in the software scope statement are refined to allow for better estimates of cost and schedule.

Customer Communication and Scope

• Determine the customer's overall goals for the proposed system and any expected benefits. • Determine the customer's perceptions concerning the nature if a good solution to the problem. • Evaluate the effectiveness of the customer meeting.

Feasibility

• Technical feasibility is not a good enough reason to build a product. • The product must meet the customer's needs and not be available as an off-the-shelf purchase.

Estimation of Resources

• Human Resources (number of people required and skills needed to complete the development project)

• Reusable Software Resources (off-the-shelf components, full-experience components, partial-experience components, new components)

• Development Environment (hardware and software required to be accessible by software team during the development process)

Software Project Estimation Options

• Delay estimation until late in the project. • Base estimates on similar projects already completed. • Use simple decomposition techniques to estimate project cost and effort. • Use empirical models for software cost and effort estimation. • Automated tools may assist with project decomposition and estimation.

Decomposition Techniques

• Software sizing (fuzzy logic, function point, standard component, change) • Problem-based estimation (using LOC decomposition focuses on software functions, using FP

decomposition focuses on information domain characteristics) • Process-based estimation (decomposition based on tasks required to complete the software

process framework)

Empirical Estimation Models

• Typically derived from regression analysis of historical software project data with estimated person-months as the dependent variable and KLOC or FP as independent variables.

• Constructive Cost Model (COCOMO) is an example of a static estimation model. • The Software Equation is an example of a dynamic estimation model.

Make-Buy Decision

• It may be more cost effective to acquire a piece of software rather than develop it. • Decision tree analysis provides a systematic way to sort through the make-buy decision. • As a rule outsourcing software development requires more skillful management than does in-

house development of the same product.

Automated Estimation Tool Capabilities

• Sizing of project deliverables • Selecting project activities • Predicting staffing levels • Predicting software effort • Predicting software cost • Predicting software schedule

Chapter 6 - Risk Analysis and Management

Overview

• Risks are potential problems that might affect the successful completion of a software project. Risks involve uncertainty and potential losses. Risk analysis and management are intended to help a software team understand and manage uncertainty during the development process. The important thing is to remember that things can go wrong and to make plans to minimize their impact when they do. The work product is called a Risk Mitigation, Monitoring, and Management Plan (RMMM).

Risk Strategies

• Reactive strategies - very common, also known as fire fighting, project team sets resources aside to deal with problems and does nothing until a risk becomes a problem

• Proactive strategies - risk management begins long before technical work starts, risks are identified and prioritized by importance, then team builds a plan to avoid risks if they can or minimize them if the risks turn into problems

Software Risks

• Project risks - threaten the project plan • Technical risks - threaten product quality and the timeliness of the schedule • Business risks - threaten the viability of the software to be built (market risks, strategic risks,

management risks, budget risks) • Known risks - predictable from careful evaluation of current project plan and those

extrapolated from past project experience • Unknown risks - some problems simply occur without warning

Risk Identification

• Product-specific risks - the project plan and software statement of scope are examined to identify any special characteristics of the product that may threaten the project plan

• Generic risks - are potential threats to every software product (product size, business impact, customer characteristics, process definition, development environment, technology to be built, staff size and experience)

Risk Impact

• Risk components - performance, cost, support, schedule • Risk impact - negligible, marginal, critical, catastrophic • The risk drivers affecting each risk component are classified according to their impact category

and the potential consequences of each undetected software fault or unachieved project outcome are described

Risk Projection (Estimation)

• Establish a scale that reflects the perceived likelihood of each risk • Delineate the consequences of the risk • Estimate the impact of the risk on the project and product • Note the overall accuracy of the risk projection to avoid misunderstandings

Risk Table Construction

• List all risks in the first column of the table • Classify each risk and enter the category label in column two • Determine a probability for each risk and enter it into column three • Enter the severity of each risk (negligible, marginal, critical, catastrophic) in column four • Sort the table by probability and impact value • Determine the criteria for deciding where the sorted table will be divided into the first priority

concerns and the second priority concerns • First priority concerns must be managed (a fifth column can be added to contain a pointer into

the RMMM)

Assessing Risk Impact

• Factors affecting risk consequences - nature (types of problems arising), scope (combines severity with extent of project affected), timing (when and how long impact is felt)

• If costs are associated with each risk table entry Halstead's risk exposure metric can be computed (RE = Probability * Cost) and added to the risk table.

Risk Assessment

• Define referent levels for each project risk that can cause project termination (performance degradation, cost overrun, support difficulty, schedule slippage).

• Attempt to develop a relationship between each risk triple (risk, probability, impact) and each of the reference levels.

• Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.

• Try to predict how combinations of risks will affect a referent level.

Risk Refinement

• Process of restating the risks as a set of more detailed risks that will be easier to mitigate, monitor, and manage.

• CTC (condition-transition-consequence) format may be a good representation for the detailed risks (e.g. given that <condition> then there is a concern that (possibly) <consequence>).

Risk Mitigation, Monitoring, and Management

• Risk mitigation (proactive planing for risk avoidance) • Risk monitoring (assessing whether predicted risks occur or not, ensuring risk aversion steps

are being properly applied, collect information for future risk analysis, attempt to determine which risks caused which problems)

• Risk management and contingency planing (actions to be taken in the event that mitigation steps have failed and the risk has become a live problem)

Safety Risks and Hazards

• Risks are also associated with software failures that occur in the field after the development project has ended.

• Computers control many mission critical applications in modern times (weapons systems, flight control, industrial processes, etc.).

• Software safety and hazard analysis are quality assurance activities that are of particular concern for these types of applications and are discussed later in the text.

Risk Information Sheets

• Alternative to RMMM in which each risk is documented individually. • Often risk information sheets (RIS) are maintained using a database system. • RIS components - risk id, date, probability, impact, description, refinement,

mitigation/monitoring, management/contingency/trigger, status, originator, assigned staff member.

Chapter 7 - Project Scheduling and Tracking

Overview

• The chapter describes the process of building and monitoring schedules for software development projects. To build complex software systems, many engineering tasks need to occur in parallel with one another to complete the project on time. The output from one task often determines when another may begin. It is difficult to ensure that a team is working on the most appropriate tasks without building a detailed schedule and sticking to it.

Software Project Scheduling Principles

• Compartmentalization - the product and process must be decomposed into a manageable number of activities and tasks

• Interdependency - tasks that can be completed in parallel must be separated from those that must completed serially

• Time allocation - every task has start and completion dates that take the task interdependencies into account

• Effort validation - project manager must ensure that on any given day there are enough staff members assigned to completed the tasks within the time estimated in the project plan

• Defined Responsibilities - every scheduled task needs to be assigned to a specific team member

• Defined outcomes - every task in the schedule needs to have a defined outcome (usually a work product or deliverable)

• Defined milestones - a milestone is accomplished when one or more work products from an engineering task have passed quality review

Relationship Between People and Effort

• Adding people to a project after it is behind schedule often causes the schedule to slip further • The relationship between the number of people on a project and overall productivity is not

linear (e.g. 3 people do not produce 3 times the work of 1 person, if the people have to work in cooperation with one another)

• The main reasons for using more than 1 person on a project are to get the job done more rapidly and to improve software quality.

Project Effort Distribution

Generally accepted guidelines are:

• 02-03 % planning • 10-25 % requirements analysis • 20-25 % design • 15-20 % coding • 30-40 % testing and debugging

Software Project Types

• Concept development - initiated to explore new business concept or new application of technology

• New application development - new product requested by customer • Application enhancement - major modifications to function, performance, or interfaces

(observable to user) • Application maintenance - correcting, adapting, or extending existing software (not

immediately obvious to user) • Reengineering - rebuilding all (or part) of a legacy system

Software Process Degree of Rigor

• Casual - all framework activities applied, only minimum task set required (umbrella activities minimized and documentation reduced)

• Structured - all framework and umbrella activities applied (SQA, SCM, documentation, and measurement tasks are streamlined)

• Strict - full process and umbrella activities applied (high quality products and robust documentation produced)

• Quick reaction - emergency situation, process framework used, but only tasks essential to good quality are applied (back filling used to develop documentation and conduct additional reviews after product is delivered)

Rigor Adaptation Criteria

• Size of project • Number of potential users • Mission criticality • Application longevity • Requirement stability • Ease of customer/developer communication • Maturity of applicable technology • Performance constraints • Embedded/non-embedded characteristics • Project staffing • Reengineering factors

Task Set Selector Value

• Computed by scoring rigor adaptation criteria and adjusting the scores using differential weighting based on project characteristics.

• Once computed the task selector value can be used to select the appropriate task set (casual, structured, strict) for the project.

• It is OK to choose a less formal degree of rigor when the task selector value falls in the overlap area between two levels of rigor, unless project risk is high.

Concept Development Tasks

• Concept scoping - determine overall project scope • Preliminary concept planning - establishes development team's ability to undertake the

proposed work • Technology risk assessment - evaluates the risk associated with the technology implied by the

software scope • Proof of concept - demonstrates the feasibility of the technology in the software context • Concept implementation - concept represented in a form that can be used to sell it to the

customer • Customer reaction to concept - solicits feedback on new technology from customer

Scheduling

• Scheduling tools should be used to schedule any non-trivial project. • PERT (program evaluation and review technique) and CPM (critical path method) are

quantitative techniques that allow software planners to identify the chain of dependent tasks in the project work breakdown structure that determine the project duration time.

• Timeline (Gantt) charts enable software planners to determine what tasks will be need to be conducted at a given point in time (based on estimates for effort, start time, and duration for each task).

• The best indicator of progress is the completion and successful review of a defined software work product.

• Time-boxing is the practice of deciding a priori the fixed amount of time that can be spent on each task. When the task's time limit is exceeded, development moves on to the next task (with the hope that a majority of the critical work was completed before time ran out).

Earned Value Analysis

• Earned value is a quantitative measure of percent of project completed so far. • The total hours to complete the entire project are estimated and each task is given an earned

value based on its estimated percentage contribution to the total.

Error Tracking

• Allows comparison of current work to past projects and provides a quantitative indication of the quality of the work being conducted.

• The more quantitative the approach to project tracking and control, the more likely problems can be anticipated and dealt with in a proactive manner.

Chapter 8 - Software Quality Assurance

Overview

• This chapter provides an introduction for software quality assurance (SQA). SQA is the concern of every software engineer to reduce cost and improve product time-to-market. A Software Quality Assurance Plan is not merely another name for a test plan, though test plans are included in an SQA plan. SQA activities are performed on every software project. Use of metrics is an important part of developing a strategy to improve the quality of both software processes and work products.

Quality Concepts

• Variation control is the heart of quality control (software engineers strive to control the process applied, resources expended, and end product quality attributes).

• Quality of design - refers to characteristics designers specify for the end product to be constructed

• Quality of conformance - degree to which design specifications are followed in manufacturing the product

• Quality control - series of inspections, reviews, and tests used to ensure conformance of a work product to its specifications

• Quality assurance - consists of the auditing and reporting procedures used to provide management with data needed to make proactive decisions

Cost of Quality

• Prevention costs - quality planning, formal technical reviews, test equipment, training • Appraisal costs - in-process and inter-process inspection, equipment calibration and

maintenance, testing • Failure costs - rework, repair, failure mode analysis • External failure costs - complaint resolution, product return and replacement, help line support,

warranty work

Total Quality Management

• Kaizen - develop a process that is visible, repeatable, and mesaurable • Atarimae hinshitsu - examine the intangibles that affect the process and work to optimize their

impact on the process • Kansei - examine the way the product is used by the customer with an eye to improving both

the product and the development process • Miryokuteki hinshitsu - observe product use in the market place to uncover new product

applications and identify new products to develop

Software Quality Assurance

• Conformance to software requirements is the foundation from which software quality is measured.

• Specified standards are used to define the development criteria that are used to guide the manner in which software is engineered.

• Software must conform to implicit requirements (ease of use, maintainability, reliability, etc.) as well as its explicit requirements.

SQA Group Activities

• Prepare SQA plan for the project. • Participate in the development of the project's software process description. • Review software engineering activities to verify compliance with the defined software process. • Audit designated software work products to verify compliance with those defined as part of the

software process. • Ensure that any deviations in software or work products are documented and handled

according to a documented procedure. • Record any evidence of noncompliance and reports them to management.

Software Reviews

• Purpose is to find defects (errors) before they are passed on to another software engineering activity or released to the customer.

• Software engineers (and others) conduct formal technical reviews (FTR) for software engineers.

• Using formal technical reviews (walkthroughs or inspections) is an effective means for improving software quality.

Formal Technical Reviews

• Involves 3 to 5 people (including reviewers) • Advance preparation (no more than 2 hours per person) required • Duration of review meeting should be less than 2 hours • Focus of review is on a discrete work product • Review leader organizes the review meeting at the producer's request • Reviewers ask questions that enable the producer to discover his or her own error (the product

is under review not the producer) • Producer of the work product walks the reviewers through the product • Recorder writes down any significant issues raised during the review • Reviewers decide to accept or reject the work product and whether to require additional

reviews of product or not

Statistical Quality Assurance

• Information about software defects is collected and categorized • Each defect is traced back to its cause • Using the Pareto principle (80% of the defects can be traced to 20% of the causes) isolate the

"vital few" defect causes • Move to correct the problems that caused the defects

Software Reliability

• Defined as the probability of failure free operation of a computer program in a specified environment for a specified time period

• Can be measured directly and estimated using historical and developmental data (unlike many other software quality factors)

• Software reliability problems can usually be traced back to errors in design or implementation.

Software Safety

• Defined as a software quality assurance activity that focuses on identifying potential hazards that may cause a software system to fail.

• Early identification of software hazards allows developers to specify design features to can eliminate or at least control the impact of potential hazards.

• Software reliability involves determining the likelihood that a failure will occur, while software safety examines the ways in which failures may result in conditions that can lead to a mishap.

Mistake-Proofing Software

• Poka-yoke devices are mechanisms that lead to the prevention of a potential quality problem before it occurs or to the rapid detection of a quality problem if one is introduced

• Poka-yoke devices are simple, cheap, part of the engineering process, and are located near the process task where the mistakes occur

ISO Quality Standards

• Quality assurance systems are defined as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.

• ISO 9000 describes the quality elements that must be present for a quality assurance system to be compliant with the standard, but it does not describe how an organization should implement these elements.

• ISO 9001 is the quality standard that contains 20 requirements that must be present in an effective software quality assurance system.

SQA Plan

• Management section - describes the place of SQA in the structure of the organization • Documentation section - describes each work product produced as part of the software process • Standards, practices, and conventions section - lists all applicable standards/practices applied

during the software process and any metrics to be collected as part of the software engineering work

• Reviews and audits section - provides an overview of the approach used in the reviews and audits to be conducted during the project

• Test section - references the test plan and procedure document and defines test record keeping requirements

• Problem reporting and corrective action section - defines procedures for reporting, tracking, and resolving errors or defects, identifies organizational responsibilities for these activities

• Other - tools, SQA methods, change control, record keeping, training, and risk management

Chapter 20 Object-Oriented Concepts and Pricinples

Overview

This chapter provides an introduction to object-oriented programming and management principles for object-oriented projects. Object-oriented software engineering process is similar to that found in the rapid prototyping or spiral paradigms. Even though, object-oriented software engineering follows the same steps as the conventional approach (analysis, design, implementation, and testing) it is harder to separate them into discrete activities. The next 3 chapters deal with the topics of object-oriented analysis, object-oriented design, and object-oriented testing.

Evolutionary Object-Oriented Process Model

• Customer communication • Planning • Risk analysis • Engineering construction and analysis

• Identify candidate classes • Look-up classes in library • Extract classes if available • Engineer classes if not available

o Object-oriented analysis (OOA) o Object-oriented design (OOD) o Object-oriented programming (OOP) o Object-oriented testing (OOT)

• Put new classes in library • Construct Nth iteration of the system

• Customer evaluation

Object-Oriented Concepts

• Objects - encapsulates both data (attributes) and data manipulation functions (called methods, operations, and services)

• Class - generalized description (template or pattern) that describes a collection of similar objects

• Superclass - a collection of objects • Subclass - an instance of a class • Class hierarchy - attributes and methods of a superclass are inherited by its subclasses • Messages - the means by which objects exchange information with one another • Inheritance - provides a means for allowing subclasses to reuse existing superclass data and

procedures; also provides mechanism for propagating changes • Polymorphism - a mechanism that allows several objects in an class hierarchy to have different

methods with the same name (instances of each subclass will be free to respond to messages by calling their own version of the method)

Advantages of Object-Oriented Architectures

• Implementation details of data and procedures and hidden from the outside world (reduces the propagation of side effects when changes are made).

• Data structures and operators are merged in single entity or class (this facilitates reuse) • Interfaces among encapsulated objects are simplified (system coupling is reduced since object

needs not be concerned about the details of internal data structures)

Class Construction Options

• Build new class from scratch without using inheritance • Use inheritance to create new class from existing class contains most of the desired attributes

and operations • Restructure the class hierarchy so that the required attributes and operations can be inherited by

the newly created class • Override some attributes or operations in an existing class and use inheritance to create a new

class with (specialized) private versions of these attributes and operations.

Chapter 21 Object-Oriented Analysis

Overview

This chapter describes the process of creating an object-oriented analysis (OOA) model for software development projects. The OOA model is composed of graphical or text-based representations that define class attributes, relationships, behaviors, and inter-class communication. OOA begins with scenario-based descriptions (use cases) of how actors (people, machines, systems) in the problem space interact with the product to be built. Class-Responsibility-Collaborator modeling translates use-case information into representations of classes and their collaborations. An object-relationship model can be built from the collaborator network. The object-behavior model is represented using a state transition diagram. The OOA model needs to be reviewed for quality like any other software engineering product.

OOA Tasks

1. Basic user requirements must be communicated between the customer and the software engineer.

2. Classes must be identified (e.g. define attributes and methods) 3. Specify class hierarchy 4. Represent object-to-object relationships 5. Model object behavior 6. Reapply 1 through 5 iteratively until model is complete

OOA Generic Steps

• Elicit customer requirements for system • Identify scenarios or use cases • Select classes and objects using basic requirements as a guide • Identify attributes and operations for each system object • Define structures and hierarchies that organize classes • Build object-relationship model • Build object-behavior model • Review OOA model against use-cases (scenarios)

Unified Modeling Language Perspectives

• User model view (describes usage scenarios from the end-user's perspective) • Structural model view (static structure of data and functionality is modeled - classes, object,

relationships) • Behavioral model view (represents dynamic system aspects - interactions or collaborations

between structural elements in the user and structural models) • Implementation model view (representing the structural and behavioral aspects of the system

as they are to be built) • Environment model view (representation of the structural and behavioral aspects of the

environment in which the system will be implemented)

Domain Analysis Activities

• Define the domain to be investigated • Categorize the items extracted from the domain • Collect a representative sample of applications in the domain • Analyze each application in the sample

• Identify candidate reusable objects • Indicate reasons the objects may be reused • Define adaptations of the objects that may be reused • Estimate percentage of applications in the domain that might make reuse of the objects • Identify objects by name and use configuration management techniques to control them

• Develop an analysis model for the objects

OOA Model Generic Components

• Static view of semantic classes (classes based on semantics of customer requirements) • Static view of attributes (attributes describe classes and suggest operations relevant to classes) • Static view of relationships (represent relationships in a way that allows identification of

operations and the design of a messaging approach) • Static view of behaviors (behaviors accommodating system usage scenarios implemented by

sequences of operations) • Dynamic view of communication (among objects based on events that cause state transitions) • Dynamic view of control and time (describe the nature and timing of events causing state

transitions)

Use Case Objectives

• Define the functional and operational requirements of system by defining a scenario of usage agreed upon by the end-user and software engineer

• Provide an unambiguous description of how the end-user and system interact with one another • Provide a basis for validation testing

Class-Responsibility-Collaborator (CRC) Modeling

• Develop a set of index cards that represent the system classes • One class per card • Cards are divide into three sections (class name, class responsibilities, class collaborators) • Once a complete CRC card set is developed it is reviewed examining the usage scenarios

Criteria for Inclusion of a Class on a CRC Card

• Class information should be retained • Provides needed services • Contains multiple attributes • Common set of attributes apply to all object occurrences • Common set of operations apply to all object occurrences • External entities that produce or consume information

Allocating Responsibilities to Classes

• Distribute system intelligence evenly • State each responsibility as generally as possible • Information and its related behaviors should reside within the same class • Localize all information about one thing in a single class • Share responsibilities among related classes when appropriate

Collaborators

• Any time a class cannot fulfill a responsibility on its own it needs to interact with another class • A server object interacts with a client object to fulfill some responsibility

Reviewing CRC Models

• Each review participant is given a subset of the CRC cards (collaborating cards must be separated)

• All use-case scenarios and use-case diagrams should be organized into categories • Review leader chooses a use-case scenario and begins reading it out loud • Each time a named object is read a token is passed to the reviewer holding the object's card • When the reviewer receives the token, he or she is asked to describe the responsibilities listed

on the card • The group determines whether one of the responsibilities on the card satisfy the use-case

requirement or not • If the responsibilities and collaborations on the index card cannot accommodate the use-case

requirements then modifications need to be made to the card set

Deriving the Object-Relationship Model

• Using the CRC model a network of collaborators can be drawn • Reviewing the CRC model index card, responsibilities and collaborators are evaluated, each

unlabeled connected line is named • Once the named relationships are established each end is evaluated to determine cardinality (0

to 1, 1 to 1, 0 to many, 1 to many) • Continue the process until a complete object-relationship model has been produced

Object-Behavior Model Construction

• Evaluate all use-cases to understand the sequence of interaction within the system • Identify events that drive the interaction sequence and how events relate to specific objects • Create an event-trace for each use-case • Build a state transition diagram for the system • Review the object behavior model to verify accuracy and consistency

Chapter 22 Object-Oriented Design

Overview

This chapter discusses the steps required to develop an object-oriented software design from an object-oriented analysis model. Object-oriented design (OOD) is divided into two major activities: system design and object design. System design defines the product architecture (the system functions and classes encapsulated in the subsystems). System design focuses on the specification of three components: the user interface, data management functions, and task management facilities. Object design focuses on the internal details of the individual classes and the messaging scheme. The design specification document form the SEPA web site is applicable to OOD. The OOD projects must be reviewed to ensure quality.

Object-Oriented Design Layers

• Responsibilities layer (highest layer - contains data structure detail and algorithmic detail for each object's attributes and operations)

• Message layer (establishes the internal and external interfaces for the system, including the details of communication among object collaborators)

• Class and object layer (contains class hierarchy including representations of each object) • Subsystem layer (lowest level - contains representations of each of the subsystems and the

necessary infrastructure that enable the software to achieve the customer's requirements)

Object-oriented Design Issues

• Decomposability - facility of design method that allows the designer to decompose the problem into easily solved subproblems

• Composability - degree to which design method ensures that modules constructed for one project can be reused in another

• Understandablity - ease with which a component can be understood without examining other components

• Continuity - ability to isolate changes made in one module and restrict the propagation of changes to other modules

• Protection - architectural characteristic that reduces the propagation of side effects when errors occur

Generic Object-Oriented Design Steps

• Describe each subsystem and allocate it to processors and tasks • Choose a design strategy for implementing data management, interface support, and task

management • Design an appropriate system control mechanism • Perform object design by creating a procedural representation for each operation and data

structures for each attribute • Perform message design using collaborations between objects and object-relationships • Create a messaging model • Review the design model and iterate as required

Unified Approach to Object-Oriented Design

• System design - UML (unified modeling language) design activity that focuses on software architecture and definition of subsystems

• Object design - UML design activity that focuses on describing object and their interactions at a level of detail that will allow them to be implemented in some programming language

Object-Oriented System Design Process

• Partition the analysis model into subsystems

• subsystems should have well defined communication interfaces • with few exceptions classes should collaborate within their subsystem • keep number of subsystems small • partition subsystem internally to reduce complexity

• Identify concurrency dictated by the problem • Allocate subsystems to processors and tasks

• allocate each subsystem to an independent processor (or) • allocate subsystems to same processor and provide concurrency support through operating

system features

• Develop user interface design • Choose basic strategy for implementing data management

• management of data critical to the application itself • creation of infrastructure for storage and retrieval of objects

• Identify global resources and control mechanisms to access them • Design control mechanism for system (including task management) • Consider how subsystem boundary conditions should be handled

• list each request (contract) that can be made by subsystem collaborators • for each contract note the operations required to implement the responsibilities implied by the

contract • for each contract create a table with these entries: type, collaborators, class, operation, message

format • if subsystem interaction modes are complex create a subsystem-collaboration diagram

• Review and consider trade-offs

Object Design Process

• Object descriptions

• protocol description - object interface specified by defining each message an object can receive and the operation triggered by message (or)

• implementation description - shows implementation details for each operation implied a message passed to the object

• Designing algorithms and data structures

• algorithm categories: data manipulation, computation, monitors • refinement of operation programs defined during OOA

• Design optimization

• review object-relationship model to ensure implemented design leads to efficient resource utilization, add redundancy where necessary

• revise attribute data structures and related operation algorithms to improve processing efficiency

• create attributes to save derived information and avoid recomputation

• Modularity is important aspect of object-oriented design quality (the program design language should support object definition)

Design Pattern Specification Components

• Name • Intent • Design forces motivating the pattern • Solution that mitigates these design forces • Classes required to implement the solution • Responsibilities and collaborations among the solution classes • Implementation suggestions • Source code examples or templates • Cross-references to related design patterns

Using Design Patterns in Object-Oriented Design

• Inheritance - makes use of an existing design pattern to create a template for a new subclass • Composition - assembling complex objects or subsystems out of selected design patterns using

only interface information

Chapter 23 Object-Oriented Testing

Overview

This chapter discusses the testing of object-oriented systems. The process of testing object-oriented systems begins with a review of the object-oriented analysis and design models. Once the code is written object-oriented testing (OOT) begins by testing "in the small" with class testing (class operations and collaborations). As classes are integrated to become subsystems class collaboration problems are investigated. Finally, use-cases from the OOA model are used to uncover software validation errors. OOT similar to testing conventional software in that test cases are developed to exercise the classes, their collaborations, and behavior. OOT differs from conventional software testing in that more emphasis is placed assessing the completeness and consistency of the OOA and OOD models as they are built. OOT tends to focus more on integration problems than on unit testing. The test plan specification template from the SEPA web site is applicable to object-oriented testing as well.

Object-Oriented Testing Activities

• Review OOA and OOD models • Class testing after code is written • Integration testing within subsystems • Integration testing as subsystems are added to the system • Validation testing based on OOA use-cases

Testing OOA and OOD Models

• Correctness of OOA and OOD models

• syntactic correctness judged by ensuring that proper modeling conventions and symbolism have been used

• semantic correctness based on the model's conformance to the real world problem domain

• Consistency of OOA and OOD models

• assess the class-responsibility-collaborator (CRC) model and object-relationship diagram • review system design (examine the object-behavior model to check mapping of system

behavior to subsystems, review concurrency and task allocation, use use-case scenarios to exercise user interface design)

• test object model against the object relationship network to ensure that all design object contain necessary attributes and operations needed to implement the collaborations defined for each CRC card

• review detailed specifications of algorithms used to implement operations using conventional inspection techniques

Assessing the Class Model

1. Revisit the CRC model and the object-relationship model 2. Inspect the description of each CRC card to determine if a delegated responsibility is part of

the collaborator's definition 3. Invert the connection to ensure that each collaborator that is asked for service is receiving

requests from a responsible source 4. Using the inverted connections from step 3, determine whether other classes might be required

or whether responsibilities are properly grouped among classes 5. Determine whether widely requested responsibilities might be combined into a single

responsibility 6. Steps 1 to 5 are applied iteratively to each class and through the evaluation of the OOA model

Object-Oriented Testing Strategies

• Unit testing in the OO context

• smallest testable unit is the encapsulated class or object • similar to system testing of conventional software • do not test operations in isolation from one another • driven by class operations and state behavior, not algorithmic detail and data flow across

module interface

• Integration testing in the OO context

• focuses on groups of classes that collaborate or communicate in some manner • integration of operations one at a time into classes is often meaningless • thread-based testing (testing all classes required to respond to one system input or event) • use-based testing (begins by testing independent classes first and the dependent classes that

make use of them) • cluster testing (groups of collaborating classes are tested for interaction errors) • regression testing is important as each thread, cluster, or subsystem is added to the system

• Validation testing in the OO context • focuses on visible user actions and user recognizable outputs from the system • validation tests are based on the use-case scenarios, the object-behavior model, and the event

flow diagram created in the OOA model • conventional black-box testing methods can be used to drive the validation tests

Test Case Design for OO Software

• Each test case should be uniquely identified and be explicitly associated with a class to be tested

• State the purpose of each test • List the testing steps for each test including:

• list of states to test for each object involved in the test • list of messages and operations to exercised as a consequence of the test • list of exceptions that may occur as the object is tested • list of external conditions needed to be changed for the test • supplementary information required to understand or implement the test

OO Test Design Issues

• White-box testing methods can be applied to testing the code used to implement class operations, but not much else

• Black-box testing methods are appropriate for testing OO systems • Fault-based testing

• best reserved for operations and the class level • uses the inheritance structure • tester examines the OOA model and hypothesizes a set of plausible defects that may be

encountered in operation calls and message connections and builds appropriate test cases • misses incorrect specification and errors in subsystem interactions

• Object-oriented programming brings additional testing concerns

• classes may contain operations that are inherited from super classes • subclasses may contain operations that were redefined rather than inherited • all classes derived from an previously tested base class need to be thoroughly tested

• Scenario-based testing

• using the user tasks described in the use-cases and building the test cases from the tasks and their variants

• uncovers errors that occur when any actor interacts with the OO software • concentrates on what the use does, not what the product does • you can get a higher return on your effort by spending more time on reviewing the use-cases as

they are created, than spending more time on use-case testing

• Testing surface structure (exercising the structure observable by end-user, this often involves observing and interviewing users as they manipulate system objects)

• Testing deep structure (exercising internal program structure - the dependencies, behaviors, and communications mechanisms established as part of the system and object design)

Class Level Testing Methods

• Random testing (requires large numbers data permutations and combinations and can be inefficient)

• Partition testing (reduces the number of test cases required to test a class)

• state-based partitioning (tests designed in way so that operations that cause state changes are tested separately from those that do not)

• attribute-based partitioning (for each class attribute, operations are classified according to those that use the attribute, those that modify the attribute, and those that do not use or modify the attribute)

• category-based partitioning (operations are categorized according to the function they perform: initialization, computation, query, termination)

Inter-Class Test Case Design

• Multiple class testing

• for each client class use the list of class operators to generate random test sequences that send messages to other server classes

• for each message generated determine the collaborator class and the corresponding server object operator

• for each server class operator (invoked by a client object message) determine the message it transmits

• for each message, determine the next level of operators that are invoked and incorporate them into the test sequence

• Tests derived from behavior models

• test cases must cover all states in the state transition diagram • breadth first traversal of the state model can be used (test one transition at a time and only

make use of previously tested transitions when testing a new transition) • test cases can also be derived to ensure that all behaviors for the class have been adequately

exercised

Chapter 25 - Formal Methods

Overview

This chapter discusses the role of formal methods in software engineering. Formal methods allow software engineers to create specifications using mathematical notation that is more complete, more consistent, and unambiguous. The mathematics used in formal software engineering methods relies heavily on set theory and logic. In many safety critical or mission critical systems, failures can have a high cost. Many safety critical systems can not be completely tested without endangering the lives of the people they are designed to protect. Use of formal methods reduces the number of specification errors dramatically, which means that the customer will encounter fewer errors when the product is deployed.

Using Formal Methods

• Define the data invariant, state, and operations for each system function

• data invariant -condition true throughout execution of function that contains a collection of data

• state- stored data accessed and altered by function • operations - system actions that take place when data are read or written to the state (a

precondition and postcondition is associated with each operation)

• Specification is represented in some set theoretic type notation from some formal language (e.g. Z or VDM)

• Specification correctness can be verified using mathematical proofs (set operations, logic operations, sequences, induction)

Formal Specification Properties

• Unambiguous - formal syntax used by formal methods has only one interpretation (unlike natural language statements)

• Consistency - ensuring through mathematical proof that initial facts can be mapped (using inference rules)into later statements within the specification

• Completeness - difficult to achieve in a large system even using formal methods

Weaknesses of Less Formal Approaches

• Contradictions (statements do not agree with one another) • Ambiguities(statements have more than one interpretation) • Vagueness (specifications in large documents are often not written precisely enough) • Incompleteness (e.g. failing to list limitations and error handling required of a function) • Mixed levels of abstraction(occurs when very abstract statements are intermixed randomly

with statements written at lower levels of detail)

Necessary Mathematics

• Constructive set specification (also known as set builder notation) • Set operations (membership, subset, union, intersection, difference, crossproduct or Cartesian

product, powerset) • Logic operators (and, or, not, implies, universal quantification) • Sequence properties (order, domain, range) • Sequence operators(concatenation, head, tail, front, last)

Writing Formal Specifications

• Begin by defining state in terms of abstract items to be manipulated by the function (similar to variable declaration in a programming language)

• Define the data invariant by writing the data relations that will not change during the execution of the function using mathematical notation

• rite he precondition and postcondition for the function using mathematical notation to show the system state before and after function execution

Formal Specification Language Components

• Syntax that defines the specific notation used to represent a specification • Semantics that help to define the objects used to define the system • Set of relations that define the rules that indicate which objects properly satisfy the

specification

Ten Commandments of Formal Methods

1. Choose the appropriate notation

2. Do not over-formalize

3. Estimate costs

4. Have a formal methods guru on call

5. Do not abandon traditional development methods

6. Document sufficiently

7. Do not compromise quality standards

8. Do not be dogmatic in assuming formal specifications are flawless

9. Use of formal methods does not eliminate the need to test products

10. Reuse is still important

Chapter 26 - Cleanroom Software Engineering

Overview

This chapter discusses the cleanroom approach to software engineering. The philosophy behind cleanroom software engineering is to develop code increments that are right the first time and verify their correctness before testing, rather than relying on costly defect removal processes. Cleanroom software engineering involves the integrated use of software engineering modeling, program verification, and statistical software quality assurance. Under cleanroom software engineering, the analysis and design models are created using a box structure representation (black-box, state box, and clear box). A box encapsulates some system component at a specific level of abstraction. Correctness verification is applied once the box structure design is complete. Once correctness has been verified for each box structure, statistical usage testing commences. This involves defining a set of usage scenarios and determining the probability of use for each scenario. Random data is generated which conform to the usage probabilities. The resulting error records are analyzed, and the reliability of the software is determined for the software component.

Distinguishing Characteristics of Cleanroom Techniques

• Makes extensive use of statistical quality control • Verifies design specification using mathematically-based proof of correctness • Relies heavily on statistical use testing to uncover high impact errors

Reasons Cleanroom Techniques Not Used Widely

• Some people believe cleanroom techniques are too theoretical, too mathematical, and too radical for use in real software development

• It does not advocate unit testing, relying instead on correctness verification and statistical quality control (a major departure from the way most software is developed today)

• Since most of the software industry is operating at the ad hoc level of the Capability Maturity Model, most organizations do not make rigorous use of the defined processes needed in all phases of the software life cycle

It should be noted that all of the above roadblocks to cleanroom usage can be overcome and that cleanroom software engineering offers substantial benefits to those who do it.

Clean room Strategy

• Increment planning. The project plan is built around the incremental strategy. • Requirements gathering. Using Chapter 11techniques, customer requirements are refined for

each increment. • Box structure specification. Box structures isolate and separate the definition of behavior, data,

and procedures at each level of refinement. • Formal design. Specifications (black-boxes) are iteratively refined to become architectural

designs (state-boxes) and component-level designs (clear boxes). • Correctness verification. Correctness questions are asked and answered and followed by formal

mathematical verification when required. • Code generation, inspection, verification. Box structures are translated into program language;

inspections are used to ensure conformance of code and boxes, as well as syntactic correctness of code; followed by correctness verification of the code.

• Statistical test planning. A suite of test cases is created to match the probability distribution of the projected product usage pattern.

• Statistical use testing. A statistical sample of all possible test cases is used rather than exhaustive testing.

• Certification. Once verification, inspection, and usage testing are complete and all defects removed, the increment is certified as ready for integration.

Box Types

• Black box - specifies a set of transition rules that describe the behavior of system components as responses to specific stimuli, makes use of inheritance in a manner similar to classes

• State box - generalization of a state machine, encapsulates the data and operations similar to an object, the inputs (stimuli) and outputs (responses) are represented, data that must be retained between transitions is encapsulated

• Clear box - contains the procedural design of the state box, in a manner similar to structured programming

Design Verification Advantages

• Reduces verification to a finite process • Improves quality • Lets cleanroom teams verify every line of code • Results in near zero levels of defects • Scales up to larger systems and higher levels • Produces better code than unit testing

Certification Steps

• Usage scenarios must be created • Usage profile is specified • Test cases generated from the usage profile • Tests are executed and failure data are recorded and analyzed • Reliability is computed and recorded

Cleanroom Certification Models

• Sampling model - determines the number if random cases that need to be executed to achieve a particular reliability level

• Component model - allows analyst to determine the probability that a given component in a multi-component system fails prior to completion

• Certification model - projected overall reliability of system

Chapter 27 Component-Based Software Engineering

Overview

The chapter describes component-based software engineering (CBSE) as a process that emphasizes the design and construction of computer-based systems using reusable software components. This has the potential advantage of delivering highly reliable software products in a very short time. CBSE encourages the use of predictable architectural patterns and standard software infrastructures that improve overall product quality. CBSE encompasses two parallel engineering activities, domain engineering and component-based development. Domain engineering explores the application domain with the specific intent of finding functional, behavioral, and data components that are candidates for reuse and places them in reuse libraries. Component-based development elicits requirements from the customer and selects an appropriate architectural style to meet the objectives of the system to be built. The next steps are to select potential components for reuse, qualify the components to be sure they fit the system architecture properly, adapt the components if they must be modified to integrate them, then integrate the components into subsystems within the application. Custom components are engineered only when existing components cannot be reused. Formal technical reviews and testing are applied to ensure the quality of the analysis model and the design model. The resulting code is tested to uncover errors in the newly developed software.

Engineering of Component-Based Systems

• Software team elicits requirements for system to be built • Architectural design is established • Team determines which of the requirements are amenable to composition rather than

construction

• Are commercial off-the-shelf (COTS) components available to implement the requirement? • Are internally developed reusable components available to implement the requirement? • Are the interfaces for available components compatible within in the proposed system

architecture?

• Team attempts to remove or modify requirements that cannot be implemented with COTS or in-house components?

• For those requirements that can be addressed with available components the following activities take place:

• component qualification - candidate components are identified based on services provided and means by which consumers access them

• component adaptation - candidate components are modified to meet the needs of the architecture or discarded

• component composition - architecture dictates the composition of the end product from the nature of the connections and coordination mechanisms

• component update - updating systems that include COTS is made more complicated by the fact that a COTS developer must be involved

• Detailed design activities commence for remainder of the system

Domain Engineering

• Domain analysis

• define application domain to be investigated • categorize items extracted from domain • collect representative applications from the domain • analyze each application from sample • develop an analysis model for objects

• Domain model • Software architecture development • Structural model

• consists of small number of structural elements manifesting clear patterns of interaction • architectural style that can be reused across applications in the domain • structure points are distinct constructs within the structural model (e.g. interface, control

mechanism, response mechanism)

• Reusable component development (new software components must be developed and integrated with existing software components)

• Repository of reusable artifacts or components

Structure Point Characteristics

• Abstractions with limited number of instances within an application and recurs in applications in the domain

• The rules governing the use of a structure point should be easily understood and structure point interface should be simple

• The structure point should implement information hiding by isolating all complexity contained within the structure point itself

Component-Based Development

• Analysis • Architectural design

• component qualification • component adaptation • component decomposition

• Component engineering • Testing

• Iterative component update

Component Adaptation Techniques

• White-box wrapping (integration conflicts removed by making code-level modifications to the code)

• Grey-box wrapping (used when component library provides a component extension language or API that allows conflicts to be removed or masked)

• Black-box wrapping (requires the introduction of pre- and post-processing at the component interface to remove or mask conflicts)

Component Composition Infrastructure Elements

• Data exchange model (similar to drag and drop type mechanisms should be defined for all reusable components, allow human-to-software and component-to-component transfer)

• Automation (tools, macros, scripts should be implemented to facilitate interaction between reusable components)

• Structured storage (heterogeneous data should be organized and contained in a single data structure rather several separate files)

• Underlying object model (ensures that components developed in different languages are interoperable across computing platforms)

Representative Component Standards

• Object Management Group (OMG) CORBA (common object request broker architecture) • Microsoft COM (component object model) • Sun JavaBeans Component System

Classifying and Retrieving Components

• Describing reusable components

• concept - what the component does • content - how the concept is realized • context - specifies conceptual, operational, and implementation features of the software

component within its domain of application

• Library indexing methods

• uncontrolled indexing vocabularies (syntax free, no restrictions) • enumerated classification (hierarchical listing of the domain objects grouped by class relations) • faceted classification (based on 1 to 8 basic descriptive features from the application domain) • attribute-value classification (similar to faceted classification using unlimited number of fixed

terms) • Reuse environment elements • component database capable of storing software components and classification information to

allow their retrieval

• library management system to allow access to database • software component retrieval system that enables client software to retrieve components and

services from library server

• CBSE tools that support integration of reused components into a new design or implementation

Economics of Reuse

• Quality -- with each reuse additional component defects are identified and removed which improves quality.

• Productivity -- since less time is spent on creating plans, models, documents, code, and data the same level of functionality can be delivered with less effort so productivity improves.

• Cost -- savings projected by estimating the cost of building the system from scratch and subtracting the costs associated with reuse and the actual cost of the software as delivered.

• Cost analysis using structure points -- can be computed based on historical data regarding the costs of maintaining, qualification, adaptation, and integrating each structure point.

• Reuse metrics can be computed for CBSE

Chapter 28 Client/Server Software Engineering

Overview

This chapter discusses client/server (C/S) software engineering. Client/server software engineering blends conventional principles, concepts, and methods discussed earlier in the text with elements of object-oriented and component-based software engineering. C/S architectures dominate the landscape of computer-based systems. In C/S architectures, software residing on one computer (the client) requests services or data from another computer (the server). The process model used in C/S software engineering is evolutionary beginning with requirements elicitation. Functionality is allocated to subsystems of components that are assigned to either the client or the server side of the C/S architecture. Design focuses on integration of existing components and creation of new components. Implementation and testing must exercise both the client and server functionality within the context of the component integration standards and the C/S architecture. C/S software engineering relies on the same SQA practices as other software engineering processes. Formal technical reviews are used to assess the quality of the analysis and design models. Specialized reviews consider issues associated with component integration and middleware. Testing is used to uncover errors at the component, subsystem, client, and sever levels.

Representative Client/Server Systems

• File servers (client requests selected records from a file, server transmits records to client over the network)

• Database servers (client sends SQL requests to server, server processes the request and returns the results to the client over the network)

• Transaction servers (client sends requests that invokes remote procedures on the server side, sever executes procedures invoked and returns the results to the client)

• Groupware servers (server provides set of applications that enable communication among clients using text, images, bulletin boards, video, etc.)

Software Components for C/S Systems

• User interaction/presentation subsystem (handles all user events) • Application subsystem (implements requires defined by the application within the context of

the operating environment, components may reside on either the client or server side) • Database management subsystem (performs data manipulation and management for the

application) • Middleware (all software components that exist on both the client and the server to allow

exchange of information)

Representative C/S Configuration Options

• Distributed presentation - database and application logic remain on the server, client software is used to reformat server data into GUI format

• Remote presentation - similar to distributed presentation, primary database and application logic remain on the server, data sent by the server is used by the client to prepare the user presentation

• Distributed logic - client is assigned all user presentation tasks associated with data entry and formulating server queries, server is assigned data management tasks and updates information based on user actions

• Remote data management - applications on server side create new data sources, applications on client side process the new data returned by the server

• Distributed databases - data is spread across multiple clients and servers, requiring clients to support data management as well as application and GUI components

• Fat server - most software functions for C/S system are allocated to the server • Thin clients - network computer approach relegating all application processing to a fat server

Guidelines for Distributing Application Subsystems

• The presentation/interaction subsystem is generally placed on the client. • If the database is to be shared by multiple users connected by a LAN, the database is typically

located on the server. • Static data used for reference should be allocated to the client.

Linking C/S Software Subsystems

• Pipes (permit messaging between different machines running different operating systems) • Remote procedure calls (permit process running on one machine to invoke execution of

process residing on another machine) • Client/server SQL interaction (SQL requests passed from client to server DBMS, this

mechanism is limited to RDBMS)

Representative Middleware Architectures

• CORBA (ORB) • COM (Microsoft) • JavaBeans (Sun)

Design Issues for C/S Systems

• Data and architectural design - dominates the design process to be able to effectively use the capabilities of RDBMS or OODMBS

• Event-driven paradigm - when used, behavioral modeling should be conducted and the control-oriented aspects of the behavioral model should translated into the design model

• Interface design - elevated in importance, since the user interaction/presentation component implements all functions typically associated with a GUI

• Object-oriented point of view - often chosen, since an object structure is provides by events initiated in the GUI and their event handlers within the client-based software

Architectural Design for Client/Server Systems

• Best described as communicating processes style architecture whose goal is to achieve easy scalability when adding and arbitrary number of clients

• Since modern C/S systems tend to be component-based, an object request broker (ORB) architecture is used for implementation

• Object adapters or wrappers provide service to facilitate communication among client and server components

• component implementations are registered • all component references are interpreted and reconciled • component references are mapped to corresponding component implementations

• objects are activated and deactivated • operations are invoked when messages are transmitted • security features are implemented

C/S Design Repository Information

• Entities (from ER diagram) • Files (which implement entities) • File-to-field relationship (establishes file layout) • Fields (from data dictionary) • File-to-file relationships (related files that may be joined together) • Relationship validation • Field type (used to permit inheritance from super classes) • Data type (characteristics of field data) • File type (used to identify file location) • Field function (key, foreign key, attribute, etc.) • Allowed values • Business values (rules for editing, calculating derived fields, etc.)

Data Distribution and Management Techniques

• Relational data base management systems (RDBMS) • Manual extract (user allowed to manually copy data from server to client) • Snapshot (automates manual extract by specifying a copy of the data be transferred from the

client to the server at predefined intervals) • Replication (multiple copies of data are maintained at different sites) • Fragmentation (system database is spread across several machines)

C/S Design Approach

1. For each elementary business process, identify the files created, updated, referenced, or deleted.

2. Use the files from step 1 as basis for defining components or objects. 3. For each component, retrieve the business rules and other business object information that has

been established for the relevant file. 4. Determine which rules are relevant to the process and decompose the rules down to the method

level. 5. As required, define any additional components that are needed to implement the methods.

Process Design Entities

• Methods - describe how a business rule is to be implmemented • Elementary processes - business processes identified in the analysis model • Process/component link - identifies components that makeup the solution for an elementary

business process • Components - describes components shown on structure chart • Business rule/component link - identified components significant to implementation of a given

business rule

C/S Testing Strategy

• Application function tests (client applications tested in stand alone manner) • Sever tests (test coordination and management functions of server, also measure performance

of server) • Database tests (check accuracy and integrity server data, examine transactions posted by client,

test archiving) • Transaction testing (ensure each class of transactions is processed correctly) • Network communication testing (verify communication among network nodes)

C/S Testing Tactics

• Begins with testing in the small and then proceeds to integration testing using the non-incremental or big bang approach

• Requires special attention to configuration testing and compatibility testing • OO testing tactics can be used for C/S systems (even when system was not built using OO

methodology) • GUI testing requires special techniques in C/S systems (e.g. structured capture/playback)

Chapter 29 - Web Engineering

Overview

The chapter describes Web engineering (WebE) as the process used to create high quality Web-based applications (WebApps). As WebApps become increasingly integrated in business strategies (e.g. e-commerce) the need to build reliable, usable, and adaptable systems grows in importance. Web engineering is not a perfect clone of software engineering, but it draws heavily on many of software engineering's principles and management activities. The Web engineering process begins with the formulation of the problem to be solved by the WebApp. The project is planned and the WebApp requirements are analyzed. Architectural, navigational, and interface design are conducted. The system is implemented using specialized languages and tools associated with the Web. WebApps tend to be highly evolutionary, so mechanisms for configuration management, quality control, and maintenance must be established early. Web engineering relies on formal technical reviews to assess the quality of the analysis and design models. Specialized reviews are conducted to assess the usability of the WebApp. Testing is applied to uncover errors in content, functionality, and compatibility.

WebApp Attributes

• Network intensive • Content-driven • Continuous evolution • Immediacy • Security • Aesthetics

WebE Application Categories

• Informational (read only content provided with simple navigation) • Downloads (user downloads information from server) • Customizable (user customizes content to specific needs) • Interaction (community of users communicate using chat rooms, bulletin boards, or instant

messaging) • User input (users complete on-line forms to communicate need) • Transaction-oriented (user makes request fulfilled by WebApp - places an order) • Service-oriented (application provides service to user, e.g. helps user determine mortgage

payment) • Portal(application directs users to other web content or services) • Database access (user queries a large database and extracts information) • Data warehousing (user queries large collection of databases and extracts information)

Web Quality Requirements

• Usability • Functionality • Reliability • Efficiency • Maintainability

WebApp Enabling Technologies

• Component-based development (CORBA, COM/DCOM, JavaBeans) • Security (encryption, firewalls, etc.) • Internet standards (HTML, XML,SGML)

Evolutionary WebE Process Model

• Formulation (goals and objectives, scope for first increment)

• what is the motivation for the WebApp? • why is the WebApp needed? • who will use the WebApp? • informational goals (user's intention for using the content) • applicative goals (ability to perform tasks within the WebApp)

• Planning (estimates project cost, evaluates risks, defines finely granulated schedule for first increment and coarser schedule for subsequent increments)

• Analysis (establishes requirements and identifies content items)

• content analysis (content provided by WebAppis identified) • interaction analysis (use-cases developed to describe user interaction with WebApp) • functional analysis (usage scenarios used to define operations and functions applied to the

WebApp content) • configuration analysis (WebApp environmental infrastructure is described in detail)

• Engineering (content design and production tasks are one thread, architectural design, navigation design, interface are the other thread)

• Page generation and testing (content and technical deigns are merged to produce executable web pages; testing exercises WebApp navigation, attempts to uncover errors in applets/scripts/forms, and checks for environment incompatibilities)

• Customer evaluation (each increment of the WebApp is reviewed and changes required by customer are applied to next increment)

Technical Elements for Web-Based Design

• Design principles and methods (high modularity, low coupling, information hiding, stepwise refinement, OO design methods)

• Golden rules (design heuristics for hypermedia applications) • Design Patterns (can be applied to WebApp functional elements, documents, graphics, and

general aesthetics) • Templates (provide reusable skeletal frameworks for any design pattern or document used

within the WebApp)

Web App Architectural Structures

• Linear structures (text and graphics presented in fixed sequential order) • Grid structures (useful when WebApp content must be organized in two pr more ways or

dimensions) • Hierarchical structures (not always traversed in strict depth-first manner, branches are often

inter-linked) • Networked or "pure" web structure (every node is connected to every other node)

WebE Design Patterns

• Cycle (user is returned to previously visited node) • Web ring (implements a grand cycle that links entire hypertext into a tour of asubject) • Contour (occurs when cycles are interconnected, allowing navigation across paths defined by

cycles) • Counterpoint (hypertext commentary used to interrupt content narrative to provide additional

information or insight) • Mirrorworld (content is presented using several threads, each with its own perspective or point

of view) • Sieve(user guided through a series of decisions to direct user to specific content indexed by the

decisions) • Neighborhood (uniform navigation is provided to user regardless of position within the

WebApp)

NavigationalDesign

• Identify the semantics of navigation for different users based on the perceived roles (i.e. visitor, registered customer, or privileged user) and the goals associated with their roles.

• Define the mechanics (syntax) of achieving navigation

WebApp Interface Guidelines

• Minor server errors are likely to cause user to leave WebApp and look for an alternative site • Reading speed on monitor is about 25% slower than for hardcopy • Avoid "under construction" signs • Users prefer not having to scroll to read content • Navigation menus and headers should be designed consistently and be available on all pages

available to the user • Do not rely on browser functions to assist in navigation • Aesthetics should never take precedence over application functionality • Navigation should be obvious to causal users

Testing WebApps for Errors

• WebApp content model is reviewed to uncover errors. • Design model for WebApp is reviewed to uncover navigation errors. • Selected processing components and web pages are unit tested. • Architecture is constructed and integration tests are performed. • Assembled WebApp is tested for overall functionality and content delivery. • WebApp is implemented in a variety of different environmental configurations and the

compatibility of WebApp with each is assessed. • WebAppis tested by a controlled and monitored group of end-users.

WebE Team Members

• Content developers and providers (focus on generation and/or collection of WebApp content) • Web publisher (liaison between technical staff who engineers WebApp and non-technical

content developers and providers) • Web engineer (involved with WebApp requirements elicitation, analysis modeling,

architectural design, navigational design, interface design, implementation, and testing) • Support specialist (responsible for continuing WebApp maintenance and support) • Administrator or web master (responsible for daily operation of WebApp)

Project Management Concerns Unique to WebE

• Many WebApps are out sourced to vendors specializing in the development of web-based systems and applications.

• WebApp development is relatively new and there is little historical data to use for estimation (e.g. there are few if any published WebE metrics).

• The continuously evolving nature of WebApps make estimation, risk analysis, and scheduling more complicated since project scope is less clearly defined than in other software development projects.

WebE Project Management Guidelines

• Initiating a project

1. many of the analysis activities should be performed internally

2. a rough design for the WebApp should be developed internally

3. a rough delivery schedule including milestone dates and final delivery dates should be developed

4. the degree of oversight and interaction by the contractor with the vendor should be identified

• Selection of candidate outsourcing vendors

1. Interview past clients to determine vendor's past performance 2. be certain the vendor's chief web engineer(s) from past successful projects will involved with

yours 3. carefully examine samples of the vendor's work on projects similar to yours

• Assessing the validity of price quotes and reliability estimates

1. does the quoted cost of the WebApp provide a direct or indirect return-on-investment that justifies the project?

2. does the vendor exhibit the required level of professionalism and experience?

• Degree of project management you can expect or perform(directly proportional to the size, cost, and complexity of WebApp, the larger the more formal the management and SQA activities)

• Assessing the development schedule (short development times suggest the use of fine granularity in the schedule, link minor milestones scheduled on a daily timeline)

• Managing the scope (using an incremental process model allows the development team to freeze the scope for one increment to allow an operational WebApp release to be created)

WebE Software Configuration Management Issues

• Content • integrating heterogeneous media • volatility • People • designers often are forced to create content • content creators often have no software engineering knowledge • Scalability • Politics • Who owns a WebApp? • Who assumes responsibility for accuracy? • Who makes changes? • Who pays for changes

Chapter 31 Computer-Aided Software Engineering

Overview

This chapter discusses the use of computer-aided software engineering (CASE) tools that can assist software engineering managers and practitioners with every activity associated with the software development process. CASE tools can automate management activities and can manage work products. CASE tools can assist engineers with analysis, design, coding, and testing work. Software engineering is hard work and tools that reduce the effort required to produce a work product or accomplish a milestone have substantial benefits. CASE tools assist the software engineer in producing high quality work products. Tools can provide the software engineer with improved insight into the software product and make decisions that lead to improved software quality. Tools complement solid software engineering practices. A good software process framework must be established and software quality must be emphasized before tools can be used effectively.

Prerequisites to Software Tool Use

• Collection of useful tools that help in every step of building a product • Organized layout that enables tools to be found quickly and used efficiently • Skilled craftsperson who understands how to use the tools effectively

CASE Building Blocks

• CASE tools • Integration framework(specialized programs allowing CASE tools to communicate with one

another) • Portability services (allow CASE tools and their integration framework to migrate across

different operating systems and hardware platforms without significant adaptive maintenance) • Operating system (database and object management services) • Hardware platform • Environmental architecture (hardware and system support)

CASE Tool Taxonomy

• Business process engineering tools - represent business data objects, their relationships, and flow of the data objects between company business areas

• Process modeling and management tools - represent keyelements of processes and provide links to other tools that provide support to defined process activities

• Project planning tools - used for cost and effort estimation, and project scheduling • Risk analysis tools - help project managers build risk tables by providing detailed guidance in

the identification and analysis of risks • Requirements tracing tools - provide systematic database-like approach to tracking requirement

status beginning with specification • Metrics and management tools -management oriented tools capture project specific metrics that

provide an overall indication of productivity or quality, technically oriented metrics determine metrics that provide greater insight into the quality of design or code

• Documentation tools - provide opportunities for improved productivity by reducing the amount of time needed to produce work products

• System software tools - network system software, object management services, distributed component support, and communications software

• Quality assurance tools -metrics tools that audit source code to determine compliance with language standards or tools that extract metrics to project the quality of software being built

• Database management tools - RDMS and OODMS serve as the foundation for the establishment of the CASE repository

• Software configuration management tools -uses the CASE repository to assist with all SCM tasks (identification, version control, change control, auditing, status accounting)

• Analysis and design tools -enable the software engineer to create analysis and design models of the system to be built, perform consistency checking between models

• PRO/SIM tools - prototyping and simulation tools provide software engineers with ability to predict the behavior of real-time systems before they are built and the creation of interface mockups for customer review

• Interface design and development tools - toolkits of interface components, often part environment with a GUI to allow rapid prototyping of user interface designs

• Prototyping tools - enable rapid definition of screen layouts, data design, and report generation • Programming tools - compilers, editors, debuggers, OO programming environments, fourth

generation languages, graphical programming environments, applications generators, and database query generators

• Web development tools - assist with the generation of web page text, graphics, forms, scripts, applets, etc.

• Integration and testing tools

• Data acquisition (get data for testing) • static measurement (analyze source code without using test cases) • dynamic measurement (analyze source code during execution) • simulation (simulate function of hardware and other externals) • test management (assist in test planning, development, and control) • cross-functional (tools that cross test tool category boundaries)

• Static analysis tools - code-based testing tools, specialized testing languages, requirements-based testing tools

• Dynamic analysis tools -intrusive tools modify source code by inserting probes to check path coverage, assertions, or execution flow, non-intrusive tools use a separate hardware processor running in parallel with processor containing the program being tested

• Test management tools - coordinate regression testing, compare actual and expected output, conduct batch testing, and serve as generic test drivers

• Client/server testing tools - exercise the GUI and network communications requirements for the client and server

• Reengineering tools

• reverse engineering to specification tools - generate analysis and design models from source code, where used lists, and other design information

• code restructuring and analysis tools -analyze program syntax, generate control flow graph, and automatically generates a structured program

• on-line system reengineering tools - used to modify on-line DBMS

Integrated CASE Environments

• Provide mechanism for sharing information among all tools contained in the environment • Enable changes to items to be tracked to other information items • Provide version control and overall configuration management • Allow direct access to any tool contained in the environment • Establish automated support for the chosen software process model, integrating CASE tools

and SCI's into a standard work break down structure • Enable users of each tool to experience a consistent look and feel at the human-computer

interface • Support communication among software engineers • Collect both management and technical metrics to improve the process and the product

Integration Architecture

• User interface layer

• interface toolkit - contains software for UI management and library of display objects • common presentation protocol - guidelines that give all CASE tools the same look and feel

(icons, mouse behavior, menu names, object names)

• Tools layer

• tools management services - control behavior of tools inside environment • CASE tools themselves

• Object management layer (OML) - performs the configuration management function, working with the CASE repository OML provides integration services

• Shared repository layer - CASE database and access control functions enabling the OML to interact with the database

CASE Repository Functions

• Data integrity - includes functions to validate entries to the repository and ensure consistency among related objects

• Information sharing - provides mechanism for sharing information among multiple developers and multiple tools, controls modification of information

• Data-tool integration - establishes shared data model and performs configuration management functions

• Data-data integration - database management system allowing access to related objects so functions can be achieved

• Methodology enforcement - the E-R model used to define steps needed to be conducted to build the repository contents

• Document standardization - definition of objects in the database leads directly to a standard approach for creation of engineering documents

Important DBMS Features Relevant to CASE Repositories

• Non-redundant data storage • High-level access • Data independence • Transaction control • Ad hoc data queries and reports • Openness • Multi-user support

Special Features of CASE Repositories

• Storage of sophisticated data structures (diagrams, documents, files, simple variables, information model describing relationships and semantics of data stored in repository)

• Integrity enforcement (business rules, policies, constraints, and requirements on the information being entered into repository, triggers may be used to check the validity of the design models in real time)

• Semantic-rich tool interface (repository meta-model contains semantics that enable a variety of tools to interpret meaning of data stored in the repository)

• Process/project management(contains information about the software application, the characteristics of each project, and the organization's general process for software development - phases, tasks, deliverables)

Software Configuration Management Features Relevant to CASE Repositories

• Versioning • Dependency tracking and change management • Requirements tracing • Configuration management • Audit trails