Chart 2-1 Copyright © 2004 by R. Fairley CSE 516 Summer, 2004 CSE 516 (formerly known as CSE 500)...

chart 2-1Copyright © 2004

by R. FairleyCSE 516Summer, 2004

CSE 516(formerly known as CSE 500)

Introduction to Software Engineering

SESSION 2: People, Processes, and Technology

developed byRichard E. Fairley, Ph.D.

Professor and Director of Software EngineeringOregon Graduate Institute

[email protected]

Modified and presented bySanjeev Qazi ([email protected])



SESSION 2 OVERVIEW

• Some People Issues

• Some Technology Factors

• Some Process Models

• A Homework Assignment



SUCCESS FACTORS FOR SOFTWARE ENGINEERING

• Three key factors in software engineering

– people: numbers and skills– process: the way of working– technology: platform and domain

• Good processes allow people to apply technology

– efficiently: without wasting time or effort, and – effectively: to achieve a desired result



PEOPLE ISSUES IN SOFTWARE ENGINEERING

• Software is produced by individuals and teams of individuals working in a closely coordinated manner

– the work is “intellect-intensive”

• Software is always part of a larger system

– software engineers must work with other people:

• other team members

• other software groups

• hardware groups

• marketing groups

• customers and users

• contract administrators

• human resource people



A “People Issues” Text

• The textbook:

Peopleware, 2nd. Ed. by DeMarco and Lister, published by Dorset House, ISBN 0-932633-43-9

provides a good discussion of people issues in software engineering



PEOPLE ISSUES - II

• Software is made by individuals and teams of individuals

• Individual success requires ability, skill, and motivation

• A team is a group of individuals working in a cooperative manner toward common shared goals

• Team success requires that:

– team members have a shared vision

– team members have shared work products

– team members be willing to help one another

a group of people working togetheris not necessarily a team



PEOPLE ISSUES - III

• Productivity of individuals in software development varies by factors of 10:1 and more

• Productivity of groups varies by factors of 10:1 and more (not all groups are teams)

• Individual productivity is a matter of:– skill and experience: ability to do the job– motivation: willingness to do the job

• Team productivity is a matter of individual productivity plus the synergy of group dynamics.



Can’t vs Won’t

• Can’t occurs when:– a person is willing but unable

• Won’t occurs when:– a person is able but unwilling

• Can’t and won’t occur when:– a person is unable and unwilling

• Can and will occur when:– a person is able and willing

success in software engineering requires individuals and teams who are willing and able



Factors That Contribute to Efficient and Effective Software Engineering Teams

• Appropriate number of people• Correct skill mixture• Good tools• Adequate training• Respect for one another• Respect for leaders and managers• Shared ownership of the results• Good communication skills• Good communication channels• Willingness to be team members• Fair treatment of each person• Good working environment• Having some fun together



Team Building Techniques

• Allow people to work together for extended periods of time

• Conduct off-site planning and review meetings– with some opportunities for socializing

• Allow team participation in off-site training courses

• Provide corporate-sponsored recreational activities

• Find isolated tasks for “lone wolf” contributors

• Reassign disruptive and unsocial people– remember the 80/20 rule (the 95/5 rule?):

don’t spend 95% of your time with the 5% of people who can’t and/or won’t and who will never change



Communication Channels

• The number of communication paths among n workers is n(n-1)/2:– 4 workers have 6 communication channels – 5 workers have 10 communication channels– 10 workers have 45 communication channels– 20 workers have 190 communication channels

• Most people can effectively maintain a fully communicative working relationship with at most 4 or 5 other people– 7 2 is the generally accepted limit of short-term,

working memory

• A hierarchical tree structure provides the minimum number of links needed to construct a connected graph



An Organizational Model for Software Projects

Project Manager

TeamLeader #1

Team Leader#2

TeamLeader #3

V&V CM

Member Member Member Member

Software Architect

. . .

Customer

XX

hierarchical structures can grow or shrink as necessary



The Team Leader’s Role

The team leader:

• Oversees personal and team processes

• Oversees personal and team product quality

• Mentors and coaches team members

