CS 455 CH 31, 34, 35, Polya, No silver bullet

risk analysis approach proposed by the U.S. Air Force, you can apply the following steps to determine the overall consequences of a risk:

(1) determine the average probability of occurrence value for each risk component; (2) determine the impact for each component based on the criteria shown (3) complete the risk table and analyze the results as described in the preceding sections.

Hope for the Silver

- Ada and other high-level language advances - Object-oriented programming (abstract data types and hierarchical types) - Artificial intelligence: 1. The use of computers to solve problems that previously could only be solved by applying human intelligence. 2: The use of a specific set of programming techniques known as heuristic or rule-based programming. - Expert Systems - "Automatic" programming. - Graphical programming - Program verification (testing and the repair of bugs) - Environments and tools (databases) - Workstations

Although there are many reasons why software is delivered late, most can be traced to one or more of the following root causes:

- An unrealistic deadline established by someone outside the software team and forced on managers and practitioners on the group. - Changing customer requirements that are not reflected in schedule changes. - An honest underestimate of the amount of effort and/or the number of re- sources that will be required to do the job. - Predictable and/or unpredictable risks that were not considered when the project commenced. - Technical difficulties that could not have been foreseen in advance. - Human difficulties that could not have been foreseen in advance. - Miscommunication among project staff that results in delays. - A failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem.

Tracking can be accomplished in a number of different ways:

- Conducting periodic project status meetings in which each team member reports progress and problems. - Evaluating the results of all reviews conducted throughout the software engineering process. - Determining whether formal project milestones have been accomplished by the scheduled date. - Comparing the actual start date to the planned start date for each project task listed in the resource table. - Meeting informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon. - Using earned value analysis (Section 34.6) to assess progress quantitatively.

The following subtasks are derived for the Design the Interface task for the fourth increment:

- Develop a sketch of the page layout for the space design page. - Review layout with stakeholders. - Design space layout navigation mechanisms. - Design "drawing board" layout.10 - Develop procedural details for the graphical wall layout function. - Develop procedural details for the wall length computation and display function. - Develop procedural details for the graphical window layout function. - Develop procedural details for the graphical door layout function. - Design mechanisms for selecting security system components (sensors, cameras, microphones, etc.). • Develop procedural details for the graphical layout of security system components. • Conduct pair walkthroughs as required.

How to grow great designers? Space does not permit a lengthy discussion, but some steps are obvious:

- Systematically identify top designers as early as possible. The best are often not the most experienced. - Assign a career mentor to be responsible for the development of the prospect, and carefully keep a career file. - Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of a advanced formal education, and short courses, all interspersed with solo-design and technical leadership assignments. - Provide opportunities for growing designers to interact with and stimulate each other.

Tracking Progress for an OO Project

- Technical milestone: OO analysis completed - Technical milestone: OO design completed - Technical milestone: OO programming completed - Technical milestone: OO testing

To determine the earned value, the following steps are performed:

- The budgeted cost of work scheduled (BCWS) is determined for each work task represented in the schedule. During estimation, the work (in person-hours or person-days) of each software engineering task is planned. Hence, BCWSi is the effort planned for work task i. To determine progress at a given point along the project schedule, the value of BCWS is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule. - The BCWS values for all work tasks are summed to derive the budget at completion (BAC). Hence, BAC = SUM (BCWS_k) for all tasks k - Next, the value for budgeted cost of work performed (BCWP) is computed. The value for BCWP is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule.

The following questions have been derived from risk data obtained by surveying experienced software project managers in different parts of the world. The questions are ordered by their relative importance to the success of a project.

1. Have top software and customer managers formally committed to support the project? 2. Are end users enthusiastically committed to the project and the system/ product to be built? 3. Are requirements fully understood by the software engineering team and its customers? 4. Have customers been involved fully in the definition of requirements? 5. Do end users have realistic expectations? 6. Is the project scope stable? 7. Does the software engineering team have the right mix of skills? 8. Are project requirements stable? 9. Does the project team have experience with the technology to be implemented? 10. Is the number of people on the project team adequate to do the job? 11. Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built?

The software process (and every software project) is populated by stakeholders who can be categorized into one of five constituencies:

1. Senior managers who define the business issues that often have a significant influence on the project. 2. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. 3. Practitioners who deliver the technical skills that are necessary to engineer a product or application. 4. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. 5. End users who interact with the software once it is released for production use.

Concept development projects are approached by applying the following major tasks:

