(c) Copyright 2000 Murray Turoff 1 Development Process CIS 679 Management of Information Systems Set three notes for lectures © Copyright 2000 Murray Turoff

(c) Copyright 2000 Murray Turoff 1

Development Process CIS 679 Management of

Information Systems Set three notes for lectures

© Copyright 2000 Murray Turoff


Introduction


Runaways Black holes of computer budgets Results in many negatives Example : Allstate insurance

1982 project to cost 8 million To be completed in 1987

Estimated for 1993 and 100 million Peat Marwick survey:

600 largest firms 35% have major runaways


Sign of Runaway First year operational budget is

the same as the prior year development budget

No one wants to call it a runaway!!


Runaway Dangers I Unexpected requirement changes Saturated hardware New type of application New technology New operating system New language Low cost review criteria Conceptual requirement errors


Runaway Dangers II Ignoring exceptions Ignoring manual operations Long delays Large projects Lack of accountability Lack of coordination Lack of user cooperation


Application Failures Various surveys give 25% to 75%

of all applications that meet specifications and in time fail to get used successfully.

Usually due to problems with the users and user acceptance

Such problems are a result of the development process


Stupid but Common Reasons for Failure

Don’t bother with a data model or any specific methodology.

Work backward from a drop dead due date

Use an inexperienced technical lead Hire lots of new people to meet the

deadline. Use technology new to your staff Skip the test phase. Leave data migration/conversion

problems till the end Customize an off the shelf package Managers in IS with no computer literacy


View of the Development Process

We will be talking about the perfect desirable environment

No such situation usually exists in any one organization

Actual choices highly situational Considerable tailoring of “ideal”

possible


Development Phases I User request Application selection Feasibility study Justification study Investigation, analysis & systems

design


Development Phases II Programming Systems testing Documentation Conversion & implementation Maintenance Evaluation & post audit Upgrading


Development Process Considerable overlap between

phases Can be iterative and cyclic Authorization and approval

checkpoints Can be tailored to organization &

situation


Project Initiation 1. User request

application selection Problem selection Exploratory study

2. Feasibility study Initial requirements design Solution alternatives Evaluation of alternatives


Project development 3. Investigation

Data gathering Fact finding

4. Analysis 5. System design


Project Implementation 6. Programming

Design, structuring Coding, debugging

7. System testing 8. Documentation

Ongoing 9. Conversion / Data Acquisition

User acceptance and tests


Post Project 10. Maintenance & updating 11. Evaluation & post audit 12. Upgrading


Feedback Structure Operational analysis

Application analysisSystems analysis

ImplementationConversionAcceptance

TestingVerification

Validation Evaluation


Desirable Effort Distribution I User request

1% of effort Priority

Feasibility study 10% of effort Initial decision

Investigation, analysis & design 30% of effort Final decision


Desirable Effort Distribution II Programming, testing,

documentation 40% of effort

Conversion & implementation 10% of effort Acceptance decisions

Evaluation & maintenance 10% of effort Ongoing


Key Development Problems Age of existing systems Manual procedures Cognitive variability Agreement on old system Agreement on new system Who gains benefits Who gains costs User cooperation User computer literacy Staff capability Management involvement


Waterfall life cycle Traditional life cycle Analysis, design, code, test &

maintenance Top down rigidity No iteration between phases Difficult accommodating

uncertainty & risk Black box approach


Prototyping Throwaway approach Evolutionary approach Incremental approach Chance to experiment Can be oversold

Raising expectations Difficult for large complex systems Sometimes prototype considered

final


Spiral Model I Four major activities (1) determination of objectives,

alternatives, and constraints Objectives: functionality,

performance, reliability, flexibility Alternatives: design choices,

purchase or develop, etc. Constraints: time, budget, enabling

technology, staffing, etc.


Spiral Model II (2) risk analysis and prototyping

Budget overruns, schedule slippage, staffing problems, requirements change, technical changes, etc.

Risk: IdentificationAssessmentPrioritizationManagement strategiesResolutionMonitoring


Spiral Model III (3) waterfall approach to next level

product Appropriate validation or

verification (4) plan for the next phase Cycle:

Risk analysis Operational prototype

Simulations, models, benchmarks Detailed design Code, unit test, integration and test,

acceptance test, implementation


