; An Introduction to Use-Case Modeling
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

An Introduction to Use-Case Modeling

VIEWS: 6 PAGES: 71

  • pg 1
									Dr Manolya Kavakli
Department of Computing
Macquarie University
Sydney, Australia

                          SYSTEM
                          DEVELOPMENT
       Systems Analysis Phases
• Scope Definition (Preliminary investigation) Phase
   – Is the project worth looking at?
• Problem Analysis Phase
   – Is a new system worth building?
• Requirements Analysis Phase
   – What do the users need and want from the new system?
• Logical Design Phase
   – What must the new system do?
• Decision Analysis Phase
   – What is the best solution?
Scope Definition Phase Context
Tasks for the Scope Definition Phase
Sample Request for System Services
Sample Problem Statements
        Scope Definition Phase
Steering body – a committee of executive business and
system managers that studies and prioritizes competing
project proposals to determine which projects will
return the most value to the organization and thus
should be approved for continues systems development.
– Also called a steering committee.
Project charter – the final deliverable for the
preliminary investigation phase. A project charter
defines the project scope, plan, methodology, standards,
and so on.
– Preliminary master plan includes preliminary schedule and
  resource assignments (also called a baseline plan).
– Detailed plan and schedule for completing the next phase of
  the project.
Context of Problem Analysis Phase
Tasks for Problem Analysis Phase
  Cause-and-Effect Analysis

Cause-and-effect analysis – a technique in
which problems are studied to determine their
causes and effects.
    In practice, effects can be symptomatic of more
    deeply rooted or basic problems which, in turn, must
    be analyzed for causes and effects until such a time
    as the causes and effects do not yield symptoms of
    other problems.
System Improvement Objectives
Objective – a measure of success. It is something that you
expect to achieve, if given sufficient resources.
   • Reduce the number of uncollectible customer accounts
     by 50 percent within the next year.
   • Increase by 25 percent the number of loan applications
     that can be processed during an eight-hour shift.
   • Decrease by 50 percent the time required to reschedule
     a production lot when a workstation malfunctions.

Constraint – something that will limit your flexibility in
defining a solution to your objectives. Essentially, constraints
cannot be changed.
   •   The   new   system   must be operational by April 15.
   •   The   new   system   cannot cost more than $350,000.
   •   The   new   system   must be web-enabled.
   •   The   new   system   must bill customers every 15 days.
Sample Cause-and-Effect
       Analysis
System Improvement Report




      Insert Figure 5-13
Context of Requirements Analysis
Tasks for Requirements Analysis
Functional vs. Nonfunctional
       Requirements
Functional requirement – a description of
activities and services a system must provide.
   • inputs, outputs, processes, stored data
Nonfunctional requirement – a description of
other features, characteristics, and constraints that
define a satisfactory system.
   • Performance, ease of learning and use, budgets, deadlines,
     documentation, security, internal auditing controls
Expressing System Requirements
• Draft Functional and Nonfunctional Requirements
  – Could use simple list of system improvement
    objectives
  – Increasingly systems analysts express functional
    requirements using Use Cases

    Use case – a business scenario or event for which the
    system must provide a defined response. Use cases
    evolved out of object-oriented analysis; however, their
    use has become common in many other methodologies
    for systems analysis and design.
Prioritize System Requirements
– Prioritization of requirements can be facilitated using
  timeboxing.
   Timeboxing – a technique that delivers information
   systems functionality and requirements through versioning.
   1. The development team selects the smallest subset of the system
      that, if fully implemented, will return immediate value to the
      systems owners and users.
   2. That subset is developed, ideally with a time frame of six to nine
      months or less.
   3. Subsequently, value-added versions of the system are developed in
      similar time frames.

   • A mandatory requirement is one that must be fulfilled by the
     minimal system, version 1.0
   • A desirable requirement is one that is not absolutely essential to
     version 1.0. It may be essential to the vision of a future version.
Context of Logical Design Phase
Tasks for Logical Design Phase
Context of Decision Analysis Phase
Tasks for Decision Analysis Phase
                  Feasibility
• Technical feasibility – Is the solution technically
  practical? Does our staff have the technical
  expertise to design and build this solution?
• Operational feasibility – Will the solution fulfill
  the users’ requirements? To what degree? How
  will the solution change the users’ work
  environment? How do users feel about such a
  solution?
