MGT 7378 Advanced Systems Analysis

1
MGT 7378Advanced Systems Analysis DesignSue
CongerFall, 2001Background Review
2
Contact Information

• Office107 Augustine
• Phones
• UD 972.721.5063
• Cell 214.929.8430
• eMail
• UD sconger_at_gsm.udallas.edu
• AOL sconger_at_aol.com

3
Goals of this Course

• Develop an understanding of the complexities and
  issues of real-time system development.
• Develop your expertise in the analysis of
  real-time problems.
• Develop your ability to document and think of
  real-time problems using object-oriented methods
  and notational schemes.

4
Course Conduct

• 2 Exams Project
• 2/26 MidTerm Exam
• 4/9 Final Exam (cumulative)
• Project Class and individual

5
Texts

• Norman OO-SAD
• Carter Developing eCommerce Systems

6
My Teaching Method

• Lecture with discussion
• Practice in class
• Practice on your own

7
What does it take to develop a computer
application

• Hardware
• Software
• People
• Procedures

8
Hardware

• Tangible
• Manufactured
• Computer properties based on systems theory
• Input--gtProcess--gtOutput

9
Software

• Logical
• Engineered
• Does not wear out
• Customized
• Subject to change
• Many varieties

10
Software Varieties

• Systems software -- operating system -- traffic
  cop (e.g., TPF, VM/CMS, MVS, DOS, OS/2)
• Communications -- traffic cop for communications
  over distance (e.g., IMS/DC, TCAM, VTAM)
• Utility -- frequently used routines (e.g., sort,
  copy, print)
• Applications -- business, models/scientific, AI,
  embedded

11
Application

• A set of programs to automate some task
• Program -- set of computer instructions. Some
  applications have millions of instructions that
  need to be organized in a logical manner.
• SAD process -- business requirements are
  decomposed to obtain small chunks, resulting in
  modules of 50-200 lines of code, that perform
  some well-defined function that can be programmed
  and tested in isolation of all of the other
  modules.

12
Common Application Characteristics

• Data -- raw material of information, numbers and
  letters
• Data -- input, output, or stored/retrieved
• Processes -- sequence of instructions or
  conjunction of events that operate on data
• Constraints -- limitations on behavior and/or
  processing of entities
• Types -- prerequisite, postrequisite, time,
  structure, control, and inferential.
• Interfaces -- human (e.g., screen interaction),
  manual (e.g., reports), automated

13
Application Responsiveness

• Batch -- transactions are processed in groups...
  non-interactive
• On-line -- interactive dialogue but does not
  impact concurrent business events
• Real-time -- interactive and can affects
  concurrent decisions including the business event
  it documents

14
Business Application Types

• Organization levels have different information
  needs
• Operations -- transactions, current, accurate,
  unambiguous
• Management -- problem finding/solving, trend and
  what if analysis, mostly accurate historical
  data
• Executive -- strategic, future orientation,
  ambiguous, incomplete, not necessarily accurate
• Staff support -- knowledge of processes and
  reasoning through problems

15
Applications Types match Information Types

• Transaction - Transaction processing systems
  (TPS)
• General information retrieval - Query systems
• Problem finding/solving - Decision support
  systems (DSS)
• Decision making -- Group decision support systems
  (GDSS)
• Strategic -- Executive information systems (EIS)
• Staff Support -- Expert systems (ES)

16
Language generations and examples

• 1st - Machine language
• 2nd - Assembler
• 3rd - COBOL, FORTRAN, C, Java
• 4th - VB, Paradox, Access,
• dBase IV, Oracle, etc.
• 5th - Prolog, Lisp

17
Each application type has better and worse
languages in which it can be written.

• Batch - Cobol (TPS), Fortran (Scientific)
• On-line - C (TPS, DSS), Assembler (TPS, DSS)
• 4GL (query, small TPS)
• 5GL (ES)
• Packages (DSS, GDSS, EIS)
• Real-time (usually TPS or embedded) -- 1GL, 2GL,
  C, Ada, may use specialized OS, e.g., TPF

18
People

• The most difficult factor in SAD and app
  development
• The larger and more complex the project,
• The more specializations involved
• The more the communication overhead

19
Project Manager role

• Complementary/joint Activities to Sr.
  Technician(s)/SEs
• Project Planning
• Assigning Staff to Tasks
• Selecting Alternatives
• Liaison -- Project Sponsor, User, IS Management,
  Technical Staff, Operations, Vendors, Other
  Teams/Departments
• Personnel Management -- Hiring, Firing,
  Motivating, Career Path Planning, Training,
  Evaluating