Software Development Approaches

Software libraries Computer system level

Functional kernels Interface functions, help libraries

Fourth generation application languages Databases

Object formalism and Reuse Structural modeling

User generated code


Requirements Analysis I Tasks change Difficult to specify all Inadequacies major role in runaways Design for change rather than

absolute specification Support tools

Data flow diagrams, data dictionaries, decision tables, flow charts, object oriented analysis

Knowledge based automatic SD Requirements generate code


Requirements Analysis II Fundamental design principles

AbstractionUser tasks

CouplingMinimize incorporation

CohesionPieces work together

EncapsulationReuse

ModularityMaintainable, extensible


Reusable Designs Reuse of design Reuse of code Construction of frameworks Artifacts of software Object oriented design


Case Support Analysis tools

OOA diagrams, specification checker, real-time analysis toolkits, prototyping tools, etc.

Data design tools Text, graphics, and layout tools for

design documentation, automated design analyzers, Hypertext data bases, etc.

Structure of reuse libraries, open question


Software Development R&D I Faceted classification Software archives Domain analysis Hypertext technology Collaborative Development Knowledge based systems


Software Development R&D II Object oriented technology Data modeling and semantic data

modeling Interface kernels Standards Programming language extensions User mental models & cognitive

processing


Detailed Development Process


User Request Based upon business plan

Business analysis User generated Informal systems analysis review Informal cooperation with IS group Short document

2 to 10 pages Usually standardized ( informally) Submitted to steering committee


User Request Content I Objectives

E.g. Cost reduction, more service, workload increase, performance goals, etc.

Preferred quantification Boundaries & constraints

Budget limits Resource limits Security requirements

Lists Mandatory documents


User Request Content II Time scale Identified problems Suggested solutions User should know :

Problem Application specifics Users organization

Systems people should know: Technology Implementation effort Generalizable approaches


User Request Process Steering committee considerations

Available resources Other project requests Predictability by plan

Steering committee alternatives Do it (advance to feasibility study) Put it on hold Turn back for more information Reject it Buck it up to higher level

Sometimes formal requirement


Middle Level Steering Committee I

Representatives of user units Middle management/ professionals Computer literate

Chair is assistant CIO A few IS professionals/ managers

Minority


Middle Level Steering Committee II

Set priorities on projects Review IS resources

Equipment Software People

Review long & short term plans Endorse budget


Middle Level Steering Committee III

Review major problems Make recommendations when

needed To represent user interests Yes/ no on user request Yes /no on feasibility study Replace charging function


Role of Steering Committee I Priority setting for projects Review of projects Policy recommendations Approving standards Review of IS resources

Recommending significant changes Review of evaluation studies Translation of strategic objectives

into tactical criteria


Role of Steering Committee II Developing function IS

requirements Mediating

Between users groups Between users and IS shop

Recommending organizationally wide IS projects

Review of IS budget and endorsement

Setting objectives for IS


Upper Level Steering Committee Translate business plans to IS

plans Set strategic IS objectives Approve major IS projects over

some dollar amount Approve major IS expenditures

GDBMS Major network expansion New main frame

Higher new CIO Resolve major conflicts


Role of the IS Manager or CIO I Allocating resources to accomplish

priorities Tactical and operational decisions

Based upon tactical criteria set up by steering committee

Deciding on technical feasibility of any project or effort

Planning IS Development Staffing Resource allocation


Role of the IS Manager or CIO II Allocation of people to jobs Recommend equipment and

software Recommending organizational

standards


Management Realties No excuse for failure No excuse for not handling problems Resources requested have to be

adequate Decision must have specificity Decisions must have accountability Promises have to be kept Punishments may be long term

At right time, after cover-up Use of scapegoats

Formal & informal systems The higher up the truer


Conflicting Objectives IS department wants performance Technical types want modern

technology Vendor wants profit Budget people want least cost Users want tasks and jobs done Organization wants profitability


Checkpoints Decisions

Schedules, resources, etc. Agreement

What is reality and objectives Within user groups Between user groups Within IS department Between IS & users


Feasibility Effort


Feasibility/Justification Study Not a design study Enough to carefully establish

Resources required Uncover hidden problems Feasible alternatives

Top level designs Five to ten percentage of effort Multi disciplinary team User participation