• Economic feasibility – Is the solution cost-
  effective?
• Schedule feasibility – Can the solution be
  designed and implemented within an acceptable
  time period?
Candidate Systems Matrix




          (Continued)
Candidate Systems Matrix
Feasibility Matrix
Outline for a Typical System Proposal
              Outline for a Typical System Proposal
 I.     Introduction
         A. Purpose of the report
         B. Background of the project leading to this report
         C. Scope of the report
         D. Structure of the report
 II.    Tools and techniques used
         A. Solution generated
         B. Feasibility analysis (cost-benefit)
 III.   Information systems requirements
 IV.    Alternative solutions and feasibility analysis
 V.     Recommendations
 VI.    Appendices
 Systems Analysis and Design
         7th Edition

Chapter 10
Systems Implementation
          Phase Description
• Systems Implementation is the fourth of
  five phases in the systems development life
  cycle
• Includes application development,
  documentation, testing, training, data
  conversion, and system changeover
• The deliverable for this phase is a
  completely functioning information system
                                                29
          Chapter Objectives
• Explain the importance of software quality
  assurance and software engineering
• Describe the application development
  process for structured, object-oriented, and
  agile methods
• Draw a structure chart showing top-down
  design, modular design, cohesion, and
  coupling
                                                 30
          Chapter Objectives
• Explain the coding process
• Explain unit, integration, and system testing
• Differentiate between program, system,
  operations, and user documentation
• List the main steps in system installation
  and evaluation


                                                  31
         Chapter Objectives
• Develop a training plan for each group of
  participants, compare in-house and outside
  training, and describe effective training
  techniques
• Describe data conversion and changeover
  methods
• Explain post-implementation evaluation and
  the final report to management
                                               32
                 Introduction

• The system design specification
  – serves as a blueprint for constructing the new
    system
• The initial task: application development
• Before a changeover can occur,
  –   the system must be tested and
  –   documented carefully,
  –   users must be trained, and
  –   existing data must be converted
• A formal evaluation of the results                 33
         Software Quality Assurance
• Software Engineering: software
  development process that stresses
   – solid design,
   – accurate documentation, and
   – careful testing.
• Capability Maturity Model
  (CMM) designed by SE
   – Goal: to improve software quality
• Capability Maturity Model                  The maturity levels:
  Integration (CMMI)                         • Performed
                                             • Managed
   – Goal: Process improvement               • Defined
   – CMMI tracks an organization's           • Quantitatively managed
     processes, using five maturity layers   • Optimizing           34
Software Quality Assurance
             • International Organization
               for Standardization (ISO)
                – Many firms seek assurance
                  that software systems will
                  meet rigid quality standards
             • In 1991:
                – ISO established a set of
                  guidelines called ISO 9000-3
                – ISO requires a specific
                  development plan

                                          35
         Overview of Application
• Application development:
                  Development
  – The process of constructing the programs and code
    modules that serve as building blocks of the
    information system.
• Objective:
  – to translate the design into program and code
    modules that will function properly
• In the previous lecture we studied the tasks
  involved in the creation of System Design.
  – These tasks produced an overall design and a plan
    for physical implementation
• Methods: Structured analysis or O-O analysis          36
          Overview of Application
               Development
• Application Development Tasks
  – Traditional methods
     • Start by reviewing documentation from prior SDLC
       phases and creating a set of program designs
     • At this point, coding and testing tasks begin
  – Agile Methods
     • Intense communication and collaboration between the IT
       team and the users or customers
     • Objective: to create the system through an iterative process

                                                               37
  Application Development
• System Development Tools
  –   Entity-relationship diagrams
  –   Flowcharts
  –   Pseudocode
  –   Decision tables and decision trees




                                           38
       Overview of Application
            Development
• Project Management
  – Even a modest-sized project might have
    hundreds or even thousands of modules
  – Important to set realistic schedules, meet
    project deadlines, control costs, and maintain
    quality
  – Should use project management tools and
    techniques

                                                     39
             • Partitioning:
Structured Application Development
               – Modular design breaks the system into
                 subsystems and modules
            • Structure Charts
               – Control module (higher level module)
               – Subordinate modules
               – Module (rectangle)
               – Data Couple (shows data passing to
                 another module)
               – Control Couple (shows message
                 passing to another module)
               – Condition (diamond)
               – Loop (curved arrow)
                                                 40
