is#systems_analysis_and_design_domain
 subdomain of: #information_science,
 object: is#course_of_system_analysis_and_design
         is#system_analysis_and_design_related_process
         is#system_analysis_and_design_agent
         is#document_or_structure_for_system_analysis_and_design
         is#system_analysis_and_design_tool;

   is#course_of_systems_analysis_and_design   supertype: #course,
    subtype: gu#1015INT  gu#7007INT;

is#project_requirement  
 definition: "business objectives that drive the work"
             "policies describing the nature of the business, the market, and the
              environment it operates in"
             "rules and processes governing business practice"
             "data storage and processing requirements"
             "order, timing and impact of key events",
 subtype: is#project_outcome_requirement;

  is#project_outcome_requirement
   subtype: is#project_deliverable,
   definition: "what we want to achieve/produce"
               "what does the business do (and why, and how)?"
               "what does it want to do (and why, and how)?"
               "what will our information systems need to do to address these?";

    is#project_deliverable
     definition: "information from interviews, questionnaires, notes, minutes ..."
                 "various existing information documents - business objectives,
                  procedures, forms, reports, requirements collected during operation
                  of existing systems ..."
                 "computer-based information - screenshots, prototyped forms, design 
                  of existing database or process applications ..."
                 "requirements documentation!";