Feasibility/Justification Content I Terms of reference

Role in plan Scope of study Methods of study Objectives, boundaries, &

constraints Existing system

Summary description Growth and future trends Problem analysis


Feasibility/Justification Content II

Requirements specification Data requirements Processing requirements Constraints: time & security

Alternative solutions Outline description Outline development plan Cost/benefit analysis Advantages/disadvantages

Recommendations & solutions Related documents, reports, data


Feasibility/Justification Agreement

Sign off by IS department Sign off by user departments Sign off by study team Sign off by affected departments Last “real” chance to kill projects


Feasibility/Justification Process Steering committee actions Accept

Set priority, starting date Choose solution

Push it higher up \ put on hold Conditionally accept Shortcomings

Send back for more work Table (usually political) Conditionally reject (reasons why) Reject (reasons why)


Feasibility/Justification Criteria Solution must be:

Technically feasible Operationally suitable Economically viable

User cooperation must be assured The more expended on effort:

Harder to kill If accepted:

Detailed plan laid out for: Investigation, analysis, design


Evaluation Criteria I Costs & objectives

Economic viability Is it worth the money?

Hardware & software Technical feasibility

Can it be put together?


Evaluation Criteria II People & organizations

Operational suitabilityCan it be used?Will it cause learning?

Profitability Strategic viability

Will it make money?Will it have value?


Economic Viability I Automation

Reduce people time Specialize work Displace work Eliminate jobs

Productivity Obtain sooner Reduce cost Increased quantity Increase quality


Economic Viability II Opportunity

Do new things Do different things Do impossible things


Development Effort & Uncertainty

User request 1-2% Uncertainty in effort 100%

Feasibility study 5-10% Uncertainty in effort 50%

Design study 20-40% Uncertainty in effort 25%

Implementation 30-60% Uncertainty in effort 10%

Conversion 5-30% Uncertainty in effort 10%


Investigation Effort


Investigation Study Content Current and new system Data: Uses, volume & characteristics Procedures: What is done, where,

when & how Error and exceptions cases People: Who does what, when and

how, aptitude & attitudes Future: Growth rates, projections on

workloads Reports and output requirements:

accuracy, timeliness, security


Investigation Problems Major predictable problems:

Age of existing system Cognitive variability Lore Informal processes

Major checkpoint: Agreement on existing system

What is it? Investigators, users


Agreement Roles Requesters Users (may come in many flavors!) Designers Managers Operators Suppliers


Agreement Issues What was the old system? What is the new system? Who accepts it? How is it changed? What is manual procedure? What are the exceptions? What are the constraints? Who bares costs? Who gains benefits?


Decision & Agreement Points I Software development projects User request

Informal agreement on computer Approach appropriateness

SA/BA and user Initial feasibility

Computer group Initial priority and go ahead

Steering committee


Decision & Agreement Points II Feasibility study

Users and DevelopersAgreement on what current systems is and does

Agreement on what new system should do

Agreement on meaningful alternatives

Agreement on chosen alternativeSteering committee, users and developers


Decision & Agreement Points III Feasibility study

Final priority for project, go ahead to next stepSteering committee

Investigation, analysis and design Detailed agreement on what

current system does, including manual processes

Detailed performance criteria for new systemUsers, Managers, Developers


Decision & Agreement Points IV Investigation, analysis and design

Efforts required on part of user group

Resources needed from other sources (auxiliary groups)Computer group and users (maybe bas)

Final decision to go aheadSteering committee, computer group and users


Decision & Agreement Points V Programming, system testing,

documentation Acceptance of the system as

workingUsers, computer group, maintenance group, audit group

Conversion & implementation Accepted as an operational system

Users, computer group, maintenance group, audit group


Decision & Agreement Points VI Evaluation of objectives being met

Designers, developers, users, steering committee

Changing requirement Users, developers, designers,

Evaluator


System Investigation


Investigation / Inquisition Collect information

Maximum amount Correct Relevant

In minimum time While doing “public” relations


Investigation Methods Study of documents Interviews Observations Participant observation Protocol analysis Questionnaires Groups (e.g. focus) Delphi Key: structure for information


Sample Interview Checklist I For document

Identification What is entered When, how often received? How many are received?

Peaks & troughs? Where does it come from?


Sample Interview Checklist II For document

