the process infsy 570 dr. r. ocker. chapter 2 (pressman, 1997) and readings (boehm88, alavi84,...

67
The Process Infsy 570 Dr. R. Ocker

Upload: christine-hopkins

Post on 04-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

The Process

Infsy 570

Dr. R. Ocker

Page 2: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88)

Page 3: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

The Process

software process – framework for the tasks that are required to

build high-quality software

Quality - basic notion behind SWE

Page 4: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

some SWE definitions the establishment and use of sound

engineering principles in order to obtain economically software that is reliable and works efficiently on real machines

(1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

(2) the study of approaches used in (1).

Page 5: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Process, Methods, and Tools

Page 6: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

SWE Process

glue that holds everything together; supposed to enable rational and timely development of SW

process defines the framework that must be followed for sw delivery

used for management control establish the context in which

technical methods are applied, etc.

Page 7: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

SWE Methods

provide the technical how to’s for building sw;

methods encompass tasks, including: requirements analysis design program construction testing maintenance

Page 8: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

SWE Tools

provide automated support for the process and methods

CASE - when tools are integrated so that information created by one tool can e used by another

Page 9: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Generic view of SWE

engineering is the analysis, design, construction, verification, and management of technical entities.

Page 10: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

3 generic phases of SWE:

definition development maintenance

Page 11: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

1. definition phase - focus on what what information is to be processed what function and performance are

desired what system behavior can be expected what interfaces are needed what design constraints exist what validation criteria are required to

define a successful system

Page 12: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

3 tasks occur

1. system or information engineering 2. software project planning 3. requirements analysis

Page 13: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

2. development phase - focus on how how data are to be structured how function is to be implemented how interfaces are to be characterized how design will be translated into

programming languages how testing will be performed

Page 14: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

3 specific technical tasks always occur 1. software design 2. code generation 3. software testing

Page 15: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

3. maintenance phase - focus on change error correction adaptations required as SW evolves changes due to enhancements brought

about by changing customer requirements

Page 16: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Umbrella activities

applied throughout the sw process; include:– project tracking and control– formal technical reviews– quality assurance– configuration management– document preparation and production– measurement– risk management

Page 17: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

SW Process

emphasis on process maturity

Software Engineering Institute (SEI) developed comprehensive model based upon a set of SWE capabilities that should be present as organizations reach different levels of process maturity

Page 18: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

capability maturity model

defines key activities required at different levels of process maturity

5 process maturity levels

Page 19: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

level 1 - initial

sw process is ad hoc, maybe even chaotic

few processes are defined success depends on individual effort

Page 20: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

level 2 - repeatable

basic project management processes are established to track cost, schedule, and functionality

Necessary process discipline is in place to repeat earlier successes on projects with similar applications

Page 21: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

level 3 - defined

sw process for both management and engineering activities is documented, standardized, and integrated into an organization-wide sw process

all projects use a documented and approved version the this for developing and maintaining sw

Page 22: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

level 4 - managed

detailed measures of sw process and product quality are collected

both sw process and products are quantitatively understood and controlled using detailed measures

Page 23: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

level 5 - optimizing

continuos process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies.

Page 24: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Software Process Models Process models differ from a sw

method/methodology method’s primary focus is on:

– how to navigate through each phase• e.g. partitioning functions

– how to represent the products of each phase• e.g. structure charts

software process models specify the order in which a project should carry out its major tasks

Page 25: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

We will look at:

code-and-fix model linear sequential model (life cycle) prototyping model human factors approach*** RAD model Evolutionary process models (iterative)

– incremental model– Spiral model*****

Page 26: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

A. Code-and-Fix Model (2 steps) 1. Write some code 2. Fix the problem in the code

earliest process model problems: spaghetti code, lack of

planning, difficult to maintain over time, no requirements phase

Page 27: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

B. Linear Sequential/ Stagewise/Life

Cycle and Waterfall Models (fig. 1, Boehm88) software developed in successive stages

(linear sequential) Waterfall - added feedback loops between

stages followed code-and-fix model traditional approach to development not iterative but sequential stages deliverables and milestones at each stage

Page 28: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

basic stages:

analysis design coding testing maintenance

Page 29: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Advantages:

designed for control complete system delivered after linear

sequence completed

Page 30: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Disadvantages:

emphasis on document driven standards (e.g. fully elaborated documents as completion criteria for early requirements and design phases);

can result in elaborate specs. of poorly understood user interfaces followed by design and development of large quantities of unusable code

Page 31: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

C. Prototyping Model

designed to help understand requirements

build an experimental system rapidly and inexpensively for users to evaluate

Page 32: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

2 types of prototypes:

1. evolutionary prototype evolves into working system 2. throw away after prototype completed and requirements

determined, it is “thrown away” software developed beginning with design

stage

Page 33: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

iterative process of development (fig. 1 Alavi84) 1. identify initial user requirements 2. develop prototype 3. use & evaluate prototype 4. revise prototype (back to 3)

Page 34: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

prototyping

prototyping much more iterative than SDLC

promotes design changes

less formal approach than SDLC quickly generate working model of

system

Page 35: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Advantages of prototyping:

useful when uncertainty about information requirements or design solutions

good for design of user interface encourages user involvement

throughout development

Page 36: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Disadvantages:

no detailed specifications - should not substitute for careful requirements analysis

better suited for smaller applications more difficult to control than SDLC - must

plan the effort in advance to control for cost, effort, and time limits

be prepared for more changes than in SDLC

Page 37: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

D. Human Factors (Mantei & Teory, 1988)

incorporates changes into prototyping process model based on human factors engineering

Page 38: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

prototyping lifecycle (fig. 1) fits prototyping into linear sequential (life cycle)

process model– feasibility study– requirements definition– global design– prototype construction– user evaluation– system implementation– testing– update and maintenance

Page 39: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

fig. 2 add human factors to life cycle

market analysis feasibility study requirements definition product acceptance analysis task analysis global design prototype construction

Page 40: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

fig. 2 (cont.) add human factors to life cycle

user testing and evaluation user evaluation system implementation product testing user testing update and maintenance product survey

Page 41: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Human Factors aspects:

MARKET ANALYSIS (iterative) * - Run “focus groups” with users to determine their perceptions and needs

PRODUCT ACCEPTANCE ANALYSIS * - Prepare a system “mockup” for presentation to a sample of users (changes can be recommended at this point). These changes result in a loop back to the requirements definition stage.

Page 42: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Human Factors aspects:

TASK ANALYSIS * - Examines the users’ mental process relative to the procedures currently being used. The results are employed in the global design and prototype construction stages in “tuning” the user interface to reflect their thought process.

Page 43: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Human Factors aspects:

USER TESTING AND EVALUATION * - finished prototype presented to sample of users for testing (ease of use, functionality and performance).

Resultant design changes require looping back through the global design and prototype construction stages.

Major system failings call for revisiting the requirements definition stage.

Page 44: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Human Factors aspects:

USER TESTING * - Upon completion of “user testing and evaluation”, the system is implemented and undergoes traditional product testing (unit and system) by the developers. The system is now subjected to a second round of USER testing.

Page 45: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Human Factors aspects:

PRODUCT SURVEY * -obtain more user feedback

This stage is tied to the ongoing update and maintenance process.– Small changes handled by looping back to

requirements determination stage.– significant revisions may require going all the

way back to “market analysis”, for a complete re-evaluation.

Page 46: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Other Considerations:

Cost effectiveness increases with the number of users

Savings from running user studies also rise with user population

Rule of thumb - use a prototype when the cost is less than 25% of the total project cost

Human factors model not recommended for small/simple projects, better suited to large user base or complex systems

Page 47: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Good example...

NOTE: This article provides a great example of applying numbers (benefits and costs) to SWE.

Page 48: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

E. RAD Model linear sequential process emphasizes very short development cycle (60-

90 days) use when requirements are well-understood

and project is scaleable (able to break into concurrent pieces)

each major function developed by a separate RAD team

emphasizes reuse

Page 49: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

RAD phases:

1. business modeling look at information flow among business

processes 2. data modeling data objects to support the business 3. process modeling create process descriptions to support

business functions

Page 50: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

RAD phases:

4. application generation 4th generation languages, reuse

existing programs 5. testing & turnover test new components only

Page 51: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

F. Evolutionary Process Model stages consist of expanding increments

of an operational software product (iterative development)

1. Incremental model 2. Spiral model

Page 52: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

1. Incremental Model

turns linear sequential approach (analysis, design, code, test) into iterative approach

system broken down into series of pieces or iterations

stagger sequences over time each linear sequence produces a

deliverable increment of the system

Page 53: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

1. Incremental Model

first increment = core system; covers basic reqs.

good to use when staffing not adequate to deliver complete system

also use increments to manage risk

Page 54: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Advantages:

matched to fourth generation languages application

good fit when users say, “I can’t tell you what I want, but I’ll know it when I see it”

Page 55: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Disadvantages:

difficult to distinguish from the old code-and-fix model (spaghetti code, lack of planning);

assumes that system can accommodate uplanned evolution plans

Page 56: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

2. Spiral Model (figure 2, Boehm88) sw developed in series of incremental

releases

model uses concept that each cycle involves a progression that addresses the same sequence of steps, from an overall concept of operation document to the coding of each individual program.

Page 57: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Typical Spiral Cycle:

Determine objectives, alternatives, constraints– determine objectives for portion of product

being elaborated– identify alternatives to implement it– identify constraints imposed on alternatives

Page 58: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Typical Spiral Cycle:

Evaluate alternative, identify, resolve risks evaluate alternatives relative to objectives

and constraints identify uncertainties that are significant

sources of project risk formulate strategy to resolve risks (may

involve prototyping, simulation, benchmarking, user surveys, etc.)

Page 59: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Typical Spiral Cycle:

Develop, verify next-level product e.g. generate sw requirements and

perform requirements validation

Plan next phases e.g. development plan; integration and

test plan

Page 60: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Spiral Model Template

Each round of the spiral model addresses the following:– Objective

– Constraints

– Alternatives

– Risks

– Risk Resolution

– Risk Resolution Results

– Plan for Next Phase

– Commitment

Page 61: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Evaluation:

Primary Advantage of Spiral Model: its range of options accommodates the

good features of existing software process models, while its risk-driven approach avoids many of their difficulties

Page 62: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Other Advantages: it focuses early attention on options involving the reuse of existing

software it accommodates preparation for life-cycle evolution, growth, and

changes of the software product it provides a mechanism for incorporating software quality

objectives into software product development it focuses on eliminating errors and unattractive alternatives early it answers the question “How much is enough?” it doesn’t involve separate approaches for software development

and software enhancement it provides a viable framework for integrated hardware-software

system development

Page 63: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Other Advantages:

focuses on early elimination of errors answers the question “How much is

enough?” doesn’t involve separate approaches for

software development and software enhancement

provides a viable framework for integrated hardware-software system development

Page 64: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Difficulties:

matching to contract software relying on risk-assessment expertise need for further elaboration of spiral

model steps

Page 65: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Risk Management Plan

one characteristic of spiral approach that can be adapted to life-cycle models

ensures that each project makes an early identification of top risk items and develops a strategy for resolving risks

Page 66: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Unit Review:Process Model Comparison Create a chart describing all of the

above process models (including both evolutionary models).

Page 67: The Process Infsy 570 Dr. R. Ocker. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88 )

Unit Review:Process Model Comparison On this chart, complete the following

categories:– basic description of process– steps in process– unique features of process– advantages of using process– disadvantages of using process– when to use process