• Cohesion and Coupling:
  Structured Application              Development
  – Cohesion measures a
    module’s scope and
    processing characteristics.
     • Single task: high degree of
       cohesion
     • If you need to make a module
       more cohesive, you can split
       it into separate units, each
       with a single function.
  – Coupling describes the
    relationship and
    interdependence among
    modules.
     • Loosely coupled
     • Tightly coupled                              41
Structured Application Development

• Drawing a Structure Chart
  – Step 1: Review the DFDs
     • Review all DFDs for accuracy and completeness
  – Step 2: Identify Modules and Relationships
     • Transform functional primitives or object methods into
       program modules
     • Three-level structure charts relate to the three DFD
       levels


                                                           42
Structured Application Development

• Steps in Drawing a Structure Chart
  – Step 3: Add Couples, Loops, and Conditions
     • Identify the data elements that pass from one
       module to another
  – Step 4: Analyze the Structure Chart and the
    Data Dictionary
     • Ensure that the chart reflects all previous
       documentation and that the logic is correct


                                                       43
Object-Oriented Application
       Development
              • Object-oriented
                development (OOD)
              • Characteristics of
                Object-Oriented
                Application
                Development
                – The application's
                  structure is represented
                  by the object model
                  itself
                                             44
     Object-Oriented Application
            Development
• Implementation of Object-Oriented Designs
  – Main objective: to translate object methods into
    program code modules and determine what
    event or message will trigger the execution of
    each module
• Object-Oriented Cohesion and Coupling
  – Classes – loosely coupled
  – Methods – loosely coupled and highly cohesive

                                                       45
 Agile Application Development
• Agile Application Development: a distinctly
  different systems development method
  – Development team is in constant
    communication with the customer
  – Focuses on small teams, intense
    communication, and rapid development
    iterations
• Extreme Programming (XP):
  – one of the newest agile methods


                                                46
 Agile Application Development
• An extreme programming (XP) Example
  –   User story
  –   Release plan
  –   Iteration cycle
  –   Iteration planning meeting
  –   Parallel programming
  –   Test-driven design


                                        47
 Agile Application Development
• The Future of Agile Development
  – Critics claim
     • it lacks discipline and
     • produces systems of questionable quality
  – Before implementing agile development, the
    proposed system and development methods
    should be examined carefully
  – A one-size-fits-all solution does not exist

                                                  48
                           Coding
• Coding: the process of turning program logic into
  specific instructions
• Programming Environments
   – Integrated development environment (IDE)
      • Microsoft’s .NET
      • IBM’s Websphere




• Generating Code
   – Some CASE Tools can generate editable program code
     directly from macros, keystrokes, or mouse actions
                                                          49
Testing the System
          • Unit Testing:
             – Testing of individual
               program or module
          • Integration Testing:
             – Testing two or more
               programs.
          • System Testing:
             – Testing entire system.
                • You should regard
                  thorough testing as a cost-
                  effective means of
                  providing a quality product.
                                         50
             Documentation
– Program Documentation:
  • Describes the inputs, outputs, and processing logic for all
    program modules.
     – Defect tracking software (bug tracking software) documents and tracks
       program defects, code changes, and replacement code (patches).
– System Documentation:
  • Describes the system’s functions and how they’re implemented.
– Operations Documentation:
  • Contains all the information needed for processing and
    distributing online (forms) and printed output (scheduling info).
– User Documentation:
  • Consists of instructions and information to users who will
    interact with the system.
     – Systems analysts usually are responsible for preparing documentation to
       help users learn the system                                      51
              Documentation
• User Documentation
  – Effective online
    documentation is an
    important productivity
    tool
  – Written documentation
    material also is
    valuable



                              52
       Management Approval
• After system testing is complete, you
  present the results to management.
• If system testing produced no technical,
  economical, or operational problems,
  management determines a schedule for
  system installation and evaluation.



                                             53
      System Installation and Evaluation
• Remaining steps in systems implementation:
  –   Prepare a separate operational and test environment
  –   Provide training for users, managers, and IT staff
  –   Perform data conversion and system changeover
  –   Carry out post-implementation evaluation of the system
  –   Present a final report to management




                                                        54
           Operational and Test
             Environments
Operational environment:
   –The environment for the actual system operation
Test environment:
   –The environment that analysts use to develop and
   – maintain programs




                                                       55
        Operational and Test
          Environments