• Maintains team morale, energy, and drive

• Keeps management informed

• Interfaces with other teams and groups

• Resolves problems and issues within his or her control

• Elevates problems and issues beyond his or her control

The team leader is responsible for the quantity and quality of team output



A QUESTION

Which is more productive?

1. A team consisting of 3 to 6 software developers, in which one person spends part of his time coordinating the work of the other team members?

Or

2. A “team” consisting of 3 to 6 software developers, where each developer “does their own thing?”



The Project Manager

• The project manager is responsible for delivering a satisfactory product on time and within budget by:

– planning and estimating

– measuring and controlling

– leading and directing

– communicating and coordinating

– This is where the “buck” usually stops.



The Software Architect

• The software architect

– develops the system architecture and – maintains the vision and integrity of the system by:

• developing technical options, • presenting them to the decision makers, and • overseeing the technical activities, • ensuring that the product/project satisfies the project

constraints



Roles for The Software Architect

• The software architect is:

– member of system design team

– leader of software analysis and design team

– leader of implementation team leads

– keeper of the product vision

– spokesperson for the software team

– technical coordinator with other design teams, and possibly other organizations

– responsible for completeness, consistency, and correctness of the software product

A Chief Architect may be responsible for a product family or product line within an organization



Roles vs Role Players

• On a small project (about 5 or fewer people), the project manager, software architect, and team leader roles may be played by one individual

– which means he/she is “wearing different hats”

• On a large project (20 or more people), the project manager and software architect may be assisted by others

– and there would typically be multiple team leaders



A Three-Way Contractual Model

• Customer agrees to not request changes to the requirements without re-negotiating with the project manager and software architect

• Project manager agrees to provide the resources needed to implement the product requirements and to measure and report schedule, budget, progress, quality, and risk factors

• Software architect agrees to develop (or modify) a product that satisfies the product requirements using the resources provided by the project manager



Some Examples of Re-Negotiating the Contract

• Marketing (customer) requests changes in the light of a competitor’s new product– must renegotiate resources, schedule, and product

features with the project manager and software architect

• Software architect hits a technical snag and cannot deliver the product on schedule– must renegotiate with marketing and project manager

• Project manager cannot provide promised resources because of a hiring freeze– must renegotiate with marketing and software architect



Theory of Triple Constraint

• What “Triple Constraint” says is that for any project, there are three variables that need to be balanced. These are:

– Time (or schedule): • How much time is available for your group to deliver on the

work assigned?

– Cost/Budget (or resources):• What is the cost of the project?

– This can include manpower cost (usually the highest), software licenses, hardware, etc.

– Quality (or features):• What are the quality requirements (based on some metric)

and/or feature requirements for the product?



SESSION 2 OVERVIEW

• Some People Issues=> Some Technology Factors• Some Process Models• A Homework Assignment



TECHNOLOGY

• Software engineering tools are hardware and software that help us build other software

• Technology provides the tools to do the job– work stations– target processors– host and target operating systems– compilers, linkers, loaders– local area networks– requirements engineering tools– design tools– debugging and testing tools– programming environments – configuration management tools– project management tools– e-mail, word processors, spreadsheets

software engineers are tool builders



PEOPLE, PROCESS, AND TECHNOLOGY

• Process is the way in which people, working in teams, apply technology to build high quality products - efficiently and effectively

People Process Technology

Capability

Product



What Is a Software Process?

• A process – is a way of doing something– includes work activities– includes procedures for conducting the work activities

• The work activities transform input work products into output work products

• The procedures are supported by methods and tools; for example:

DesignProcess

Requirements Design DocumentsTest Plans

methodsand tools



The Nature of Software Processes

• A process is typically part of a larger process– the design process is part of the development process

• A process may have sub-processes– the design process includes a design review process

• A process has entry and exit criteria– we must have some requirements before we design; we must have a

design review before we complete the design

• A process includes procedures for conducting the work activities; for example:

RepairProcess

Problem Report Repaired Code

Updated Work Products

methodsand tools



An Example-- The Defect Repair Process --

Fixing a customer-reported defect involves the following procedures:

1. reproducing the failure (absolutely need this)2. finding the defect3. fixing the mistake4. regression testing5. documenting the fix6. updating other work products7. checking-in the modified code8. releasing the product with the fix.9. closing the problem report.

QA will typically verify that this bug has been fixed. Customer certainly will :=)

note: fixing a user-reported defect also involves a Configuration Management process



THE NATURE OF ENGINEERING PROCESSES

• An engineering process is a way of accomplishing some engineering activity

• Key aspects of an engineering process include:

– Process Definition: what is the process?

– Process Enactment: how is it done?

– Process Measurement: how well is it done?

– Process Assurance: is it done correctly?

– Process Improvement: how can it be done better?



A Process Model for Developing Software-Intensive Systems

DefineOperationalRequirements

SpecifySystemRequirements

DevelopSystemArchitecture

ObtainSoftwareComponents

IntegrateSoftwareComponents

systemvalidation

systemvalidation

User NeedsAcquirer Expectations

User NeedsAcquirer Expectations

softwarevalidation

softwarevalidation

IntegrateTotalSystem

Allocate theSoftwareRequirements

DevelopSoftwareDesign

Allocate theHardwareRequirements

Allocate thePeopleRequirements

add othercomponents



Obtaining the Software Components

• Software components can be obtained by:

– designing and building in-house

– contracting with a third party supplier

– buying components from a vendor

– reusing components from another system• With or without modification

– using components provided by another group• With or without modification

Each of these approaches requires a different process;several approaches may be used on one project



Support Functions for Software Development

• Supporting functions for software development and modification include:

– configuration management• change control; version control

– verification and validation• checking completeness, consistency, and correctness of work products

– quality assurance• assuring the quality of both process and product

– documentation support• developing user and customer materials

– training• developer training; user training

Each supporting function must be accomplished using a well-defined process



customer

management

Planning and Replanning

ActivityDefinition

WorkAssign-ments

SoftwareDevelopment

Quality Assurance

Independent Validation

Measuring

Controlling

DataRetention

Estimating

ReportingStatus ReportsProject Reports

Requirementsand Constraints

Directives andConstraints

Change Requests and Problem Reports

ConfigurationManagement

product

. . . . . . . . . . . . .. . . .

Process Models for Software Development



Some FOUNDATION ELEMENTS of a Software Development Process

• coding style guidelines

• code documentation guidelines

• debugging tools

• peer reviews

• testing strategies, procedures, and tools

• periodic backups

• a version control system (SCM)

• a defect tracking system

• a design documentation tool

• a project planning and tracking system



Some Process Models for Software Development

Model Emphasis

Hacking Writing Programs

Waterfall Project Phases

Incremental Staged Development

Evolutionary Exploratory Development

Spiral Risk Management

Cleanroom Rigorous Process

Component-based Savings and Quality

Frameworks Tailoring and Adaptation



Hacking

• To hack means to start writing the programs without any system engineering, requirements analysis, software design, or test planning

• Hacking focuses attention on implementation details before

– understanding the problem (analysis)– developing a solution (design)– determining success criteria (objectives)

• A hacker is one who hacks

development of a complex system requiresmultiple descriptions at different levels of abstraction



Descriptions: The Work Products of Software Engineering

• The work products of software engineering include:

– operational requirements: user needs– technical specifications: developer’s guidance– design documents: structure and interfaces– test plans: product validation– source code: implementation– project plans: project roadmaps– status reports: visibility– reference manual: product dictionary– on-line help: user guidance– installation instructions: operators’ guidance– release notes: know issues; hints– maintenance guide: maintainers’ guidance



The Waterfall ModelUser Needs

System Requirements

Software Requirements

Software Design

Implementation

Software Test

System Test

Verification:are we buildingthe system correctly?

Acceptance Test

Validation:did we buildthe correct system?



Advantages of the Waterfall Approach

• Compared to Hacking, the Waterfall Model requires us to:

– develop requirements before design

– design before writing programs

– test programs after integrating them

– have milestone reviews

– establish and control work product baselines



Milestone Reviews in the Waterfall Model

User Needs

System Requirements

Software Requirements