Who does it come from? How is it delivered? Who delivers it? Where is it received? Who receives it? What is it used for? What happens to it?

Leads into procedures


Sample Interview Guide For functions:

Place each on 3 x 5 card Lay out table of:

DesirabilityFeasibility

Request user judgement Ask for explanations and note Ask to fill in blank cards


Interview Things to Do Do:

Keep phrasing simple Keep a logical sequence Leave room for notes Keep questions relevant to the

person being interviewed Use shorthand codes

++ important agreement ? Missing information

Have back up checklists forDocuments, files, procedures


Interview Things to not Do Do not:

Be vague in phrasing Cram for space or be untidy Be parochial

Process: 1. Think of major question 2. Ask it 3. Listen 4. Analyze 5. Note 6. Form supplementary question


User Alternatives I What he would like analyst to

think What he thinks analyst would like

to hear What he thinks analyst would like

to know What actually happens What he would like to happen What he has been told happens


User Alternatives II What his supervisor would like him

to say What it says officially occurs What he has been told to say What is good for him What is good for the organization What is good for the unit


User Strategy Develop user community Acquisitions tied to goals Use steering committee Encourage computer literacy Develop user requirements

continuously Deal with qualitative &

quantitative impacts Emphasize: time saved & new

opportunities


SA Behavior Be objective Validate Be professional Do not give up (polite tenacity) Follow through Be diplomatic Be willing to go out on a limb when

you know it makes a difference!


Factors Increasing Resistance Apprehension about change Unanswered concerns Conflicts with beliefs Past negative changes Irritation with manner of change


Factors Decreasing Resistance Personal security Trust in management, union, work

group Confirmed positive expectations Past positive changes Satisfaction with manner of

change


User Questions I Will it:

Affect my earnings? Block my promotion prospects? Limit my freedom of action? Mean I lose my job? “take the fun” out of the job? Mean more supervision? Cut the number of my staff? It erodes my authority? It increases my workload?


User Questions II Will I:

Just become a ‘new boy’ ? Be able to cope with everything?

Is this just the first step, what is next?


Acceptance/Rejection Spectrum I Acceptance

Enthusiastic support Active cooperation Willing acceptance Cooperation under pressure Passive acceptance Tolerance under sufferance

Indifference Apathy Minimum effort to run system Regressive, non-learning behavior


Acceptance/Rejection Spectrum II

Resistance Minimum effort on work generally Withdrawal Protests Bending the system Deliberate sabotage


Justification Analysis I What new system will do Trap:

Automating what was done before Itemization of:

Functions Data Problems to be solved

Major checkpoint: Agreement on what new system will

do Agreement on justification for system Investigators, users


Justification Analysis II Efficiency

Functions done quicker More volume Save people time

Eliminate jobsDon’t hire

Cheaper Effectiveness

Standards State of the art (learning) Increase quality


Justification Analysis III Opportunity

Do old things, new ways Do new things, new ways Do impossible things


Justification Analysis IV Productivity =

Quality x quantity / cost Efficiency =

Effectiveness / cost Opportunity Strategic relevance Profit enhancement


Justification Analysis V Problems: Measures of performance

Drunkard’s paradox Measuring reality, not potential

Multiple measures (relationships) Individual conflicts Artistic compromises

Subjective estimations Groups agreement processes Basis for final cost justification


Systems Design


System Design Objectives Create system specification

Business system design Technical system design

Basis for Final cost/benefit assessment Plan for project implementation


Design Methods Comparison / differentiating Designing / requirements

Task understanding / macro Cognitive understanding / micro

Enhancements / evolution Visioning / normative

Social engineering Goal setting


User Involvement Defining & agreeing on project

aims Liaison officers Decision checkpoints Staff contributions to investigation Staff training Staff participation during

conversion Mockup evaluation Evaluation Feedback


Customer Developer Links Facilitated team/focus group IS intermediary Support line, Help desk Surveys, Delphi User Interface Prototyping Requirements Prototyping Interviews Testing (Beta) Email/Bulletin Board Usability Lab Participant Observation Studies Marketing User groups Trade show exhibits


Survey of Eleven Companies More links to customers the

greater the percentage of successful application project

Most used three to five distinctive links, six upper bound

Too many links resulted in little payoff for additional links