• The operational environment
  – includes hardware and software configurations
    and settings, system utilities,
    telecommunications resources, and any other
    components that might affect system
    performance
• If you have to build or upgrade network
  resources to support the new system, you
  must test the platform rigorously before
  system installation begins
                                                    56
                            Training
• Training Plan
   – The three main groups for
     training are users, managers,
     and IT staff
   – You must determine how the
     company will provide training
• Vendor-supplied Training
   – Often gives the best return on
     your training dollars




                                       57
                     Training
• Web-based training providing an interactive
  experience:
  – Webinars (online seminar),
  – Podcasts, (web-based broadcast via multimedia)
  – Tutorials
     • Webcast (prerecorded webinar session)
     • Subscribers
     • As technology continues to advance, other wireless
       devices such as PDAs and cell phones will be able to
       receive podcasts
     • Tutorials can be developed by software vendors, or by a
       company’s IT team
                                                            58
Training
    • Outside Training Resources
       – Many training consultants,
         institutes, and firms are
         available that provide either
         standardized or customized
         training packages
    • In-House Training
       – The IT staff and user
         departments often share
         responsibility



                                     59
            Data Conversion
• Data Conversion Strategies
  – The old system might be capable of exporting data
    in an acceptable format for the new system or in a
    standard format such as ASCII or ODBC (Open
    Database Connectivity)
  – If a standard format is not available, you must
    develop a program to extract the data and convert it
  – Often requires additional data items, which might
    require manual entry
                                                     60
            Data Conversion
• Data Conversion Security and Controls
  – You must ensure that all system control
    measures are in place and operational to protect
    data from unauthorized access and to help
    prevent erroneous input
  – Some errors will occur
  – It is essential that the new system be loaded
    with accurate, error-free data

                                                       61
        System Changeover
The process of putting the new information
system online and retiring the old system




                                             62
          System Changeover
• Direct Cutover
  – Involves more risk than other changeover methods
  – Companies often choose the direct cutover method
    for implementing commercial software packages
  – Cyclical information systems usually are converted
    using the direct cutover method at the beginning of a
    quarter, calendar year, or fiscal year



                                                     63
          System Changeover
• Parallel Operation
  – Easier to verify that the new system is working
    properly under parallel operation than under direct
    cutover
  – Running both systems might place a burden on the
    operating environment and cause processing delay
  – Is not practical if the old and new systems are
    incompatible technically
  – Also is inappropriate when the two systems
    perform different functions
                                                          64
          System Changeover
• Pilot Operation
  – The group that uses the new system first is called the
    pilot site
  – The old system continues to operate for the entire
    organization
  – After the system proves successful at the pilot site, it is
    implemented in the rest of the organization, usually
    using the direct cutover method
  – Is a combination of parallel operation and direct cutover
    methods
                                                           65
          System Changeover
• Phased Operation
  – You give a part of the system to all users
  – The risk of errors or failures is limited to the
    implemented module only
  – Is less expensive than full parallel operation
  – Is not possible, however, if the system cannot
    be separated easily into logical modules or
    segments

                                                       66
System Changeover




                    67
    Post-Implementation Tasks
• Post-Implementation Evaluation
  – Assesses the overall quality of the information
    system
• A post-implementation evaluation should
  examine all aspects of the development effort
  and the end product — the developed
  information system
• You can apply the same fact-finding
  techniques in a post-implementation evaluation
  that you used to determine the system               68
    Post-Implementation Tasks
• Final Report to Management
  – Your report should include the following:
     • Final versions of all system documentation
     • Planned modifications and enhancements to the system
       that have been identified
     • Recap of all systems development costs and schedules
     • Comparison of actual costs and schedules to the original
       estimates
     • Post-implementation evaluation, if it has been performed
  – Marks the end of systems development work
                                                            69
           Chapter Summary
• The systems implementation phase consists of
  application development, testing, installation,
  and evaluation of the new system
• Analysts and technical writers also prepare
  operations documentation and user
  documentation
• Develop a training program
• A post-implementation evaluation assesses and
  reports on the quality of the new system and
  the work done by the project team
                                                    70
          Chapter Summary
• The final report to management includes the
  final system documentation, describes any
  future system enhancements that already
  have been identified, and details the project
  costs
• The report represents the end of the
  development effort and the beginning of the
  new system’s operational life

                                                  71

								
To top