Software Design

Implementation

Software Test

System Test

Verification:are we buildingthe system correctly?

Acceptance Test

Validation:did we buildthe correct system?

SRR

SSR

PDRCDR

TRR

STR

SAR

CAR

SRR: System Requirements ReviewSSR: Software Specification ReviewPDR: Preliminary Design ReviewCDR: Critical Design ReviewTRR: Test Readiness ReviewSTR: Software Test ReviewSAR: System Acceptance ReviewCAR: Customer Acceptance Review



Baselines and Version Control

• A baseline is a work product that has been accepted by the involved parties and placed under version control– acceptance requires application of some acceptance

criteria

• A baseline cannot be changed without the agreement of the involved parties

• A baseline is changed because:1. the requirements for the work product changed, or2. a defect was found in the work product

baselines and version control are fundamentaltechniques of software engineering; they

are elements of Configuration Management



The Waterfall Approach

• The Waterfall Model requires that we (attempt to):

– specify the requirements completely, consistently, correctly, and unambiguously on the first attempt

– design the system completely and correctly on the first attempt

– write all of the program interfaces and internal details correctly on the first attempt

– integrate the components in one large step

– do system testing at the end

the waterfall model is a one-pass process



Some Realities of Software Development

1. Requirements always change because of:

– changing customer desires and user needs– initial requirements analysis inadequate– understandings and insights gained through experience – changing technology– changing competitive situation– personnel turnover: engineering, management, marketing,

customer

2. The design is never right the first time– design is a creative, problem solving process

3. Frequent demonstrations of progress and early warning of problems are desirable

An iterative development model is best



Iterative Development

• Iteration is the process by which the desired result is approached through repeated cycles

• In software engineering, an iterative approach allows revision of and addition to the work products

• Different types of iterative models support revision of:– requirements– design– code

iteration should be planned;not done as an afterthought



Iterative Development - II

• The goals of iterative development are:

– frequent demonstrations of progress– early warning of problems– ability to incorporate changes

• Three types of iterative development models

1. incremental2. evolutionary3. spiral models



The Incremental Implementation Process

IncrementalValidation

RequirementsSpecifications

DesignPartitioning

ArchitecturalDesign

IncrementalBuilds*

IncrementalVerification

OperationalRequirements

*build includes detailed design,implementation, review, and test



The Incremental Implementation Approach

• Design is partitioned into a series of prioritized builds

– each build adds capabilities to the existing base in priority order

• builds produce demonstrable versions

– most critical parts are built first• and tested/demonstrated most often

– All incremental builds are not necessarily customer builds.



Incremental Building and Validating

AddFeature Set N

• • •• • • • • •

AddFeature Set 2

BuildFeature Set 1

Time

ValidateFeature Set FS1

ValidateFeature Sets

1 + 2

• • •• • • • • •Goal:

Rework < 20% oftotal effort

Deliver Version 1.0

Validateall Features

DesignPartitioning

Demo FS1

Demo 1+2

(Rqmts & Design)

...



An Incremental ExampleBuilding A Compiler

• Version 0.1: input reader

• Version 0.2: plus lexical analyzer

• Version 0.3: plus symbol table

• Version 0.4: plus code generator

• Version 0.5: plus linker table

• Version 0.6: plus writer

• Version 0.7: plus error messages

• Version 0.8: plus optimizer

Version 0.8 is customer Version 1.0



Milestone Chart for a Six Month Incremental Project

V0.1V0.2

V0.3V0.4

V0.5V0.6

V0.7V0.8

2 Months

Design Implementation*

4 Months

Demo1Demo2

Demo3Demo4

Demo5Demo6

Demo7

Demo &Deliver V1.0

Note: bi-weekly demonstrationmilestones

a project milestone is a point in timewhere progress is assessed

Design MilestoneRequirements Milestone

Rqmts



Design Partitioning

• Partitioning criteria for the incremental versions must be established;

– for example:• foundation elements

– elements needed to support other elements• prioritized user needs

– must-have features first– nice-to-have features next

• a safety-critical system– safety features first– other features next

• a user-intensive system– user interface features first– other features next