Reduced reliance on indirect links (intermediaries and surrogates)


Custom Software Top Rated Links

Facilitated teams/focus groups User interface prototyping Requirements prototyping Interviews Testing IS intermediary Bulletin Boards


Packages Software Top Rated Links

Support line Interview User interface prototyping User groups Requirements prototyping Testing Marketing


Current Operational Systems User surveys Interviews of power users and

light users Monitoring current operations

Functions used Errors occurring Power users


Attitude Toward Users Treating customers as the experts Apprenticeship on user tasks Understanding user problem

solving How users treat data and

information Detail of the work domain Determining who is the user or

who should be listened to.


System Specification Document I For old and new system Still not subroutine level Functional level 1. System summary

1.1 management summary 1.2 system organizational chart 1.3 narrative description 1.4 organizational responsibilities 1.4 cost/benefit study


System Specification Document II

2. Data specifications 2.1 files and data structures 2.2 inputs 2.3 outputs

3. Processing specifications 3.1 manual 3.2 computer

4. Interface specifications 4.1 metaphor 4.2 screen mockups 4.3 evaluation


System Specification Document III

5. Integration specifications 5.1 data and file transfer

6. Constraint specifications 6.1 security 6.2 time limits

7. System test plan 7.1 test organization 7.2 test schedule

8. Conversion plan 8.1 conversion tasks & responsibilities 8.2 file data sources & preparation

methods 8.3 conversion schedule & costs


System Design Actions Steering committee

Final determinationGo \ no goDelaySeek revisionPass up

AmountControversy

Usually formality Informal commitments crucial Battles settled before


User Involvement


User Participation Necessary for Decision Support and Expert

Systems Desirable for:

Increasing task and system complexity Realistic user expectations Bargaining & conflict resolution between IS

and Users Increased user feelings of ownership Increased user commitment

Can be negative if prior implementations were poorly done Condition of trust for IS must exist with users.

Confounding variations: degree of influence and control, specific phases of effort.


Hypothesis of User Participation 1. Participation relationship to Success

influenced by a set of contingency variables. ** correlation in survey with user

satisfaction 2. Participation Behavior relationship to User

Satisfaction influenced by the need for participation Need for participation function of task

complexity (or ambiguity) and system complexity

@@ correlation with user satisfaction with increasing “need for participation”

All the following forms of user participation were observed in survey.


Project Feasibility User Involvement

Project definition**@@ Cost justification Approval of cost justification** Developed Information

requirements Approval of Information

requirements Use to obtain information

requirements


Project Design User Involvement Member of project team Review prototype Walk through design with IS staff Define physical controls and

security procedures**@@ Approve controls and security Define I/O forms, screens,

reports@@ Approve I/O forms, screens,

reports


Project Installation User Involvement

Member of team**@@ Develop test data specifications** Approve test data specifications Conduct the system test**@@ Approve the results of the system

test Conduct training for users** Approve training for users Responsible for purchase of

hardware or software**@@


Project Management User Involvement

Leader of project team**@@ Initiate project via formal request**@@ Charged for project cost** Formal “user liaison” appointed by IS Formal “user-liaison” appointed by user

shop Develop project management schedules and

progress reports**@@ Approve project management schedules and

progress reports**@@ Attend technical seminars on computers or

IS User participation is assessed by user

management**@@


Correlation Results Strong correlation between user

participation in general and user satisfaction

Stronger correlation for tasks of high complexity and complex systems.

There is no dysfunctional effects shown but they exist and this study sheds no light on that issue.

No control on user or management literacy

No control on type of application or its objectives

No control on mutual trust or past history


Software Creation


Software Experiment 3 people teams

Experience & talent 3 day effort roughly Objectives

Create in shortest time Create shortest code Minimum core usage Minimum execution item Easy to maintain code Easy to read output

Software as an art form


Software Cost Observations I Cost of errors = 50% (of total effort) Cost of conceptual & design errors =

40%

Error in estimation of effort Before requirements 100% Before development 50% Before operations25%

If standard/frequent job 1/2 above


Software Cost Observation II Cost of software line of code

Linear up to 70% machine utilization.

Twice as much at 80% Four times at 90%

Limited hardware or software has non linear impact on increasing cost of professional effort expended.


Programming, Testing, Documentation I