is#project_cost 
 subtype: {is#tangible_cost  is#intangible_cost}  {is#startup_cost  is#recurring_cost}
          {is#project_development_cost  is#project_operational_cost};

  is#recurring_cost
   annotation: "time dependency of recurring benefits and costs: 
                a dollar today is worth more than a dollar tomorrow,
                costs change e.g. interest rates, inflation, Moores Law, currency fluctuations,
                benefits can decay or increase over time";

  is#project_development_cost
   annotation: "staff salaries, equipment and installation, software and licenses,
                consulting and other third party fees, training, facilities,
                utilities and tools, support staff, travel and misc expenses";

  is#project_operational_cost
   annotation: "hardware and software maintenance and upgrades, connectivity costs,
                programming, 'Management' overhead (including change requests,
                configuration control, documentation), sysadmin and 'helpdesk' support,
                training, consumables";

is#system_analysis_and_design_related_process 
 subtype: is#system_analysis_and_design_task
          is#planning_and_managing_an_information_system_project,
 agent: is#system_analysis_and_design_agent;

  is#system_analysis_and_design_task
   subtype: is#task_of_traditional_system_development_life_cycle
            is#rapid_application_development  //prototyping approach
            is#object_oriented_method_of_system_analysis_and_design
            is#end-user_project_development  is#evolutionary_project_development,
   annotation: "there is no 'best way'; choose the 'most appropriate way', being mindful 
                of the strengths and weaknesses of each";

is#planning_and_managing_an_information_system_project
 annotation: "why, what, when, where, who and how",
 part: is#project_initiation_and_planning  is#project_execution  is#project_close_down,
 input: is#project_requirement,
 object: #project;

  is#project_initiation_and_planning
   successor: is#project_identification_and_selection  is#project_analysis,
   definition: "establishment of scope, feasibility and resources",
   output: "statement of work (an overview for the 'customer')",
   subtype: is#project_initiation  is#project_planning;

    is#project_initiation
     part: "addressing the most important 'why'" 
           "establishing of initial resources, team, resources, ..."
           "creating plans (initiation, scoping and/or feasibility studies, ...)"
           "management procedures, customer relationships, project workbook,
            environment (influenced by development model options), ...";

    is#project_planning
     part: is#project_feasibility_assessment  is#project_resource_usage_estimation
           is#manage_risk,
     annotation: "defining scope, feasibility, alternatives"
                 "project schedule, detailed resource estimating and planning"
                 "various plans (communications, test, ... )"
                 "standards and procedures, risk assessment"
                 "detail of agreed development models, management procedures and environment",
     output: "statement of Work (an overview for the customer)" is#baseline_project_plan
             "project review and decision on whether or not to proceed, and how";

  is#project_execution
   definition: "execute and manage your plan, with all the attendant resource, personnel,
                monitoring, organisational and technical change management, communication, 
                QA and documentation issues";

  is#project_close_down
   definition: "transition to either: operation, oblivion, 
                reviews of project management or the project itself,
                people, resource, contractual and numerous other issues";

is#project_feasibility_assessment
 annotation: "criteria: economic, technical, operational, schedule, legal and contractual,
              political (organisational and cultural)",
 subtype: is#project_economic_feasibility_assessment
          is#project_technical_feasibility_assessment 
          is#project_operational_feasibility_assessment
          is#project_schedule_feasibility_assessment
          is#project_legal_and_contractual_feasibility_assessment
          is#project_political/organisational/cultural_feasibility_assessment;

  is#project_economic_feasibility_assessment
   annotation: "an assessment of financial benefits and costs associated with the project"
               "must identify and quantify benefits and costs at least to the point where
                meaningful comparisons between projects can be made",
   part: is#cost/benefit_analysis  is#cash_flow_analysis,
   method: is#project_economic_feasibility_assessment_technique;

    is#cash_flow_analysis
     annotation: "usually needs to consider the cash flow issues of economic feasibility 
                  i.e. when is money needed, or when does it become available";

    is#project_economic_feasibility_assessment_technique
     subtype: is#net_present_value_analysis  is#net_present_value_analysis
              is#break-even_analysis;

      is#net_present_value_analysis__NPV_analysis  //the "__" means "synonym:"
       definition: "converting the future dollar amounts of costs and benefits into their 
                    current value, and compare the current values";

      is#net_present_value_analysis__ROI_analysis
       definition: "analysing the benefit achieved per dollar of cost";

      is#break-even_analysis__BEA_analysis
       definition: "analysing the amount of time required for the cumulative value of 
                    benefits to equal or exceed the cumulative costs";

  is#project_technical_feasibility_assessment
   issue: "Does it require a research breakthrough?"
          "Does it introduce new development technology?"
          "Does it introduce new application technology?"
          "Is it a large and complex project?"
          "Are we likely to be short of the people we need (skills and numbers)?"
          "Is there a low level of structure and understanding of the business 
           processes and requirements?";

  is#project_operational_feasibility_assessment
   annotation: "related to technical and organisational feasibility in many models"
               "concerned with extent to which proposed system will meet organisational
                goals and its effect on structures and processes";

  is#project_schedule_feasibility_assessment
   annotation: "can we meet the development milestones? A simple test is: Did you 
                developed the schedule without regard to externally imposed constraints
                and deadlines? If NO, you must consider the schedule to be a high risk
                component of your project";

  is#project_legal_and_contractual_feasibility_assessment
   annotation: "legal E.g. copyright, nondisclosure, financial reporting, misc minor legislation"
               "contractual E.g. development/testing/documentation requirements";

  is#project_political/organisational/cultural_feasibility_assessment
   annotation: "how do various stakeholders (both within and without the organisation)
                view the proposed system?"
               "Issues: computer competency, perceived shifts in control and power,
                concerns about job security and prospects, changes to established
                procedures and responsibilities";

is#project_resource_usage_estimation
 annotation: "gather a consensus: a mean or median of estimates from a number of people
              will usually prove more accurate than a single estimate, e.g. the 
              DELPHI method",
 trap: "optimistic estimation"  "the 'Mythical Man Month' problem"
       "the bill for documentation, testing and training"
       "pressures to estimate in conformance with desires and the 'can do' problem"
       "allowing your estimate to be treated as an opening position in a negotiation 
       process"  "the idea that 'we will make up this phase' slippage in subsequent phases"
       "the effect of changes in scope or requirements",
 subtype: is#project_cost/benefit_estimation
          is#project_amount_of_work_estimation
          is#project_resource/constraint_estimation;

  is#project_amount_of_work_estimation
   method: is#project_amount_of_work_estimation_technique;

    is#project_amount_of_work_estimation_technique
     subtype: is#project_decomposition  is#project_estimation_via_an_estimation_model
              is#project_estimation_via_function_point_analysis;

      is#project_decomposition 
       definition: "breaking the task into smaller subtasks, and estimate each individually";

      is#project_estimation_via_an_estimation_model
       annotation: "various modeling environments to help predict work requirements"
                   "tend to be highly proprietary and somewhat secretive"
                   "uses numerous different input parameters"
                   "from input parameters, predict resource usage and development effort"
                   "Eg. Constructive Cost Model: COCOMO, Boehm 1981";

      is#project_estimation_via_function_point_analysis
       annotation: "essentially, a modeling technique"
                   "determine number of function points: inputs, outputs, internal files,
                    external files, system query environments"
                   "look up history of prior projects with comparable function points";

is#task_of_traditional_system_development_life_cycle__SDLC_task
 annotation: "the SDLC is more aligned with corporate management models than  
              other system development methods are"
             "there are many Standard Model for Traditional SDLC but when we look closely
              into these, there are far fewer differences than similarities",
 subtype: is#project_identification_and_selection
          is#project_initiation_and_planning  //detailed in a previous sub-section
          is#project_analysis  is#project_analysis_subtask
          is#project_design  is#project_implementation_and_maintenance,
 output: "a functional system (software, hardware, procedures, trained users)"
         "documentation about the system itself (specifications), about the 
          development process, about the use of the system (procedural manuals,
          user guides and training manuals)";
  
  is#project_identification_and_selection
   successor: is#project_initiation_and_planning,
   successor of: is#project_maintenance,
   output: "mandate to continue to the NEXT PHASE"
           "commitment of the resources necessary for the next phase only!"
           "identification and selection of needs (ideally, a whole-of-enterprise
            analysis e.g. SWOT), priorities, resources"
           "decision on what to proceed with",
   subtype: is#project_identification  is#project_selection;
   
    is#project_identification
     annotation: "how do potential development projects arise?"
                 "top down (usually focuses on supporting what we want to do)"
                 "bottom up (usually focuses on supporting what we currently do,
                  and how we currently do it)"
                 "from the IS Department (usually focuses on improving efficiency
                  of IS support)";

    is#project_selection
     annotation: "to select, we must assess/classify/compare/rank projects via criterias:
                  value chain analysis, strategic alignment, preliminary assessment of
                  various aspects of feasibility, ...";
  
  is#project_analysis 
   successor: is#project_initiation_and_planning  is#project_logical_design,
   annotation: "detailed study of needs, current procedures and information systems",
   requirement: "the organisation has identified a number of potential projects and selected one"
                "some work effort has already gone into identifying the project, scope,
                 feasibility, budget and broad total work effort i.e. Planning"
                "the Senior Management has reviewed the project, and given approval to proceed",
   part: is#project_analysis_subtask;
    
    is#project_analysis_subtask
     subtype: is#determining_project_requirements  
              is#structuring_project_requirements
              is#generating_and_selecting_project_design_strategies
              is#updating_the_baseline_project_plan;
  
  is#project_design
   part: "addressing how we intend to do and represent it"
         "addressing: system interfaces and interactions, database design,
          program and module design and specification, system architecture",
   subtype: is#project_logical_design  is#project_physical_design,
   output: "detailed system specifications";
  