• an operating system– kernel operations first– utility operations next



Guidelines for Incremental Development

• Build an “official” demonstration version every week/month– developers may do more frequent builds

• Build product versions according to priority of requirements– build and test the most critical parts first

• Do independent review and testing of each version

• Incorporate requirements changes into later versions

• Redesign if changes to previous builds exceed 20% of effort when building two successive product versions



Advantages of Incremental Development

• Allows early and continuing demonstrations of progress

• Components built first are tested most

• Can incorporate some changes to requirements in later builds

• Can make trade-offs of features and schedule– during development– at delivery time

• Can provide incremental deliveries to customers– during development– at delivery time



Incremental Delivery

• Deliver of early versions provides early feedback from users

• Allows product delivery on schedule– with most important features working– with systematic planning for later versions

• At delivery time, it is better to be

– 100% complete with 80% of the most important product features

than to be

– 80% complete with 100% of features (and nothing to deliver)



The Evolutionary Model

• Used when a first version of the requirements cannot be (mostly) specified in advance:

Cycle 1 Cycle 2 Cycle 3 Cycle n. . .

Analyze Design Implement Test Evaluate=> => => =>

• Details of each cycle:

Each Cycle is<= 1 Month Duration



Evolutionary Development Guidelines

• Used when requirements cannot be mostly specified in advance

• Evolutionary cycles end when– project is cancelled because it is infeasible– project is converted to an incremental approach– product is delivered

• Using the evolutionary approach indicates a high-risk project



The Spiral Approach

• The Spiral Process is a nested set of iterative development models– earlier activities are revisited, revised, and refined on each pass of

the spiral

• Each cycle of a spiral model involves four steps:

Step 1 - determine objectives, alternatives, and constraintsStep 2 - identify risks for each alternative, choose one of the alternativesStep 3 - implement the chosen alternativeStep 4 - evaluate results and plan for the next cycle of the spiral

• The cycles continue until the desired objectives are achieved



time

xx

xxx

x

x

x

An Evolutionary Spiral Model

x

x

xxx

x

x

x

x

x

x

x

x

x

xx

x

x

x

x

x

x

x

xx

x

x

x

x

x

xxx

xxx

x

x

x

xx

x

xx

x

xx

xx

x

ANALYZE:Determineobjectives,alternatives,and constraints

DESIGN:evaluate alternatives,Identify risks of eachalternative &choose one

DEVELOP:Implement and test the chosen alternative

EVALUATE:examine resultsand decide whatto do next

x

x

Each Cycle is One Month or Less



time

xx

xxx

x

x

x

An Incremental Build Spiral Model

x

x

xxx

x

x

x

x

x

x

x

x

x

xx

x

x

x

x

x

x

x

xx

x

x

x

x

x

xxx

xxx

x

x

x

xx

x

xx

x

xx

xx

x

DETAILED DESIGN:Select algorithmsand data structures;specify interfacedetails

IMPLEMENTATION:implement, document,review, test the build

VALIDATION:Integrate the buildinto the base systemand test the combination

EVALUATION:examine resultsand decide whatto do next

x

x

Each Cycle is One Week or Less



Some Spiral Models for System Development - I





Integrate &Test SoftwareComponents

systemvalidation

User NeedsCustomer Expectations

softwarevalidation

Integrate& TestSystem

Allocate SoftwareRequirements Develop

SoftwareDesign



operationalvalidation

starthere

endhere

IncrementalImplementationSpiral

add othercomponents



A Nested Set of Spiral Models








SoftwareDesign




starthere


endhere

add othercomponents



Some Comments

• Moving from an inner level to an outward level of the Spiral Model indicates project instability

• Moving from an outer level to an inward level of the Spiral Model indicates growing project stability

• Incremental and evolutionary development can be thought of as instances of the spiral approach

• How do we proceed when none of the product factors are stable or partitionable?– conduct a feasibility study using prototyping



The Role of Prototyping

• Prototyping involves building a “mock-up” of some part of a system

• Prototyping is typically used to– build a mock-up of the user interface, or– write a program to study a technical issue