Final decomposition of specifications Tailored to people resources Tailored to hardware & software

Considerable overlap Case and software engineering Live testing Interface refinement


Programming, Testing, Documentation II

Variabilities Management style Degree of talent State of hardware & software Moral & commitment Attitude of technical people


Programming, Testing, Documentation III

Variabilities Relationships to user groups Degree of specialization Team structures

StandardEgolessSurgicalApprenticeshipBalanced


Problem Projects (PP)


Alternatives for Problem Projects

Revise completion date? Hire more staff? Increase overtime? Reduce requirements?


Associated Questions for PP How much quality assurance

effort? What should distribution of effort

be on phases of project? What are the differences between

potential, actual, and perceived productivity?

Why does the “90% completion syndrome” chronically reoccur?


Adding more people More communications among total

staff More training of new people The later this occurs the more

likely the impact is negative Brooks’ Law Mythical man month Non linear efforts


Increasing Overtime or Reducing Requirements

Concentrates on “essentials” Likely to lower quality of results More errors due to increased

stress User features likely to get reduced Documentation suffers At some point also a negative

impact


90% Completion Syndrome Takes 10% of the time/effort to get

to 90% completion, than 90% of effort to get to 100% completion.

What does 40% completed mean to estimator?

Over optimism bias because specific pieces have been defined.

Problems of integration of pieces and gathering accurate control information from everyone


Modeling the Software Production Process

Paper by Abdel-Hamid & Stuart Madnick

Example of modeling a human organization

Four subsystems Potential for understanding &

relating Organizational design Human Behavior IS Design


Human Resource Management Model

Workforce size Organizational Learning New members Experience of group Hiring rate (perceived need) Turnover rate (result of stress)


Software Production Model Software development rate Actual productivity

Process loss (schedule pressure, workforce)

Potential Productivity Learning

Quality assurance (AWS) Error rate Error detection


Planning Model Adjustments to workforce &

schedule (AWS) Scheduled completion date

Forecasted completion dateSchedule pressure


Control Model Perceived Productivity

Project tasks perceived completed (influence AWS)

Actual Productivity Accuracy of Measurement

Effort Perceived as still needed Perceived project size


Basic Model Relationships Actual productivity = Potential –

Losses due to faulty processes Perceived productivity = Actual +

reductions in requirements – changes in requirements


Role of Quality Assurance Analysis from simulation Minimum overall project costs

when QA about 15% of the effortOnly about 70% of errors detected

Larger QA at 40% detects only 80% of errors and costs almost double

Smaller QA at 5% of effort doubles project costs through more undetected errors

Initial values for this type of model based upon historical data


Missing Model Relationships AWS used to reduce project tasks

by ignoring them and reducing project size

AWS used to reduce quality assurance effort

Schedule pressure increases turnover

Scheduled tress decreases new hiring skill level which influences workforce experience mix


Management Coping Managers often use fudge factors (25% to

100%) No feasibility study 100% error possible All design work done 25% error possible

Often leads to increasing size of project because of peak loads toward end of project.

Reasons for increased specialization and handoff Can harm morale of workforce (long-term)

No new staff at the point of testing started Push to use sequential waterfall type

approach


Software Development Many assumptions the result of

expert wisdom Many assumptions have proven to

be false when controlled experiments have been done.

Example today is a growing emphasis on graphical visualization methods


Graphical Visualizations of Software I

Much of what contributes to the comprehensibility of a graphical representations isn’t part of the formal programming notation but a secondary notation of layout, typographic cues and graphical enhancements that is subject to individual skill.

Graphical readership is an acquired skill: structure, relationships, and relevance aren’t universally obvious


Graphical Visualization of Software II

Experts ‘see’ differently and use different strategies from novice graphical programmers.

Although some touted qualities may be illusory, graphical representations are nevertheless persistently appealing and that has its own value

The role of graphics in notation must be addressed realistically


Cognitive influences on Software Compare decision table with either flow

chart or structured program. Good graphics usually means linking

perceptual cues to important (what and to whom) information

Shallow inheritance graphs are more comprehensible and less complex than deep ones, but deep ones can capture more commonalties among classes

Dynamic binding can increase reuse flexibility, but can extract penalties in performance, simplicity, and robustness


Common Biases for implementers