is#determining_project_requirements
 output: is#project_requirement,  //detailed in the first section of this document
 method: is#traditional_method_of_requirements_determination
         is#new_method_of_requirements_determination;

  is#traditional_method_of_requirements_determination
   subtype: is#interviewing  is#using_questionnaires  is#direct_observation
            is#analysing_procedures_and_documents;

    is#interviewing
     guideline: "plan the interview - individual or group, who, consider desired outcomes,
                 recording/documentation, followup and feedback processes, ..."
                "prepare! - both yourself and the interviewee: when, where, for how long,
                 what you will be asking, design interview form ..."
                "listen and 'record' (you are there to find out their views, not express
                 your own!), and document as soon as possible"
                "take care about raising expectations (and the problem of 'active listening')"
                "allow adequate time between interviews for documenting, redesigning interview etc"
                "'close the loop'",
     object: is#interview; //see details below in the data/document structure section

    is#using_questionnaires
     object: #questionnaire,
     annotation: "generally more 'efficient' than interviews but less rich in information
                  response" "generally tend towards more closed questions",
      requirement: "need greater care to avoid ambiguity or biased sampling";

    is#direct_observation
     rationale: "there is often a significant disparity between what people think they do
                 (or would like you to believe that they do) and what they actually do
                 (and how they do it); direct observation can detect this and other 
                 inadvertent omissions",
     requirement: "for direct observation to work effectively, you will need to be
                   more than a passive observer (but beware of the observer influencing
                   the observed!)"  "plan observation to avoid bias (e.g. different people,
                   different levels, different times)";

    is#analysing_procedures_and_documents
     subtype: is#analysing_existing_business_documentation;

      is#analysing_existing_business_documentation
       definition: "analysing mission statements, organisational objectives, business plans,
                    organisational charts, duty statements and job descriptions,
                    procedural manuals, training manuals, business forms,
                    current system design documentation, ...",
       requirement: "beware of the difference between formal/informal systems and processes!";
  is#new_method_of_requirements_determination
   annotation: "generally, we embark on these when entering new and/complex areas, 
                when we think the processes and requirements are not well understood, when
                we need to re-think not only how we do things, but what we do, and why",
   subtype: is#Joint_Application_Design  is#requirements_determination_via_prototyping;

    is#Joint_Application_Design__JAD
     annotation: "structured meeting involving representatives of all stakeholders"
                 "objective - to collect requirements"
                 "supported by some computer tools, such as CASE groupware products
                  (but can use variety of general support software)";

    is#requirements_determination_via_prototyping
     annotation: "various types ranging from simple forms to full functional prototypes"
                 "even with simple prototypes, we want to investigate process, not just 
                  appearance!";

