(c) copyright 2000 murray turoff 1 development process cis 679 management of information systems set...
Post on 15-Jan-2016
217 views
TRANSCRIPT
(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 2
Introduction
(c) Copyright 2000 Murray Turoff 3
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
(c) Copyright 2000 Murray Turoff 4
Sign of Runaway First year operational budget is
the same as the prior year development budget
No one wants to call it a runaway!!
(c) Copyright 2000 Murray Turoff 5
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
(c) Copyright 2000 Murray Turoff 6
Runaway Dangers II Ignoring exceptions Ignoring manual operations Long delays Large projects Lack of accountability Lack of coordination Lack of user cooperation
(c) Copyright 2000 Murray Turoff 7
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
(c) Copyright 2000 Murray Turoff 8
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
(c) Copyright 2000 Murray Turoff 9
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
(c) Copyright 2000 Murray Turoff 10
Development Phases I User request Application selection Feasibility study Justification study Investigation, analysis & systems
design
(c) Copyright 2000 Murray Turoff 11
Development Phases II Programming Systems testing Documentation Conversion & implementation Maintenance Evaluation & post audit Upgrading
(c) Copyright 2000 Murray Turoff 12
Development Process Considerable overlap between
phases Can be iterative and cyclic Authorization and approval
checkpoints Can be tailored to organization &
situation
(c) Copyright 2000 Murray Turoff 13
Project Initiation 1. User request
application selection Problem selection Exploratory study
2. Feasibility study Initial requirements design Solution alternatives Evaluation of alternatives
(c) Copyright 2000 Murray Turoff 14
Project development 3. Investigation
Data gathering Fact finding
4. Analysis 5. System design
(c) Copyright 2000 Murray Turoff 15
Project Implementation 6. Programming
Design, structuring Coding, debugging
7. System testing 8. Documentation
Ongoing 9. Conversion / Data Acquisition
User acceptance and tests
(c) Copyright 2000 Murray Turoff 16
Post Project 10. Maintenance & updating 11. Evaluation & post audit 12. Upgrading
(c) Copyright 2000 Murray Turoff 17
Feedback Structure Operational analysis
Application analysisSystems analysis
ImplementationConversionAcceptance
TestingVerification
Validation Evaluation
(c) Copyright 2000 Murray Turoff 18
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
(c) Copyright 2000 Murray Turoff 19
Desirable Effort Distribution II Programming, testing,
documentation 40% of effort
Conversion & implementation 10% of effort Acceptance decisions
Evaluation & maintenance 10% of effort Ongoing
(c) Copyright 2000 Murray Turoff 20
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
(c) Copyright 2000 Murray Turoff 21
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
(c) Copyright 2000 Murray Turoff 22
Prototyping Throwaway approach Evolutionary approach Incremental approach Chance to experiment Can be oversold
Raising expectations Difficult for large complex systems Sometimes prototype considered
final
(c) Copyright 2000 Murray Turoff 23
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.
(c) Copyright 2000 Murray Turoff 24
Spiral Model II (2) risk analysis and prototyping
Budget overruns, schedule slippage, staffing problems, requirements change, technical changes, etc.
Risk: IdentificationAssessmentPrioritizationManagement strategiesResolutionMonitoring
(c) Copyright 2000 Murray Turoff 25
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
(c) Copyright 2000 Murray Turoff 26
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
(c) Copyright 2000 Murray Turoff 27
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
(c) Copyright 2000 Murray Turoff 28
Requirements Analysis II Fundamental design principles
AbstractionUser tasks
CouplingMinimize incorporation
CohesionPieces work together
EncapsulationReuse
ModularityMaintainable, extensible
(c) Copyright 2000 Murray Turoff 29
Reusable Designs Reuse of design Reuse of code Construction of frameworks Artifacts of software Object oriented design
(c) Copyright 2000 Murray Turoff 30
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
(c) Copyright 2000 Murray Turoff 31
Software Development R&D I Faceted classification Software archives Domain analysis Hypertext technology Collaborative Development Knowledge based systems
(c) Copyright 2000 Murray Turoff 32
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
(c) Copyright 2000 Murray Turoff 33
Detailed Development Process
(c) Copyright 2000 Murray Turoff 34
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
(c) Copyright 2000 Murray Turoff 35
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
(c) Copyright 2000 Murray Turoff 36
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
(c) Copyright 2000 Murray Turoff 37
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
(c) Copyright 2000 Murray Turoff 38
Middle Level Steering Committee I
Representatives of user units Middle management/ professionals Computer literate
Chair is assistant CIO A few IS professionals/ managers
Minority
(c) Copyright 2000 Murray Turoff 39
Middle Level Steering Committee II
Set priorities on projects Review IS resources
Equipment Software People
Review long & short term plans Endorse budget
(c) Copyright 2000 Murray Turoff 40
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
(c) Copyright 2000 Murray Turoff 41
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
(c) Copyright 2000 Murray Turoff 42
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
(c) Copyright 2000 Murray Turoff 43
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
(c) Copyright 2000 Murray Turoff 44
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
(c) Copyright 2000 Murray Turoff 45
Role of the IS Manager or CIO II Allocation of people to jobs Recommend equipment and
software Recommending organizational
standards
(c) Copyright 2000 Murray Turoff 46
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
(c) Copyright 2000 Murray Turoff 47
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
(c) Copyright 2000 Murray Turoff 48
Checkpoints Decisions
Schedules, resources, etc. Agreement
What is reality and objectives Within user groups Between user groups Within IS department Between IS & users
(c) Copyright 2000 Murray Turoff 49
Feasibility Effort
(c) Copyright 2000 Murray Turoff 50
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
(c) Copyright 2000 Murray Turoff 51
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
(c) Copyright 2000 Murray Turoff 52
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
(c) Copyright 2000 Murray Turoff 53
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
(c) Copyright 2000 Murray Turoff 54
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)
(c) Copyright 2000 Murray Turoff 55
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
(c) Copyright 2000 Murray Turoff 56
Evaluation Criteria I Costs & objectives
Economic viability Is it worth the money?
Hardware & software Technical feasibility
Can it be put together?
(c) Copyright 2000 Murray Turoff 57
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?
(c) Copyright 2000 Murray Turoff 58
Economic Viability I Automation
Reduce people time Specialize work Displace work Eliminate jobs
Productivity Obtain sooner Reduce cost Increased quantity Increase quality
(c) Copyright 2000 Murray Turoff 59
Economic Viability II Opportunity
Do new things Do different things Do impossible things
(c) Copyright 2000 Murray Turoff 60
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%
(c) Copyright 2000 Murray Turoff 61
Investigation Effort
(c) Copyright 2000 Murray Turoff 62
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
(c) Copyright 2000 Murray Turoff 63
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
(c) Copyright 2000 Murray Turoff 64
Agreement Roles Requesters Users (may come in many flavors!) Designers Managers Operators Suppliers
(c) Copyright 2000 Murray Turoff 65
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?
(c) Copyright 2000 Murray Turoff 66
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
(c) Copyright 2000 Murray Turoff 67
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
(c) Copyright 2000 Murray Turoff 68
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
(c) Copyright 2000 Murray Turoff 69
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
(c) Copyright 2000 Murray Turoff 70
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
(c) Copyright 2000 Murray Turoff 71
Decision & Agreement Points VI Evaluation of objectives being met
Designers, developers, users, steering committee
Changing requirement Users, developers, designers,
Evaluator
(c) Copyright 2000 Murray Turoff 72
System Investigation
(c) Copyright 2000 Murray Turoff 73
Investigation / Inquisition Collect information
Maximum amount Correct Relevant
In minimum time While doing “public” relations
(c) Copyright 2000 Murray Turoff 74
Investigation Methods Study of documents Interviews Observations Participant observation Protocol analysis Questionnaires Groups (e.g. focus) Delphi Key: structure for information
(c) Copyright 2000 Murray Turoff 75
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?
(c) Copyright 2000 Murray Turoff 76
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
(c) Copyright 2000 Murray Turoff 77
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
(c) Copyright 2000 Murray Turoff 78
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
(c) Copyright 2000 Murray Turoff 79
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
(c) Copyright 2000 Murray Turoff 80
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
(c) Copyright 2000 Murray Turoff 81
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
(c) Copyright 2000 Murray Turoff 82
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
(c) Copyright 2000 Murray Turoff 83
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!
(c) Copyright 2000 Murray Turoff 84
Factors Increasing Resistance Apprehension about change Unanswered concerns Conflicts with beliefs Past negative changes Irritation with manner of change
(c) Copyright 2000 Murray Turoff 85
Factors Decreasing Resistance Personal security Trust in management, union, work
group Confirmed positive expectations Past positive changes Satisfaction with manner of
change
(c) Copyright 2000 Murray Turoff 86
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?
(c) Copyright 2000 Murray Turoff 87
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?
(c) Copyright 2000 Murray Turoff 88
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
(c) Copyright 2000 Murray Turoff 89
Acceptance/Rejection Spectrum II
Resistance Minimum effort on work generally Withdrawal Protests Bending the system Deliberate sabotage
(c) Copyright 2000 Murray Turoff 90
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
(c) Copyright 2000 Murray Turoff 91
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
(c) Copyright 2000 Murray Turoff 92
Justification Analysis III Opportunity
Do old things, new ways Do new things, new ways Do impossible things
(c) Copyright 2000 Murray Turoff 93
Justification Analysis IV Productivity =
Quality x quantity / cost Efficiency =
Effectiveness / cost Opportunity Strategic relevance Profit enhancement
(c) Copyright 2000 Murray Turoff 94
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
(c) Copyright 2000 Murray Turoff 95
Systems Design
(c) Copyright 2000 Murray Turoff 96
System Design Objectives Create system specification
Business system design Technical system design
Basis for Final cost/benefit assessment Plan for project implementation
(c) Copyright 2000 Murray Turoff 97
Design Methods Comparison / differentiating Designing / requirements
Task understanding / macro Cognitive understanding / micro
Enhancements / evolution Visioning / normative
Social engineering Goal setting
(c) Copyright 2000 Murray Turoff 98
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
(c) Copyright 2000 Murray Turoff 99
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
(c) Copyright 2000 Murray Turoff 100
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)
(c) Copyright 2000 Murray Turoff 101
Custom Software Top Rated Links
Facilitated teams/focus groups User interface prototyping Requirements prototyping Interviews Testing IS intermediary Bulletin Boards
(c) Copyright 2000 Murray Turoff 102
Packages Software Top Rated Links
Support line Interview User interface prototyping User groups Requirements prototyping Testing Marketing
(c) Copyright 2000 Murray Turoff 103
Current Operational Systems User surveys Interviews of power users and
light users Monitoring current operations
Functions used Errors occurring Power users
(c) Copyright 2000 Murray Turoff 104
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.
(c) Copyright 2000 Murray Turoff 105
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
(c) Copyright 2000 Murray Turoff 106
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
(c) Copyright 2000 Murray Turoff 107
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
(c) Copyright 2000 Murray Turoff 108
System Design Actions Steering committee
Final determinationGo \ no goDelaySeek revisionPass up
AmountControversy
Usually formality Informal commitments crucial Battles settled before
(c) Copyright 2000 Murray Turoff 109
User Involvement
(c) Copyright 2000 Murray Turoff 110
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.
(c) Copyright 2000 Murray Turoff 111
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.
(c) Copyright 2000 Murray Turoff 112
Project Feasibility User Involvement
Project definition**@@ Cost justification Approval of cost justification** Developed Information
requirements Approval of Information
requirements Use to obtain information
requirements
(c) Copyright 2000 Murray Turoff 113
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
(c) Copyright 2000 Murray Turoff 114
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**@@
(c) Copyright 2000 Murray Turoff 115
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**@@
(c) Copyright 2000 Murray Turoff 116
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
(c) Copyright 2000 Murray Turoff 117
Software Creation
(c) Copyright 2000 Murray Turoff 118
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
(c) Copyright 2000 Murray Turoff 119
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
(c) Copyright 2000 Murray Turoff 120
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.
(c) Copyright 2000 Murray Turoff 121
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
(c) Copyright 2000 Murray Turoff 122
Programming, Testing, Documentation II
Variabilities Management style Degree of talent State of hardware & software Moral & commitment Attitude of technical people
(c) Copyright 2000 Murray Turoff 123
Programming, Testing, Documentation III
Variabilities Relationships to user groups Degree of specialization Team structures
StandardEgolessSurgicalApprenticeshipBalanced
(c) Copyright 2000 Murray Turoff 124
Problem Projects (PP)
(c) Copyright 2000 Murray Turoff 125
Alternatives for Problem Projects
Revise completion date? Hire more staff? Increase overtime? Reduce requirements?
(c) Copyright 2000 Murray Turoff 126
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?
(c) Copyright 2000 Murray Turoff 127
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
(c) Copyright 2000 Murray Turoff 128
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
(c) Copyright 2000 Murray Turoff 129
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
(c) Copyright 2000 Murray Turoff 130
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
(c) Copyright 2000 Murray Turoff 131
Human Resource Management Model
Workforce size Organizational Learning New members Experience of group Hiring rate (perceived need) Turnover rate (result of stress)
(c) Copyright 2000 Murray Turoff 132
Software Production Model Software development rate Actual productivity
Process loss (schedule pressure, workforce)
Potential Productivity Learning
Quality assurance (AWS) Error rate Error detection
(c) Copyright 2000 Murray Turoff 133
Planning Model Adjustments to workforce &
schedule (AWS) Scheduled completion date
Forecasted completion dateSchedule pressure
(c) Copyright 2000 Murray Turoff 134
Control Model Perceived Productivity
Project tasks perceived completed (influence AWS)
Actual Productivity Accuracy of Measurement
Effort Perceived as still needed Perceived project size
(c) Copyright 2000 Murray Turoff 135
Basic Model Relationships Actual productivity = Potential –
Losses due to faulty processes Perceived productivity = Actual +
reductions in requirements – changes in requirements
(c) Copyright 2000 Murray Turoff 136
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
(c) Copyright 2000 Murray Turoff 137
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
(c) Copyright 2000 Murray Turoff 138
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
(c) Copyright 2000 Murray Turoff 139
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
(c) Copyright 2000 Murray Turoff 140
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
(c) Copyright 2000 Murray Turoff 141
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
(c) Copyright 2000 Murray Turoff 142
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
(c) Copyright 2000 Murray Turoff 143
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.
(c) Copyright 2000 Murray Turoff 144
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
(c) Copyright 2000 Murray Turoff 145
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
(c) Copyright 2000 Murray Turoff 146
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
(c) Copyright 2000 Murray Turoff 147
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
(c) Copyright 2000 Murray Turoff 148
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.
(c) Copyright 2000 Murray Turoff 149
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.
(c) Copyright 2000 Murray Turoff 150
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
(c) Copyright 2000 Murray Turoff 151
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
(c) Copyright 2000 Murray Turoff 152
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.
(c) Copyright 2000 Murray Turoff 153
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
(c) Copyright 2000 Murray Turoff 154
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
(c) Copyright 2000 Murray Turoff 155
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
(c) Copyright 2000 Murray Turoff 156
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
(c) Copyright 2000 Murray Turoff 157
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)
(c) Copyright 2000 Murray Turoff 158
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.
(c) Copyright 2000 Murray Turoff 159
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.
(c) Copyright 2000 Murray Turoff 160
Coordination in Software Development
(c) Copyright 2000 Murray Turoff 161
Problem of Scale/Size Encourages specialization Division of labor Compartmentalization Subgroup Cohesion Reduction of sharing Reduction of breath of experience Narrowness
(c) Copyright 2000 Murray Turoff 162
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
(c) Copyright 2000 Murray Turoff 163
Three Traditional Approaches to Coordination
Technical Tools Editors Languages Version Data bases
Modularization Formal Procedures
Version control Specification Languages Test Plans
(c) Copyright 2000 Murray Turoff 164
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
(c) Copyright 2000 Murray Turoff 165
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.
(c) Copyright 2000 Murray Turoff 166
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
(c) Copyright 2000 Murray Turoff 167
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
(c) Copyright 2000 Murray Turoff 168
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
(c) Copyright 2000 Murray Turoff 169
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.
(c) Copyright 2000 Murray Turoff 170
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
(c) Copyright 2000 Murray Turoff 171
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
(c) Copyright 2000 Murray Turoff 172
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.
(c) Copyright 2000 Murray Turoff 173
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
(c) Copyright 2000 Murray Turoff 174
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?).
(c) Copyright 2000 Murray Turoff 175
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
(c) Copyright 2000 Murray Turoff 176
Other Development Components
(c) Copyright 2000 Murray Turoff 177
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
(c) Copyright 2000 Murray Turoff 178
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
(c) Copyright 2000 Murray Turoff 179
Conversion File conversion User training Documentation review Operational acceptance trials Maintenance review Software review Prototyping Hardware delivery & installation Services expansion
(c) Copyright 2000 Murray Turoff 180
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
(c) Copyright 2000 Murray Turoff 181
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
(c) Copyright 2000 Murray Turoff 182
Software Maintenance Problems II
Machine requirements Storage & processing time System reliability Hardware & software Data integrity
(c) Copyright 2000 Murray Turoff 183
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?
(c) Copyright 2000 Murray Turoff 184
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
(c) Copyright 2000 Murray Turoff 185
THE END
CIS 679 Management Information Systems The Development Process The third notes set http://eies.njit.edu/[email protected]