Representatives: assume global result or general assumptions will occur locally causes implementers to ignore deviations

Availability: people estimate occurrence of an event by how easy they remember about the occurrence of the event. Implementers will try to use code chunks and structures they are most familiar with.

Confirmatory: having a preference for confirmatory information and not looking for data to negate the assumption.


Bug Categories (Knuth) Algorithm awry Blunder or botch Data structure debacle Forgotten function Language liability, misuse of

tools/language/hardware Mismatch between modules Reinforcement of robustness (e.g.,

handling erroneous input) Surprise scenario, or bad bugs that

forced design change Trivial typo


Why Bugs difficult to track down Cause/Effect chasm

Consider reuse and object programming

Large temporal or spatial chasms between symptom and bug.

Tools inapplicable or hampered WYSIPIG (What you see is probably

illusory, guv’nor) Faulty Assumption/Model or

misdirected blame Spaghetti (Unstructured) code


Techniques used to track down the bugs

Gather data Inspeculation

Step and study Wrap and profile Print and peruse Dump and compare Conditional breaks and inspect Specialist profile tool

Expert recognized cliché Controlled experiments


Common underlying causes of bugs

Memory clobbered Vendor problems Unanticipated case Wrong initialization Lexical problem or ambiguous

syntax Wrong variable or operator Unknown or unsolved Language semantics ambiguous End user’s subtle behavior


Observations on bugs Solution still a craft and art form Reuse assumes perfect code and

modules Chasm is biggest error problem

with respect to effort. Increasing complexity of systems

making situation worse “Full proof” but constrained

development environments is one current popular solution.


Total Quality Management (TQM)

Solution to changing user requirements by putting the user in charge!!!

Focus on the “voice of the customer” to provide functionality

Planning to deliver as the customer wants it, in a timely manner

Deliver a quality product in customers view

Control and monitor costs and provide accurate costs to users.


Aspects of TQM Benefits of TQM

Implemented in a very precise and objective manner

High confidence of avoiding many common pitfalls

Problems of TQM Produces literal user designs Rare to get strategic or process

oriented systems Rare to take full advantage of

technology capabilities


Software Engineering Objectives Understanding user conceptual

models and development of better specifications

Improvement in design languages and reusable code

Participatory design and interactive debugging

Specification of interface and mockup to confirm specifications


Software Development Process Software implementation is a

descriptive process In the actual use it is translated to

a prescriptive process Software process is open as long as

the application exists Product must either evolve or atrophy Formal models that satisfy initial need

may constrain the scope of future modifications

Formal initial model may be incomplete and leave things out.


Method Categories I Conceptual (descriptive, validation) Problem Oriented

Understanding problem in terms of application domain

Example: database entity-relationships models

Product Oriented Transform application concepts into

implementation decisions Example: information flow diagrams


Method Categories II Formal (prescriptive, verification) Problem Oriented

Representations that shed insight into problem and solution

Example: Problem oriented programming languages

Product Oriented Creating correct implementation

units Examples: programs, objects


Current Controversies Data flow versus data structure Module organization: process

versus object Logical versus conceptual

approaches Decomposition (top-down) and

composition (outside-in) Conceptual for problem domain

versus formal for implementation domain


Quality Management ISO 9000: developed in 1979

British Standards Institute ISO 9000 covers:

Quality design Quality management Quality assurance

ISO 9000 does not check for conformance


Conformance Alternatives The organization that follows the

standard (first party) The organizations that buys a

product or service (second party) An organization that specializes in

conformance (third party)


Mission of Organization Increase quantity of customers Increase quality to customers Decrease cost to customers Organization determines

documents/evidence to measure improvements in mission variables.


Mapping Documents & Behavior Best situation

Documents conform to standard and people behavior follow documents

Worse situation Documents do not follow the

standard or are missing and people do not follow them.


Coordination in Software Development


Problem of Scale/Size Encourages specialization Division of labor Compartmentalization Subgroup Cohesion Reduction of sharing Reduction of breath of experience Narrowness


Uncertainty Inability to anticipate all changes Incomplete specifications Undetected errors in design Undetected errors in test product Incompleteness because too few

people have sufficient knowledge of the whole application domain.

Precise integration of numerous components required


Three Traditional Approaches to Coordination

Technical Tools Editors Languages Version Data bases