is#structuring_project_requirements
 subtype: is#process_modeling  is#data_modeling  is#logic_and_timing_modeling,
 object: is#project_model,
 input: "information from Requirements Determination";

  is#process_modeling
   annotation: "what processes exist (i.e. what does this system actually do, and how does
                it do it)? what information do these processes use or produce?",
   object: is#process_model;

  is#data_modeling
   annotation: "detail the data definitions, structure or relationships"
               "needed for the design of programs, data bases, forms, reports etc"
               "starts with a data model of the existing system (not information system!)
                and supplement with other information from Requirements Determination";

  is#logic_and_timing_modeling
   annotation: "represents the internal structure and functionality of a process",
   requirement: "must be complete and detailed"
                "must be generic, i.e. not represent specific syntax of a product/environment",
   instrument: is#logic_and_timing_model;

is#generating_and_selecting_project_design_strategies
 subtype: is#generating_project_design_strategies  is#selecting_project_design_strategies,
 output: is#project_design_strategy;

  is#project_design_strategy 
   subtype: is#minimalist_design_strategy is#maximalist_design_strategy
            is#realistic_compromise_design_strategy,
   definition: "high level statement about our approach to developing a system",
   annotation: "deals primarily with: scope and functionality, method of acquisition, and
                implementation environment";

  is#generating_project_design_strategies
   definition: "identifying strategy alternatives is needed to investigate what is 'best'
                for the organisation, what can it manage at this time, what does it
                want to do in the future, ..."
                "identifying strategy alternatives is needed to avoid re-design efforts
                 later, misunderstanding about the goal of the project, ...",
   requirement: "must consider: system features, information needs, functionality, 
                 modes of output, timeliness, development constraints, timeframe,
                 organisational commitment, resources, business environment issues";
  
  is#selecting_project_design_strategies
   annotation: "focus on a small number of feasible alternatives (because we need to 
                analyse and describe these in detail)"
               "the 3 most common alternatives will represent (at least in terms of
                scope and functionality, and usually environment):
                1) minimum, 2) maximum, 3) realistic compromise",
   subtype: is#selecting_the_best_project_design_strategy;

    is#selecting_the_best_project_design_strategy
     requirement: "any alternative selected to be the best must: (i) adequately address at 
                   least the minimum requirements, (ii) be technically and financially
                   feasible with attractive total cost of ownership, (iii) meet the 
                   organisation's timeframe requirements",
     method: is#cost/benefit_analysis  is#weighted_assessment_criteria_method
             is#constraint_satisfaction/optimisation_approach,
     agent: "the organisation/business with advice from PM, Analysts and/or IT Management",
     successor: is#updating_the_baseline_project_plan;

      is#updating_the_baseline_project_plan
       object: is#baseline_project_plan;

is#project_logical_design
 successor: is#project_analysis  is#project_physical_design,
 successor of: is#project_physical_design,
 part: is#designing_forms_reports_and_interfaces  is#logical_database_design,
 annotation: "what is this system going to do: system functionality, process support, ...?"
             "describing a solution without regard to physical implementation issues,
              limits and constraints (business level representation of how requirements
              will be met with a solution)",
 rationale: "those who build it probably won't have been involved in designing it (and
             those who maintain it will be different again, and those who design and
             build its replacement will be different again)",
 output: "justification or explanation"
         "a narrative overview (essentially the who, what, when, where, why, how etc)"
         "design itself (sample?)"  "information testing and assessment";

  is#designing_forms_reports_and_interfaces
   requirement: "based on user and task requirements"
               "needs to address: who, what, when, where, why, how etc"
               "feedback on design from users (prototype?)",
   object: is#form_created_by_project_design  #report  #user_interface,
   guideline: is#report/interface_general_formatting_guideline;

    is#form_created_by_project_design 
     annotation: "the data elements of the form or report relate to components of 
                  data stores and E-R data models";

    is#report/interface_general_formatting_guideline 
     subtype: is#user_interface_design_principle,
     purpose: "for achieving consistency, efficiency, speed, accuracy, satisfaction,
               ease of use, ...",
     #measure: "time to learn, speed of performance, error rate, retention, satisfaction",
     instance: "highlighting, colour, use of text, table or graphical presentation"
               "do not undervalue 'common look and feel'"
               "be careful of inducing or reinforcing bias (both theirs and your!)"
               "provide assistance to users (error and valid response checking,
                selection menus, 'default' responses, help files, maybe speech recognition,
                dictionary and thesaurus services)";

      is#user_interface_design_principle
       object: #user_interface,
       subtype: is#consistency_oriented_user_interface_design_principle
                is#forgiveness_oriented_user_interface_design_principle
                is#feedback_oriented_user_interface_design_principle;

        is#consistency_oriented_user_interface_design_principle
         example: "present common functions using the same interface";

        is#forgiveness_oriented_user_interface_design_principle
         example: "allow for interactive discovery"  "allow for trial and error"
                  "allow user to undo what has just been done";

        is#feedback_oriented_user_interface_design_principle
         example: "confirm the system is responding to input"
                  "a user interface should be timely and near the point of activity";

  is#logical_database_design
   part: is#relational_database_normalisation
         "represent entities (identifier becomes primary key, other attributes become
          non-key attributes of the relation)"
         "represent relationships (e.g. the primary key of one relation becomes a foreign key of another)"
         "normalise relations"  "merge (and re-normalise) relations (if appropriate)",
   object: is#logical_data_model,
   output: "a normalised data model of our system that conforms to our chosen database
            technology (commonly, relational)";

    is#relational_database_normalisation
     subtype: is#relational_database_normalisation_in_3NF;

      is#relational_database_normalisation_in_3NF
       object: is#relational_database_third_normal_form__3NF,
       output: "every nonprimary key attribute depends upon the whole primary key,
                and nothing but the primary key";