1.1 Concept scoping determines the overall scope of the project. 1.2 Preliminary concept planning establishes the organization's ability to undertake the work implied by the project scope. 1.3 Technology risk assessment evaluates the risk associated with the technology to be implemented as part of the project scope. 1.4 Proof of concept demonstrates the viability of a new technology in the software context. 1.5 Concept implementation implements the concept representation in a manner that can be reviewed by a customer and is used for "marketing" purpose when a concept must be sold to other customers or management. 1.6 Customer reaction to the concept solicits feedback on a new technology concept and targets specific customer applications.

Percent complete

= BCWP/BAC provides a quantitative indication of the percent of completeness of the project at a given point in time t.

Percent scheduled for completion

= BCWS/BAC provides an indication of the percentage of work that should have been completed by time t.

Constantine [Con93] suggests four "organizational paradigms" for software engineering teams:

A closed paradigm structures a team along a traditional hierarchy of authority. Such teams can work well when producing software that is quite similar to past efforts, but they will be less likely to be innovative when working within the closed paradigm. A random paradigm structures a team loosely and depends on the individual initiative of the team members. When innovation or technological breakthrough is required, teams following the random paradigm will excel. But such teams may struggle when "orderly performance" is required. An open paradigm attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm. Work is performed collaboratively, with heavy communication and consensus-based decision making the trademarks of open paradigm teams. Open paradigm team structures are well suited to the solution of complex problems but may not perform as efficiently as other teams. A synchronous paradigm relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves.

project schedule

Becomes a road map that defines the tasks and milestones to be tracked and controlled as the project proceeds. An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.

Cost performance index

CPI = BCWP/ACW CPI value close to 1.0 provides a strong indication that the project is within its defined budget.

Cost varience

CV = BCWP - ACWP It is an absolute indication of cost savings (against planned costs) or shortfall at a particular stage of a project.

Polya's Third Principle:

Carry out the plan If it continues not to work discard it and choose another one. Don't be misled

Software project scheduling Basic Principles

Compartmentalization. The project must be compartmentalized into a number of manageable activities and tasks. To accomplish compartmentalization, both the product and the process are decomposed. Interdependency. The interdependency of each compartmentalized activity or task must be determined. Some tasks must occur in sequence, while others can occur in parallel. Some activities cannot commence until the work product produced by another is available. Other activities can occur independently. Time allocation. Each task to be scheduled must be allocated some number of work units (e.g., person-days of effort). In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies and whether work will be conducted on a full-time or part-time basis. Effort validation. Every project has a defined number of people on the soft- ware team. As time allocation occurs, you must ensure that no more than the allocated number of people has been scheduled at any given time. For example, consider a project that has three assigned software engineers (e.g., three person-days are available per day of assigned effort). On a given day, seven concurrent tasks must be accomplished. Each task requires 0.50 person-days of effort. More effort has been allocated than there are people to do the work. Defined responsibilities. Every task that is scheduled should be assigned to a specific team member. Defined outcomes. Every task that is scheduled should have a defined outcome. For software projects, the outcome is normally a work product (e.g., the design of a component) or a part of a work product. Work products are often combined in deliverables. Defined milestones. Every task or group of tasks should be associated with a project milestone. A milestone is accomplished when one or more work products has been reviewed for quality and has been approved.

To develop a comprehensive taxonomy of software project types, most software organizations encounter the following projects:

Concept development projects that are initiated to explore some new business concepts or applications of some new technology. New application development projects that are undertaken as a consequence of a specific customer request. Application enhancement projects that occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end-user. Application maintenance projects that correct, adapt, or extend existing software in ways that may not be immediately obvious to the end-user. Reengineering projects that are undertaken with the intent of rebuilding an existing (legacy) system in whole or in part.

*PRODUCT* The first software project management activity is the determination of software scope. Scope is defined by answering the following questions:

Context. How does the software to be built fit into a larger system, product, or business context, and what constraints are imposed as a result of the context? Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input? Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?

MOI Model

Motivation. The ability to encourage (by "push or pull") technical people to produce to their best ability. Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

Software manager focus on the four Ps:

People Product Process Project

People-CMM/People-CMMI

People-Capability Maturity Model/People-Capability Maturity Model Integration

Another view of the characteristics that define an effective project manager emphasizes four key traits:

Problem-solving. An effective software project manager can diagnose the technical and organizational issues that are most relevant, systematically structure a solution or properly motivate other practitioners to develop the solution, apply lessons learned from past projects to new situations, and remain flexible enough to change direction if initial attempts at problem solution are fruitless. Managerial identity. A good project manager must take charge of the project. She must have the confidence to assume control when necessary and the assurance to allow good technical people to follow their instincts. Achievement. A competent manager must reward initiative and accomplishment to optimize the productivity of a project team. She must demonstrate through her own actions that controlled risk-taking will not be punished. Influence and team building. An effective project manager must be able to "read" people; she must be able to understand verbal and nonverbal signals and react to the needs of the people sending these signals. The manager must remain under control in high-stress situations.

