 |
| https://members.tripod.com/~ci620 |
CI-620 System Analysis and Design
Topics 01/29/98
Some Views of Systems
Laszlo and Bertalanffy--
Before Systems: atomistic view of compartmentalized specializations
after systems: holistic view of related complexities
before systems: Newton's clockwork physics dealt with simple organizations or mass chaos
after systems: Warren Weaver's science of organized complexity
Systems maintain themselves over time and over changing environment
see: Second Law of Thermodynamics: entropy increases over time
Systems achieve a dynamic (not static) steady state.
Systems achieve a parametric homeostasis (like a warm-blooded creature)
Closed and Open Systems
Systems involve feedback, servo-mechanisms, reiterative processes.
systems tend toward equifinality: a tendency toward a characteristic final state.
Is it robust? Flexible? Enabling or Restrictive?
Review of Reading Assignment
Shannon and Weaver's Communication Model.
Debons' EATPUT model.
Lecture
Systems Analysis (to break down) and Design (to build up)
We live in a designed world. (parkway, campus, etc.)
How is the engineering of IS different from other types of engineering?
1. Goal of software enginering: devising teachable, reproduceable, reusable techniques
2. Catastropic faliures of most engineering (skyscrapers, bridges, tunnels) are rare. Computer crashes are common. What's the difference?
3. Physical system have the range of possibility limited by physical forces; software faces no such forces and thus has a larger spectrum.
Problems in software Development
1. Productivity: labor intensive, high variability
time to produce system may exceed timeframe to implement
myth of the man-month: more people doesn't reduce time.
N people generate n(n-1)/2 communication paths,
so 4 people means 6 paths, 40 people means 780 comm paths.
2. Maintainability
software spends most of its service life in maintainence mode.
20% is error correction, 80& is adaptive/change
3. Project Management
55% of projects exceed budget
68% exceed schedule
88% are substantially re-designed
Solution: Formal Methodologies
1. Handling Complexity by imposing structure, narrowing scope, abstracting essentials, communicate graphically
2. Formal Methodologies introduce prior experience into the product
3. Characteristics of a good methodology: describable, repeatable, teachable, widely applicable, produces better results
4. Produces greater control over status, time/cost/quality, benefits
Software life cycle models
- Why a life cycle model?
- defines activities
- introduces consistency
- provides checkpoints for control
Users
- System Owner
- small organization: owner, president
- large organization: high level executive (vice-president)
- final authority on system
- overall "big picture" knowledge
- how the new system fits in with organization
- focused on business goals
- system integrity, security, control, legal issues
- Responsible User
- more of an operational manager: branch manager, supervisor
- detailed knowledge of day to day operations
- administrator for system output
- manages operations and training
- Hands-on User
- clerks, tellers, etc.
- data entry / output handling
- knowledge of operational procedures; data entry
- handle invalid data; exceptional situations
- Beneficial Users
- customer, client
- [indirectly] provides input / receives output
Project Life Cycle Activities
- Problem Definition
- Systems Analysis and Feasibility Study
- feasibility study
- documentation
- design dictionary
- goal: produce an essential model of the system to build built (focused on what the system is to do)
- goal: determine the feasibility of the proposed system; compare with alternatives
- inputs: charter; user policy & requirements; management & operational constraints
- inputs: system requirements & policies from users
- constraints from management
- outputs: charter to authorize Analysis activity; gives scope, goals and objectives;
- tentative cost/benefit report to management
- example: need better housing for expanding family; study alternatives of buying a new house vs. remodeling existing house
- outputs: structured specification (requirements specification); revised cost/benefit analysis
- example: meet with architect to discuss needs, draw model for project (blueprints)
- Systems Design
- Logical
- Physical
- goal: to produce a design specification (focused on how the system will meet the requirements specification)
- inputs: requirements spec.; operational & management constraints
- output: design spec., incl. user implementation model, database design and program design
- Procedure Description
- goal: To describe procedures need to use the system
- inputs: requirements specifications
- output: user manual
- System Development / Design Implementation
- goal: to produce a working system
- inputs: design specification
- output: integrated system
- System Testing
- goal: to produce test strategies and test cases
- inputs: requirements specification
- output: QA test set
- goal: To test if the actual system meets its specifications
- inputs: test set, user manual, integrated system
- output: accepted system
- System Implementation
- Installation
- goal: Make system available in its operating environment
- inputs: accepted system, converted databases
- output: installed system
- Database Conversion
- goal: To convert existing data to new format
- inputs: design specifications, existing files, databases
- output: converted files, databases
- Training
- Formal Review
- Project Modification and Enhancement
- System Maintenance
Intro to Modeling
- The Essential Model
- Shows the user's essential business functions and essential data without respect to how those functions are done or how data is stored
- abstract--should be valid over long periods of time
- Properties of Good Models
- abstraction: inclusion of that which is important to the problem at hand, omission of the irrelevant and of too much detail
- example-- maps:
- topographical maps emphasize physical features (drainages,
elevations), omit or downplay man-made features
- street maps emphasize roads, parks, maybe buildings, but omit
geographic detail
- graphical notation
- transparency
- hierarchical
- top level model shows "big picture"
- lower level models expand on top level with more detail
- example: road atlas
Project Life Cycle Issues
- Goal: to produce a correct and reliable working system that meets the user's business objectives
- Correctness Issues:
A correct system meets its specifications
- validation: Are we building the right system?
- example: you want more bedroom space, but architect comes up with plan to expand playroom space
- example: trying to use a topo map to find a street address
- verification: Are we building the system right?
- example: blueprint for expanded area violates setback requirements
- example: street names are incorrect on street map
- traceability: every requirement is implemented in the working system and every part of the working system is there because and only because it is required to meet a requirement
- forward traceability: for every requirement in the system
specification you can trace forward to the programs/modules/code
segments that implement that specification
note: necessary but not sufficient condition for correctness
- backward traceability: every part of the working system can be
traced back to some requirement
note: no undocumented or unrequested "features"
- Freezes
- Defines the end of an activity (e.g. requirements, design). A formal process is required to make modifications after a freeze.
Rhetoric
- Purposeful, Persuasive Communication
- ethos: ethics/credibility
- logos: logic
- pathos: feelings
- some might add: chronos
Handouts Distributed
- The Lever of Knowledge, Information Week Oct. 20, 1997
- WallStreet.com, Wired Feb. 1998