• Prototyping is a technique, not a process model– prototyping does not eliminate the need for requirements

analysis, design, test planning, integration, system testing, and documentation activities

Prototyping is a technique that must be planned and controlled; it should not be an excuse for hacking



A Spiral Model of Prototyping to Elicit User Requirements




ObtainSoftwareComponents**

IntegrateSoftwareComponents**

systemvalidation


Acquirer Conditions

softwarevalidation

REQUIREMENTS ENGINEERING

IntegrateTotalSystem**

AllocateSoftwareRequirements

Develop**SoftwareDesign

** must maintain user and acquirer involvement

AllocateHardwareRequirementsAllocatePeopleRequirements



Managing Prototyping Efforts

• Prototyping must not be used as an excuse for uncontrolled hacking– specific (limited) objectives must be established for each

prototyping iteration– time frame of each iteration must be limited to one month or

less– results must be evaluated and decisions made, just as in the

evolutionary approach

• Evolutionary development follows a systematic process within a larger strategy; prototyping is a technique to study a specific problem within a limited context

Prototyping must be planned and controlled it should not be an excuse for hacking



Some Distinctions

• When building a prototype, we keep the knowledge we have gained but – we do not use the code in the deliverable version of the system

unless we are willing to do additional work to develop production code

• When using evolutionary development, we keep the knowledge we have gained in each cycle– we may, or may not, use the code we have written in the

deliverable version of the system

• When using incremental development, the goal is to keep the code we write in each build as part of the deliverable system



Prototype

Evolutionary

Incremental

Mix and match the processes to fit the problem, as appropriate:1. Prototype to understand the problem

2. Evolutionary to develop solutions

3. Incremental to develop the product

4. Spiral framework to manage iteration

Spiral

A Tailorable Process Framework

development processes must be designed and evolvedin the same way that the product is designed and evolved



A Recommended Approach

• Use prototyping to understand technical issues and to specify the User Interface

• Use evolutionary spiral approaches to evolve solutions (as necessary)

• Use an incremental spiral approach whenever possible– including frequent demonstrations and incremental version

testing

• Embed software development in a system-level spiral model

• Embed the system development process in a workflow process model



customer

management

Planning and Replanning

ActivityDefinition

WorkAssign-ments

SoftwareDevelopment

Quality Assurance

Independent Validation

Measuring

Controlling

DataRetention

Estimating

ReportingStatus ReportsProject Reports

Requirementsand Constraints

Directives andConstraints

Change Requests and Problem Reports

ConfigurationManagement

product

. . . . . . . . . . . . .. . . .

A Process Model of Project Workflow



A Nested Set of Spiral Models








SoftwareDesign




starthere


endhere

add othercomponents



Managing Iterative Development• Iterations must be pre-planned

• Iterations must be of limited duration

• Multiple work activities, and multiple types of work activities may be conducted concurrently

• Iterative, independent validation is required

• An automated version control is essential for establishing and maintaining product baselines– A baseline is a work product that has been evaluated and

accepted by the involved parties– A baseline changed for one of two reasons:

• in response to a requirements change• to fix a defect

the product vision must be maintained



Who Keeps the Process Roadmap and the Product Vision?

• Every software project should have a software development team, with project manager, software architect, and team leader roles– the project manager keeps the process roadmap (the

project plan)– the software architect keeps the product vision (the

product architecture)

• Fred Brooks says– the project manager is like the movie producer– the software architect is like the movie director



An Organizational Structure for Software Projects

Project Manager

TeamLeader #1

Team Leader#2

TeamLeader #3

V&V CM

Member Member Member Member

Software Architect

. . .

Customer

XX

hierarchical structures can grow or shrink as necessary



A Comment

• This session has focused on process models for developing software

• All of the work processes of software engineering should have well-defined processes;

– for example:

• configuration management• quality assurance• verification and validation• and so forth



THE IMPORTANCE OF SOFTWARE PROCESS MODELS

• Physical constraints determine the processes to be used to build and modify physical systems

• In software, our process models provide guidelines that are the equivalent of physical constraints in building physical systems

– process models help us coordinate the work activities of different people working on a common, intellectual work product