One method for identifying risks is to create a risk item checklist. The check- list can be used for risk identification and focuses on some subset of known and predictable risks in the following generic subcategories:

Product size—Risks associated with the overall size of the software to be built or modified. Business impact—Risks associated with constraints imposed by management or the marketplace. Stakeholder characteristics—Risks associated with the sophistication of the stakeholders and the developer's ability to communicate with stakeholders in a timely manner. Process definition—Risks associated with the degree to which the software process has been defined and is followed by the development organization. Development environment—Risks associated with the availability and quality of the tools to be used to build the product. Technology to be built—Risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system. Staff size and experience—Risks associated with the overall technical and project experience of the software engineers who will do the work.

Risk Exposure (RE) a.k.a. "Risk Impact"

RE = P X C where P is the probability of occurrence for a risk, and C is the cost to the project should the risk occur. EXAMPLE: Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into the application. The remain- ing functionality will have to be custom developed. Risk probability. Eighty percent (likely). Risk impact. Sixty reusable software components were planned. If only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 3 100 3 14 5 $25,200. Risk exposure. RE 5 0.80 3 25,200 ~ $20,200.

*PROJECT* five-part commonsense approach to software projects:

Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be solved and then setting realistic objectives and expectations for everyone who will be involved in the project. It is reinforced by building the right team and giving the team the autonomy, authority, and technology needed to do the job. Maintain momentum. Many projects get off to a good start and then slowly disintegrate. To maintain momentum, the project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team's way. Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of test cases) are produced and approved (using technical reviews) as part of a quality assurance activity. In addition, software process and project measures can be collected and used to assess progress against averages developed for the software development organization. Make smart decisions. In essence, the decisions of the project manager and the software team should be to "keep it simple." Whenever possible, decide to use commercial off-the-shelf software or existing software components or patterns, decide to avoid custom interfaces when standard approaches are available, decide to identify and then avoid obvious risks, and decide to allocate more time than you think is needed to complex or risky tasks (you'll need every minute). Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project. Evaluate the planned and actual schedules, collect and analyze software project metrics, get feedback from team members and customers, and record findings in written form.

Condition-transition-consequence (CTC) format

That is, the risk is stated in the following form: Given that <condition> then there is concern that (possibly) <consequence>. This general condition can be refined in the following manner: Subcondition 1. Certain reusable components were developed by a third party with no knowledge of internal design standards. Subcondition 2. The design standard for component interfaces has not been solidified and may not conform to certain existing reusable components. Subcondition 3. Certain reusable components have been implemented in a language that is not supported on the target environment.

Risk Management

The objective of risk management tools is to assist a project team in defining risks, assessing their impact and probability, and tracking risks throughout a software project. All efforts designed to preserve assets and earning power associated with a business. Assumes that mitigation efforts have failed and that the risk has become a reality.

risk-monitoring

The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. It is a project tracking activity with three primary objectives: (1) to assess whether predicted risks do, in fact, occur; (2) to ensure that risk aversion steps defined for the risk are being properly applied. (3) to collect information that can be used for future risk analysis. It also attempts to allocate origin [what risk(s) caused which problems throughout the project].

Risk Information Sheet

The risk is documented individually and is maintained using a database system so that creation and information entry, priority ordering, searches, and other analysis may be accomplished easily. Including: - Description - Refinement/context - Mitigation/monitoring - Management/contingenc paln/trigger - Current Status

Polya's First Principle:

Understand the problem: Polya taught teachers to ask students questions such as: - Do you understand all the words used in stating the problem? - What are you asked to find or show? - Can you think of a picture or diagram that might help you understand the problem? - Is there enough information to enable you to find a solution?

*PROJECT* W5HH Principle

Why is the system being developed? All stakeholders should assess the validity of business reasons for the software work. Does the business purpose justify the expenditure of people, time, and money? What will be done? The task set required for the project is defined. When will it be done? The team establishes a project schedule by identifying when project tasks are to be conducted and when milestones are to be reached. Who is responsible for a function? The role and responsibility of each member of the software, the team is defined. Where are they located organizationally? Not all roles and responsibilities reside within software practitioners. The customer, users, and other stakeholders also have responsibilities. How will the job be done technically and managerially? Once product scope is established, management and technical strategy for the project must be defined. How much of each resource is needed? The answer to this question is derived by developing estimates (Chapter 33) based on answers to earlier questions.