• Monitor and Control -- Status monitoring and
  reporting, Change control, Standards, QA

20
Software Engineers -- Analysts, Designers,
Programmers, Senior technical staff

• Complementary/joint Activities to PM
• Project Planning
• Assigning Staff to Tasks
• Proposing and Selecting Alternatives for project
  life cycle, methodology, CASE tools, hardware,
  operating environment, software, language, etc.
• Software Engineers -- Application Activities
• Requirements elicitation (user liaison)
• Decomposition of requirements and translation
  into computer components
• Definition of computer database from user data
  requirements
• Testing that programs match requirements
• Implementation

21
User Activities

• All tasks negotiated with PM
• Overall responsibility and management of project
  work
• Provide/approve all functional requirements -
  data, processes, constraints, interfaces
• Screen/report design - contents and layout
• User documentation development
• User training
• Acceptance testing

22
Procedures

• Prescribe conduct of the process.
• Project Life Cycles -- gross work breakdown of
  application development work
• Methodologies -- procedures, documentation
  techniques, and thought processes that direct
  activities of each phase
• Testing Plans -- describe the strategies, types
  and detailed test plans for the project
• Project Management -- describes the time plan,
  staffing plan, budget, reporting and control
  mechanisms for managing the work
• Other -- e.g., use of technical environment,
  change control, etc.

23
Sequential (Waterfall) Life Cycle

• Initiation -- User request is activated
• Feasibility -- Determine financial, technical and
  organizational readiness, risks, technical
  alternatives evaluated and tentative approach ID
• Analysis -- Define detailed user functional
  requirements, what the application will do
• Design -- Translate user requirements into
  computer design, how for specific HW/SW
• Program/Unit Test -- Translate design into
  program code
• Test -- Find errors
• Requires strategy -- black box, white box,
  top-down, bottom-up
• Types of tests -- unit, integration, system,
  recovery, peak period, multi-user, etc.

24
Sequential Life Cycle -- continued

• Implement -- Turn over to users, place into
  production use, requires strategy (big bang,
  incremental by geography, function, other)
• Operate and Maintain -- Fix bugs, adapt to
  changing business requirements, make more
  efficient
• Retire -- Discontinue maintenance, transfer
  functions to a new application

25
Iterative Life Cycle Types

• Full Prototyping Life Cycle
• Proof of Concept Life Cycle
• Partial System Prototype Life Cycle

26
Learn-as-you-go Life Cycle
27
Methodology Classes

• Flesh out the life cycle phases by focusing
  attention and identifying decisions to be made
• Process -- Focus on data flows through processes
• Data -- Focus on data
• Object Focus on development of encapsulated
  data and processes
• Semantic (AI) Focus on reasoning processes

28
Computer-Aided Software Engineering Tools (CASE)

• Automate some or all of project documentation for
  
• - functional requirements,
• - design decompositions,
• program specification,
• code generation,
• testing, and
• maintenance.

29
Varieties of CASE

• Dumb -- paper/pencil alternative
• Semi-intelligent -- enforces local rules
• Intelligent -- enforces local and global rules,
  incorporates intelligent evaluation, integrated
  -- supports transformations (analysis --gt design
  --gt program code)

30
CASE Changes Project Work

• All documentation is on computer vs. meetings,
  verbal, typed/hand-written
• Forces top-down approach to documenting
  information vs. gather all information, then
  decide what to do with it
• Requires compliance with supported methodology to
  obtain intelligent advantages
• More esoteric technical documentation than
  traditional applications

31
CASE/Methodology Assumptions

• Technical environment definition and design are
  outside analytical scope
• Project management is outside analytical scope
• Functional requirements are correct and complete
• Customizing is done by the SE and project manager
  to fit project requirements

32
Traditional life cycle
33
Life cycle using CASE
34
Novice v. Expert

• And, learning new methods

35
Learning Characteristics

• Novices
• Local mental models
• Undirected search (trial and error)
• Surface Features
• Mental simulation of isolated functions
• Incomplete analysis
• Failure to integrate pieces into a whole ...
  design pieces
• Find a (any) solution

• Experts
• Global mental models
• Directed search
• Deep Structures
• Mental simulation of integrated functions and
  whole application
• Complete analysis deferring details, top-down
  thinking
• Integrated whole throughout the process ...
  design whole and add pieces
• Find the best solution

36
Goals of this Course

• Develop an understanding of the complexities and
  issues of real-time system development.
• Develop your expertise in the analysis of
  real-time problems.
• Develop your ability to document and think of
  real-time problems using object-oriented methods
  and notational schemes.