READINGS FOR THIS WEEK

• Sommerville, Chapter 3– The Software Process

• Brooks, Chapters 3 & 4– The Surgical Team– Autocracy, Democracy, and System Design– material in Brooks Ch. 19, starting on pg. 253



SESSION 2 Assignments

• Read the Session Three Readings– see the syllabus

• Complete Homework Assignment 2 (next two slides. The same assignment is also on the web)

– it must be turned in at the start of class next session



Homework Assignment #2

Develop an incremental process for development of a word processor

1. Describe the features of your word processor, including a list of the software components in the word processor

2. Develop a numbered list of 10 to 15 operational requirements for the word processor

prioritize the requirement in the order of implementation

3. Decide how many incremental builds (5 or more) will be implemented and demonstrated; group the requirements into incremental builds– the most important parts should be built first– some earlier parts may provide the features needed to build

the later parts4. Include a table of milestones for the development project

indicating the number of each build, what new features will be in each build, and the schedule when each build will be implemented and demonstrated

The assignment is due at start of class next session



Homework Assignment #2

Use the following format for your answer:

Your NameCSE 516, Assignment #2Date the Assignment is due

1. Brief description of the features of your word processor, including the software components in the word processor

2. Numbered list of 10 to 15 operational requirements for the word processor in priority order for incremental development

3. Partitioning and grouping of the requirements for each incremental version– increment #1: list of requirements to be included in

increment #1– increment #2: list of additional requirements to be included

in increment #2– and so forth

4. Table of schedule milestones for the project



An Example1. BRIEF DESCRIPTION OF AN ATM

• An automated teller machine (ATM) allows people to conduct financial transactions at convenient times using conveniently located terminals

• Elements of software for an ATM include:– Hardware Drivers– Communication Package– User Transaction Interface– Off-Line Diagnostics– Off-Line Maintenance

• Incremental development of the User Transaction part will be presented. User Transactions include the following elements:– transaction validation– transaction processing– transaction recording– transaction termination



2. NUMBERED LIST OF REQUIREMENTS FOR ATM FINANCIAL TRANSACTIONS

[1] Financial Transactions can only occur when the ATM is in ON-LINE mode[2] a) Financial Transaction shall accommodate Quick Cash Withdrawal, Standard

Withdrawal, Deposit, Loan Payment, Balance Inquiry, and b) Terminate requests from customers

[3] Financial Transaction shall permit cash withdrawal from checking, savings, and credit card accounts

[4] Financial Transaction shall permit deposits to checking, savings, and credit card accounts

[5] Financial Transaction shall permit transfer of funds between checking and savings, savings and checking, checking and loan accounts, and savings and loan accounts

[6] Financial Transaction shall permit account balance inquiries on checking, savings, and loan accounts

[7] Financial Transaction shall prompt (both visual and audio) the customer toa) Enter Personal Identificationb) Enter Transaction Information

and so forth



3. PARTITIONING AND GROUPING OF THE ATM REQUIREMENTS

• Increment #1:– build the ONLINE communication software (in several incremental builds)

• Increment #2:– build the User Interface shell (in several incremental builds)

• Increment #3:– build communication between user interface and financial institution (in

several incremental builds)

• Increment #4:– build the Hardware Driver software (in several incremental builds)

• Increment #5:– build the Quick Cash Withdrawal option (in several incremental builds)

• and so forth



4. THE MILESTONE CHART AND SCHEDULE

• See lecture charts 2-49 for example of milestone charts– note: you should not copy these charts; make a milestone

chart for your project

• Your schedule should be in the form of a table:– milestone #1:

name work to be completed date (or time from start of project)

– milestone #2: name work to be completed date (or time from

start of project)etc.



Session 2 Summary

• Some People Issues• Some Technology Factors• Some Process Models • A Homework Assignment

Chart 2-1 Copyright © 2004 by R. Fairley CSE 516 Summer, 2004 CSE 516 (formerly known as CSE 500)...

Documents

Transcript of Chart 2-1 Copyright © 2004 by R. Fairley CSE 516 Summer, 2004 CSE 516 (formerly known as CSE 500)...