Once the information necessary for the generation of a time-line chart has been input, the majority of software project scheduling tools produce project tabular

a tabular listing of all project tasks, their planned and actual start and end dates, and a variety of related information. Used in conjunction with the time-line chart, project tables enable you to track progress.

task networks

also called an activity network, is a graphic representation of the task flow for a project. It is sometimes used as the mechanism through which task sequence and dependencies are input to an automated project scheduling tool.

Risk projection

also called risk estimation, attempts to rate each risk in two ways— (1) the likelihood or probability that the risk is real and will occur and (2) the consequences of the problems associated with the risk, should it occur. You work along with other managers and technical staff to perform four risk projection steps: - Establish a scale that reflects the perceived likelihood of a risk. - Delineate the consequences of the risk. - Estimate the impact of the risk on the project and the product. - Assess the overall accuracy of the risk projection so that there will be no misunderstandings.

Generic risks

are a potential threat to every software project.

Predictable risks

are extrapolated from past project experience (e.g., staff turnover, poor communication with the customer, dilution of staff effort as ongoing maintenance requests are serviced).

Software safety and hazard analysis

are soft-ware quality assurance activities that focus on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail. If hazards can be identified early in the software engineer- ing process, software design features can be specified that will either eliminate or control potential hazards.

Unpredictable risks

are the joker in the deck. They can and do occur, but they are extremely difficult to identify in advance.

Known risks

are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date, lack of documented requirements or software scope, poor development environment).

Program evaluation and review technique (PERT) and the critical path method (CPM)

are two project scheduling methods that can be applied to software development. Both techniques are driven by information already developed in earlier project planning activities: estimates of effort, a decomposition of the product function, the selection of the appropriate process model and task set, and decomposition of the tasks that are selected. Both PERT and CPM provide quantitative tools that allow you to: (1) determine the critical path—the chain of tasks that determines the duration of the project, (2) establish "most likely" time estimates for individual tasks by applying statistical models, and (3) calculate "boundary times" that define a time "window" for a particular task.

Product-specific risks

can be identified only by those with a clear under- standing of the technology, the people, and the environment that is specific to the software that is to be built.

the inherent properties of this irreducible essence of modern software systems:

complexity, conformity, changeability, invisibility

Earned Value Analysis (EVA)

consists of comparing the following metrics at regular intervals during the project: budget to date, actual spending to date, estimate to complete and estimate at completion

risk mitigation, monitoring, and management (RMMM) plan

documents all work performed as part of risk analysis and is used by the project manager as part of the overall project plan.

Risk Mitigation

is a problem avoidance activity.

expert system

is a program that contains a generalized inference engine and a rule base, takes input data and assumptions, explores the inferences derivable from the rule base, yields conclusions, and advice, and offers to explain its results by retracing its reasoning for the user. The inference engines typically can deal with fuzzy or probabilistic data and rules, in addition to purely deterministic logic.

Software project scheduling

is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks.

Risk

is not limited to the software project itself. It can occur after the software has been successfully developed and delivered to the customer. These are typically associated with the consequences of software failure in the field.

prototype software system

is one that simulates the important interfaces and performs the main functions of the intended system, while not necessarily being bound by the same hardware speed, size, or cost constraints.

actual cost of work performed (ACWP)

is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. It is then possible to compute

Three factors affect the consequences that are likely if a risk does occur:

its nature, its scope, and its timing.

An abstract program consists of conceptual constructs:

operations, data types, sequences, and communication.

The Putnam-Norden-Rayleigh (PNR) Curve

provides an indication of the relationship between effort applied and delivery time for a software project. E_a = effort in person-months t_d = nominal delivery time for schedule t_o = optimal development time (in terms of cost) t_a = actual delivery time desired

An effective strategy must consider three issues:

risk avoidance, risk monitoring, and risk management and contingency planning.

*PRODUCT* Problem Decomposition

sometimes called partitioning or problem elaboration, is an activity that sits at the core of software requirements analysis. The process of breaking down a complex problem into smaller, more manageable problems. Two major areas: (1) the functionality and content (information) that must be delivered (2) the process that will be used to deliver it.

Project risks

threaten the project plan and identify potential budgetary, schedule, personnel (staffing and organization), resource, stakeholder, and requirements problems and their impact on a software project.

Technical risks

threaten the quality and timeliness of the software to be produced and identify potential design, implementation, interface, verification, and maintenance problems.

Business risks