Modularization Formal Procedures

Version control Specification Languages Test Plans


Structural Characteristics of Projects

Project Size Project Age Planning stages and percentage of

effort Organizational Interdependence

Project dependence on efforts outside project, e.g. network functions

Project certainty Past relevant experience of

organization and people


Project Outcomes I Project members informed:

management and professionals understand scope of project

Coordination success: duplication, redundancy and lack of completeness

Client Satisfaction: ease of learning, absence of defects, functionality required, etc.


Project Outcomes II Mangers evaluation: internal

quality of product, external quality of the product, accomplishment of objectives, schedules, and effort forecasts.

Software productivity: amount of change required and uncertainty dealt with

Software Quality: errors by type, frequency, and effort


Coordination Techniques I Formal impersonal procedures

Project documents and memos Project milestones and delivery

schedules Modification request and error

tracking procedures Data dictionaries

Formal interpersonal procedures Status review meetings Design review meetings Code inspection


Coordination Techniques II Informal interpersonal procedures

Group meetings Collocation of requirements and

development staff Electronic Communication

Electronic mail Electronic Bulletin boards

Interpersonal network Contacts outside the project


Survey of Managers and Professionals

One company Sent to 150 line managers and 600

professionals Returned by 563 individuals Projects included: 65 At project level data averaged

over all respondents in project.


Ratings of Value of Coordination Methods I

Top Cluster (6/7): Discussion with Peers

Second Cluster 5.5-5/7): Project documents, customer testing, milestone, schedules, design reviews, requirements reviews, error tracking


Ratings of Value of Coordination Methods II

Third Cluster (5-4.5/7): Status reviews, Collocation, Discussions with boss, electronic mail, group meetings.

Fourth Cluster(<4.5): Code inspections, project bulletins

Fifth cluster (<3.5): Source code, data dictionaries

Sixth cluster (~3): Management case tools


Ratings of VALUE and USE Flaw in paper Does regression on these two

variables on a 7 point scale for each

No use of variance or uncertainty in positions of averages in original data.

Assumes estimates are perfect.


Ratings of Value for Problem Solving by Software Engineers

Top Source (6): Other project members

Rating (4): Non-project company members, boss

Rating (3.5): Client experts, project documentation

Ratings (3): Source code Ratings (2.7): Vendors, books and

journals Ratings (<2): Electronic bulletin

boards


Statistical Correlation I Staff members assessment of their

project coordination strongly correlates with customer satisfaction

Software quality and productivity correlate

Software quality and productivity unrelated to clients assessment (problem?).


Statistical Correlation II Management rating uncorrected

with any measures except coordination success, but low correlation (related problem?)

DISTURBING RESULT: Current practices not a guide to success


Other Development Components


System Development Concerns I Not what you do but who does it Never install without testing In case of failure stop and think,

not run Make sure competition does not

wipe out gains Proprietary hardware and software

trap


System Development Concerns II Efficient if you produce more with

less Effective if you pocket the gains Make only one major change at a

time System faults are multiplicative

Anticipate change Investigate exceptions


Conversion File conversion User training Documentation review Operational acceptance trials Maintenance review Software review Prototyping Hardware delivery & installation Services expansion


Maintenance Used to disguise runaways

Cost year one equals development cost

All systems subject to change Support software changes Sources of application changes

Residual bugs Unexpected exceptions Changing user requirements Reductionism errors

Tradeoffs and conflicts Applications conception errors


Software Maintenance Problems I

In order of importance: User knowledge Lack of user understanding Inadequate training Programmer effectiveness

Productivity, motivation & skillsProduct qualityAdequate design specificationsQuality of programmingQuality of documentation


Software Maintenance Problems II

Machine requirements Storage & processing time System reliability Hardware & software Data integrity


Evaluation Achieve what users wanted? Have requirements changed? Easy to learn? Training and help adequate? User effort required Hardware & software performance? Error type and frequency analysis? Frequency and type of exceptions? Evolution? User saturation? Integration?


Support Functions Standards Training Systems software General application systems

Databases Communications Transaction tracking

Documentation, library, clerical Forward resource planning Forward system planning Distributed computing & systems


THE END

CIS 679 Management Information Systems The Development Process The third notes set http://eies.njit.edu/[email protected]