is#project_physical_design
 successor: is#project_analysis  is#project_physical_design,
 annotation: "how the system is going to meet the requirements (choice of language 
              and development environment, physical infrastructure choices, ...)?"
             "maps the Logical Design to the implementation environment",
 output: "technical specification of how solution will actually be physically implemented",
 subtype: is#physical_file/database_design  is#system_and_program_structure_design
          is#distributed_system_design,
 object: is#system_structure  is#program_structure  is#system_architecture;

  is#physical_file/database_design
   purpose: "translate the logical database design into technical specifications for implementation",
   part: "defining attribute data types (fields)"
         "determining the physical record structure"
         "organising files for secondary storage devices"
         "selecting and allocating the storage databases and devices",
   object: is#physical_file  is#system_structure is#data_schema  is#physical_data_base 
           is#file_organisation/index;

  is#system_and_program_structure_design
   definition: "group the system processes (modeled by Data Flow Diagrams) into modules
                (a module is a relatively small functional unit of a system, with high
                 cohesion and low coupling; commonly represent using Structure Charts)",
   guideline: "modular and hierarchical"
              "each module should control a small number of subordinate modules"
              "each module should be relatively independent (low coupling)"
              "relatively cohesive (one function)" "relatively small in size"
              "as generic as possible",
   output: is#output_document_of_program_design;

  is#distributed_system_design
   part: "choosing a network architecture (homogeneous/heterogeneous networks; 
           applications - distributed, client/server, central server etc)"
         "managing data (file servers, distributed or replicated databases,
          how to ensure integrity and security)"
         "separating application and data through middleware technology?";