threaten the viability of the software to be built and often jeopardize the project or the product. Candidates for the top five business risks are (1) building an excellent product or system that no one really wants (market risk), (2) building a product that no longer fits into the overall business strategy for the company (strategic risk), (3) building a product that the sales force doesn't understand how to sell (sales risk), (4) losing the support of senior management due to a change in focus or a change in people (management risk), and (5) losing budgetary or personnel commitment (budget risks).

All of the technological attacks on the accidents of the software process are fundamentally limited by the productivity equation:

time_of_task = Sum_t (frequency)_i x (time)_i

Technical milestone: OO analysis completed

• All classes and the class hierarchy have been defined and reviewed. • Class attributes and operations associated with a class have been defined and reviewed. • Class relationships have been established and reviewed. • A behavioral model has been created and reviewed. • Reusable classes have been noted.

Technical milestone: OO programming completed

• Each new class has been implemented in code from the design model. • Extracted classes (from a reuse library) have been implemented. • Prototype or increment has been built.

To mitigate this risk, you would develop a strategy for reducing turnover. Among the possible steps to be taken are:

• Meet with current staff to determine causes for turnover (e.g., poor work- ing conditions, low pay, competitive job market). • Mitigate those causes that are under your control before the project starts. • Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave. • Organize project teams so that information about each development activity is widely dispersed. • Define work product standards and establish mechanisms to be sure that all models and documents are developed in a timely manner. • Conduct peer reviews of all work (so that more than one person is "up to speed"). • Assign a backup staff member for every critical technologist.

Technical milestone: OO testing

• The correctness and completeness of OO analysis and design models have been reviewed. • A class-responsibility-collaboration network has been developed and reviewed. • Test cases are designed, and class-level tests have been conducted for each class. • Test cases are designed, and cluster testing is completed and the classes are integrated. • System-level tests have been completed.

Technical milestone: OO design completed

• The set of subsystems has been defined and reviewed. • Classes are allocated to subsystems and reviewed. • Task allocation has been established and reviewed. • Responsibilities and collaborations have been identified. • Attributes and operations have been designed and reviewed. • The communication model has been created and reviewed.

Polya's Second Principle:

Devise a plan: A partial list of strategies is included: - Guess and check - Make an orderly list - Eliminate possibilities - Use symmetry - Consider special cases - Use direct reasoning - Solve an equation - Look for a pattern - Draw a picture - Solve a simpler problem - Use a model - Work backwards - Use a formula - Be ingenious

Rearranging this software equation, we can arrive at an expression for development effort E:

E = L^3/(P^3t^4) where E is the effort expended (in person-years) over the entire life cycle for software development and maintenance and t is the development time in years. The equation for development effort can be related to development cost by the inclusion of a burdened labor rate factor ($/person-year).

40-20-40 Rule

Forty percent of all effort is allocated to front-end analysis and design. A similar percentage is applied to back-end testing. You can correctly infer that coding (20 percent of effort) is deemphasized. Testing and subsequent debugging can account for 30 to 40 percent of software development effort.

Past Breakthroughs Solved Accidental Difficulties three steps in software technology development

High-level languages. Time-sharing Unified programming environments

work breakdown structure (WBS)

Interdependencies among tasks may be defined using a task network. It defined for the product as a whole or for individual functions.

time-line chart, also called a Gantt chart

It depicts a part of a software project schedule that emphasizes the concept scoping task for a word-processing (WP) software product. All project tasks (for concept scoping) are listed in the left-hand column. The horizontal bars indicate the duration of each task. When multiple bars occur at the same time on the calendar, task con- currency is implied. The diamonds indicate milestones.

Schedule Performance Index (SPI)

It is an indication of the efficiency with which the project is utilizing scheduled resources. An SPI value close to 1.0 indicates the efficient execution of the project schedule. A measure of schedule efficiency expressed as the ratio of earned value to planned value. SPI = BCWP/BCWS

Schedule Variance (SV)

It is simply an absolute indication of variance from the planned schedule. A measure of schedule performance expressed as the difference between the earned value and the planned value. SV = BCWP - BCWS

A risk table

It provides you with a simple technique for risk projection and can be implemented as a spreadsheet model. This enables easy manipulation and sorting of the entries.

L, is related to effort and development time by the equation:

L = P x E^(1/3)t^(4/3) where E is a development effort in person-months, P is a productivity parameter that reflects a variety of factors that leads to high-quality software engineering work and t is the project duration in calendar months.

Polya's Fourth Principle:

Look Back By taking the time to reflect and look back at what you have done, what worked, and what didn't. Doing this will enable you to predict what strategy to use to solve future problems.