is#project_implementation_and_maintenance
 part: is#project_implementation  is#project_maintenance  is#security_management,
 annotation: "implementation and maintenance are the two largest, longest and most 
              expensive phases";

  is#project_implementation
   successor: is#project_physical_design  is#project_maintenance,
   purpose: "to convert system specs into functioning and reliable system, with 
             documentation and adequate support services",
   annotation: "second largest and most expensive phase"
               "largest number and widest variety of personnel involved",
   subtype: is#coding  is#testing  is#documenting_the_project_implementation
            is#training_related_to_an_IS_implementation
            is#design_support_related_to_an_IS_implementation
            is#installation_related_to_an_IS_implementation
            is#close_down_of_project_installation; 

    is#coding
     definition: "coding turns the physical design specs into functional computer code",
     part: "documenting while coding"
           "many programmers, many modules, many changes -> how to keep track? 
            importance of module libraries and revision control";

    is#testing
     annotation: "testing approach and procedures are formulated before implementation starts",
     output: is#master_test_plan,
     part: is#quality_assurance;

      is#quality_assurance 
       part: is#unit_testing  is#integration_testing  is#system_testing
             is#testing_user_acceptance;

        is#unit_testing
         agent: is#programmer,
         part: "testing a module or subportions as the coding progress"
               "checking at completion that it meets the specification requirements"
               "technical walkthroughs";

        is#integration_testing
         agent: "the IT section",
         object: "all the modules together (do they co-operate correctly as a system?)",
         requirement: "usually requires separate environment and data"  "migration procedures";

        is#testing_user_acceptance
         agent: is#user,
         definition: "tests the system is acceptable as far as the users are concerned:
                      Does it do what the users want (functionally)? Does it fail-safe
                      and recover? Is it robust and tolerant of user errors? Is it secure?
                      Does it meet performance requirements?",
         annotation: "separate acceptance test environment and data";


    is#documenting_the_project_implementation 
     definition: "review and update business documentation made during the analysis and 
                  design phases",
     object: is#documentation_of_the_project_implementation;  //details in a section below

    is#training_related_to_an_IS_implementation
     part: is#user_training_related_to_an_IS_implementation
           is#technical_staff_training_related_to_an_IS_implementation
           "notify customers of changes and help them adapt";

      is#technical_staff_training_related_to_an_IS_implementation
       part: is#file_back-up_and_recovery  is#data_file_maintenance;

    is#design_support_related_to_an_IS_implementation
     part: is#technical_support_related_to_an_IS_implementation
           is#help_desk_related_to_an_IS_implementation;

      is#technical_support_related_to_an_IS_implementation
       part: "help with machine usage"  "assist with operating system problems";

      is#help_desk_related_to_an_IS_implementation
       part: "assist with system usage" 
             "can also act as job initiation point for tech support";

    is#installation_related_to_an_IS_implementation
     part: "transferring from the 'old' system to the new"
           "hardware and network rollout"
           is#data-conversion_related_to_an_IS_implementation
           "software rollout or migration",
     method: is#direct_installation_of_an_IS  is#parallel_installation_of_an_IS 
             is#phased_installation_of_an_IS  is#pilot_installation_of_an_IS;

      is#data-conversion_related_to_an_IS_implementation
       part: is#data_conversion  is#data_mapping  is#data_cleansing  is#data_transfer
             is#audit;

      is#direct_installation_of_an_IS
       part: "complete old to new system transfer",
       characteristic: "highest risk" "one time for whole of organization"
                       "minimum transfer effort";

      is#parallel_installation_of_an_IS
       part: "run old and new together until management deems old can be eliminated",
       characteristic: "minimizes risk"  "requires greater effort and resources";

      is#phased_installation_of_an_IS
       part: "change from old to new incrementally"  "start with some functionality"
             "continue in portions until all functionality 'transferred' to new system";

      is#pilot_installation_of_an_IS
       part: "try out the new system at one location"  "evaluate system readiness";

    is#close_down_of_project_installation
     requirement: "successful implementation",
     part: "obtaining customer satisfaction"  "post-project review"
           "project staff re-allocation";


  is#project_maintenance
   part: "keeping the system running as intended"  "correct/prevent faults"
         "adding new and/or improved functions"  "adapt to changing environment"
         "improve function or performance" "help users"  "documenting! "
         "never losing sight of the meaning of 'System'" 
         is#configuration_management_and_control,
   method: "change requests" "approve or reject changes"  "re-cycle through SDLC"
           "plan, analyze, design, implement"
           "this requires configuration management",
   characteristic: "the most expensive component of system life cycle cost
                    (Pressman suggests 70-80% of system lifecycle cost!)",
   annotation: "good analysis and design and documentation is paid for many times 
                over by subsequent reduction in maintenance costs"
               "currently more programmers involved in maintenance than development!"
               "current and future trend: decrease in on-site maintenance";

    is#configuration_management_and_control
     part: "keeping current system documentation up to date (part of configuration
            management and control)"   "planning ahead, and capture new requirements"
           "ensures only authorized changes are made to a system"
           "tracks state of current changes"  "traces history of changes"
           "authorizes programmers to have modification rights to certain modules",
     annotation: "system librarian oversees 'check-ins / outs'"
                 "some case tools have their own library control systems e.g. Cool-Gen";

  is#security_management
   part: "control access"  "backup and recovery - data and software",
   characteristic: "highly valuable for corporate information and corporate information systems";

is#rapid_application_development
 definition: "normally used for referring to approaches which use the 'prototype' as the
              final operational system"
             "a collection of approaches, techniques and tools aimed at reduced
              development times, rather than a specific methodology",
 purpose: "rapid identification of business problem and development and deployment of solution"
          "close cooperation between developers and users"
          "availability of prototyping and development tools",
 advantage: "extensive end-user involvement, leading to better end-solutions"
            "powerful development and prototyping tools (e.g. CASE code generators, 4GLs),
             allowing short development cycles"  "can result in significant cost savings",
 drawback: "nothing can be cheap, quick and good (and RAD isn't always necessarily cheap
            anyway!)"  "the almost complete focus on what the user wants will reduce
            opportunities for BPR"  "often fails to address important system requirements 
            (e.g. standards, documentation, consistency, scalability, security,
             maintenance etc)"  "can be very difficult to process, manage and forecast";

is#object_oriented_method_of_system_analysis_and_design
 annotation: "approach has been likened to more like an onion (contrast to the waterfall
              SDLC model)"  "progressive layers of system detail, starting with external
              qualities of the system, and continuing through to how the system will
              function and how it will be built"
              "models objects, encapsulating both data and behaviour",
 method: is#UMLS  is#Use_Cases_method;

  is#Use_Cases_method
   annotation: "represent functional requirements, what the system should do"
               "the Use Case represents a specific way of using the system: usually as
                a sequence of related actions to achieve some outcome or goal",
   support: is#object-oriented_diagram;

is#system_analysis_and_design_agent 
 subtype: is#system_analysis_and_design_project_manager
          is#system_analysis_and_design_content_expert  
          is#system_analysis_and_design_programmer   is#instructional_designer 
          is#system_analyst;

  is#system_analyst
   requirement: "must understand the entire process of systems development, as well as the
                 specific methodologies of structured analysis and design"
                "must have a knowledge of the business domain"
                "must have analytical skills to identify how that business domain might
                 benefit from IS Development"
                "must have management skills - to manage the development of the IS"
                "must have technical IT/IS skills"
                "must have teamwork and interpersonal skills";

is#document_or_structure_for_system_analysis_and_design 
 subtype: is#interview  is#object-oriented_diagram  is#project_plan
          is#data_structure_for_project_plan  is#project_model  is#data_flow_diagram
          is#output_document_of_program_design  is#data_structure_for_program_design
          is#test_plan  is#documention_of_the_project_implementation;

  is#interview  //Week 5
   subtype: is#interview_with_open-ended_questions  is#interview_with_closed-ended_questions
            is#individual_interview  is#group_interview;

    is#interview_with_open-ended_questions
     annotation: "does not suggest answers; e.g. 'What do you consider are the best aspects
                  of the current system?' or 'What do you think the main features of the 
                  new system should be?'";

    is#interview_with_closed-ended_questions
     annotation: "suggests YES/NO answers, or constrains respondees to YES/NO answers,
                  or constrains respondees to choose from (or rating) your suggestions"
                 "particular care needs to be taken with Closed questions to not
                  'pre-condition' the response'",
     example: "Is the current system good?" 
              "Which of the following features do you think the new system should have
               (then list the options)?"
              "Rate each of the following features on a scale of 1 (must have) to 5 
               (don't need) ...";

    is#individual_interview 
     annotation: "in general better than group interviews because not dominated by the
                  loudest voice, the strongest personality or the highest position,
                  but Harder to schedule and 'keep on track' and less 'efficient'"
                 "do not allow interaction and discussion between interviewees";


  is#object-oriented_diagram
   subtype: is#object-oriented_class_diagram is#object-oriented_state_diagram
            is#object-oriented_sequence_diagram;

    is#object-oriented_class_diagram
     annotation: "represents static structure of the OO model: the object classes
                  themselves and their relationships";

    is#object-oriented_state_diagram
     definition: "dynamic models of how objects change over time";

    is#object-oriented_sequence_diagram
     definition: "dynamic models of interaction between object";

  is#project_plan //Week 2
   use: "representation and scheduling" "'Work Breakdown', or activities, or tasks, ...",
   annotation: "some terms: Critical Path, Slack time, Completion times (earliest and
                latest expected), Estimated (completion) times - optimistic, realistic,
                pessimistic",
   subtype: is#baseline_project_plan,
   support: is#data_structure_for_project_plan;

    is#baseline_project_plan
     annotation: "addresses various elements of this phase in detail"
                 "formats vary between organisations, but a suggested structure is
                  Introduction, Description, Feasibility Assessment, Management Issues";

  is#data_structure_for_project_plan
   subtype: is#Gantt_chart  is#PERT_chart;

    is#Gantt_chart
     annotation: "task activities and durations, set against a timeline",
     use: "shows task chronological, not logical, sequence"
          "shows duration, set against a timeline, but not logical sequence";

    is#PERT_chart
     annotation: "task activities and their relationships" "reveals the 'critical path'",
     use: "shows logical sequence but 
           does not visually represent durations/timelines";

  is#project_model
   subtype: is#process_model  is#data_model  is#logic_and_timing_model;

    is#process_model   //Week 6
     support: is#data_flow_diagram;

      is#data_flow_diagram__DFD
       annotation: "most common form of Process Models"
                   "despite the name, DFDs have a process focus rather than a data focus"
                   "representation of all processes and all information stores, irrespective
                    of whether or not they are computerised",
       subtype: is#current_physical_DFD  is#current_logical_DFD
                is#new_physical_DFD  is#new_logical_DFD,
       part:  is#DFD_process__DFD_activity__DFD_function  is#DFD_data_store
              is#DFD_external_entity  is#DFD_data_flow  1 is#DFD_context,
       object of: is#CASE_tool;

    is#data_model   //Week 7
     subtype: is#logical_data_model,
     annotation: "describes the data that support the business processes"
                 "shows the entities/attributes corresponding to the data stores in DFDs"
                 "during Analysis, the data model presents the logical organisation of
                  data, without regard to how these data are stored, created or manipulated;
                  during Design, these data models are changed to reflect these details",
     part: is#data_model_entity  is#data_model_attribute  is#data_model_relationship
           is#attribute_of_data_model_element  is#data_model_triggering_operation;

      is#data_model_entity
       definition: "a meaningful business object or concept about which data is stored
                    e.g. a person, place, event or an object",
       annotation: "an Entity will have multiple instances or occurrences - e.g. for
                    the entity patient, instances might be John Smith and Jill Jones",
       subtype: is#associative_entity,
       attribute: is#data_model_attribute   1..* is#data_model_candidate_key;

        is#associative_entity__Gerund  definition: "relationship modelled as entity";

      is#data_model_attribute
       definition: "some type of information about entities, e.g. patient last_name, 
                    patient telephone_number",
       subtype: is#data_model_candidate_key,
       attribute: is#data_model_attribute_domain,
       object of: is#data_model_triggering_operation;

        is#data_model_candidate_key
         definition: "an attribute serving to uniquely identify an instance of an entity";

        is#data_model_attribute_domain
         definition: "data type or value that an attribute can assume (e.g. type, length,
                      format, range, uniqueness, allowable values, etc)";

        is#data_model_triggering_operation
         annotation: "a condition of a rule on an event such as for example 'insert'";

      is#data_model_relationship
       definition: "association between entities, e.g.: patient 'schedules' appointment",
       attribute: is#data_model_relationship_degree  is#data_model_relationship_cardinality
                  is#data_model_relationship_modality,
       subtype: {is#data_model_unary_relationship is#data_model_binary_relationship 
                 is#data_model_ternary_relationship};

        is#data_model_relationship_cardinality__data_model_relationship_maximum_cardinality
         definition: "the (maximum) number of times an instance of one entity can be 
                      related to instances of another entity",
         example: "a patient should have one and only one medical_history (1:1)"
                  "a patient may schedule many appointments but a particular appointment 
                   is only scheduled by one patient (1:M)"
                  "diseases can have many symptoms but symptoms can be associated with
                   many diseases (M:M)";

        is#data_model_relationship_modality__data_model_relationship_minimum_cardinality
         definition: "the minimum number of times an instance of one entity can be related
                      to instances of another entity, e.g. a person would only be entered 
                      as a patient when they made an appointment (thereby signifying a 
                      modality or minimum cardinality of one)";

    is#logic_and_timing_model //Week 8
     subtype: is#structured_English__pseudocode  is#decision_table  is#decision_tree;
 
      is#structured_English
       annotation: "this is a communication technique for Analysts and Users, while
                    pseudocode is a communication between Analysts and Programmers"
                   "must represent control features of structured programming:
	            sequence, conditional statements, repetition"  "no standard";

      is#decision_table
       definition: "a diagram of process logic" "a matrix representation of a logic decision",
       use: "used when the logic is complicated, and/or we need to ensure all case/outcomes
             are considered"  "specifying possible conditions and their resulting actions",
       subtype: is#nested_decision_table;


  is#output_document_of_program_design
   subtype: is#structure_chart  is#module_or_program_specification,
   support: is#data_structure_for_program_design;

    is#module_or_program_specification
     definition: "detailed description of module" "enough detail so programmer can code",
     support: is#pseudocode  is#flow_chart,
     part: "module common and technical name" "analyst and programmer name"
           "date received and due" "some business area context"  "list of requirements"
           "details of each requirement"  "unit test procedures"
           "references to site technical standards";

  is#data_structure_for_program_design
   subtype: is#pseudocode__pseudo-code  is#flow_chart  is#structure_chart_structure;

    is#flow_chart__flowchart
     definition: "a graphical Representation of structure of code",
     part: "symbols for sequence, condition/decision, repetition/recursion",
     subtype: is#Nassi-Shneiderman_flowchart;

    is#structure_chart_structure     
     definition: "hierarchical diagram displaying organization of an information system
                  (each box is a module)"
                 "each process on levelled DFD loosely corresponds to a module on a 
                  structure chart BUT, it is NOT NECCESSARILY a one to one correlation:
                  may need to add controlling modules, may split a process into more 
                  than one module",
      support of: is#structure_chart;

  is#test_plan
   subtype: is#master_test_plan;


  is#documention_of_the_project_implementation
   subtype: is#technical_documentation  is#user_documentation  is#training_documentation;

    is#technical_documentation
     subtype: is#internal_code_documentation  is#data_dictionary  is#module_library_index;

    is#user_documentation
     subtype: is#user_manual  is#template  is#online_help_text;

    is#training_documentation
     subtype: is#trainer_manual  is#course_note;

is#system_analysis_and_design_tool 
 subtype: is#automated_project_management_tool  is#CASE_tool;

  is#automated_project_management_tool
   annotation: "provides representational forms (e.g. Gantt, PERT) and much more",
   object: is#project_plan;

  is#CASE_tool
   annotation: "can help data modeling by (i) including names, descriptions, definitions,
                business rules etc in CASE repository and (ii) providing diagramming tools, 
                with 'links' between diagrams and CASE repository";