SAD

SAD

System Modelling/Models
1. Meaning of systems modeling
  1. The use of model to conceptualize and construct systems
  2. The interdisciplinary study of the use of these models
  3. Systems modeling, analysis, and design efforts
  4. Systems modeling and simulation, such as system dynamics
2. Types of Modeling
  1. Waterfall Model (linear)
    1. Sequential development process, development flows steadily downwards through the SDLC phases;
      1. Analysis
      2. Design
      3. Implementation
      4. Testing
      5. integration
      6. Maintenance
      7. Waterfall Model Image Representation
    2. emphasizing planning, time schedules, target dates, budgets and implementation at one time allows us to consider, think and plan through the entire life of a project
  2. Parallel Development (Structured)
    1. Similar to Waterfall Model difference being
      1. Instead of completing each one of the phases for the whole project the project is divided into small projects and each one of the phases is implemented separately for each one of them
        This way, the development process is carried on concurrently and separately for each one of the small sub projects.
  3. Prototyping (iterative)
    1. Prototying allows people to have 'Stake' or interest in a system to 'Test Drive' designs
    2. Not all prototypes are interactive, the most useful application of prototyping is based upon providing a simulation of some behaviour and functionality.
  4. Agile (iterative)
    1. Advocates a lighter more people-centric view point than traditional aprroaches of iterative development
    2. Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.
  5. Spiral (Linear + Iterative)
    1. Allows for incremental releases of the product, or incremental refinement through each time around the spiral
      1. The spiral model also explicitly includes risk management within software development
    2. Based on continuous refinement of key products for requirements definition and analysis, system and software design, and implementation (the code
    3. Uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations
    4. Starting at the center, each turn around the spiral goes through several task regions;
      1. - Dtermine the objectives, alternatives, and constraints on the new iteration.
      2. - Evaluate alternatives and identify and resolve risk issues
      3. - Develop and verify the product for this iteration
      4. - Plan the next iteration
Interfacing
1. Interface metaphor is a set of user interface visuals, actions and procedures that exploit specific knowledge that users already have of other domains
  1. example of an interface metaphor is the folders and the file cabinet representation of the file system of an operating system. Another example is the tree view representation of a file system, as in a file manager, that helps a user to use it, given some previous knowledge of recursive structures
2. Usability (Simplicity, less is more, don't make me think, don't make me read)
  1. Testing Usability
    1. 1. Get users to try the system out and talk about their experience (see Krug) Select roles Select tasks Get users (role-person) to try to execute the task
    2. 2. Get the user to talk through what they are doing and record this. Record the users facial expressions. Record the mouse movements
    3. 3. Play back video to user, and have them explain in further detail
    4. 4. Analyse what went wrong and compile the data: Error severity Number of mouse clicks used Facial expressions, show frustration etc Navigation paths
  2. "Usability is a quality attribute that assesses how easy user interfaces are to use.” (Nielsen, 2003)
3. 5 quality componets
  1. Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?
  2. Efficiency: Once users have learned the design, how quickly can they perform tasks?
  3. Memorability: When users return to the design after a period of not using it, how easily can they reestablish proficiency?
  4. Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?
  5. Satisfaction: How pleasant is it to use the design?
4. 10 usability heuristics
  1. Visibility of system status: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
  2. Match between system and the real world: The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
  3. User control and freedom: Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
  4. Consistency and standards: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  5. Error prevention: Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
  6. Recognition rather than recall: Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
  7. Flexibility and efficiency of use: Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
  8. Aesthetic and minimalist design: Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
  9. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
  10. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. I originally developed the heuristics for heu
Stages from the SDLC
1. 2. Project Initiation + Planning
  1. Operational Feasibility
  2. Economic Feasibility
  3. Technical ^
  4. Human Factors ^
  5. Legal/Political ^
2. 3. Analysis
  1. User Requirements
  2. System Requirements
3. 4. Design
  1. Desired Software Features in Detail
  2. Functional Hierarchy diagrams
  3. Screen Layout diagrams
  4. Tables of Business Rules
  5. Business Process Diagrams
  6. Pseudo-Code
  7. entity-relationship diagram + Full Data Dictionary
4. 5. Implementation
  1. Changes and enhancements would be made with the implementation
  2. Two approaches to System Development
    1. Structured
    2. Object Oriented
5. 6. Maintenace
6. 1. Project Idenification and Selecion
Reporting
1. Giving data meaning it becomes information, information is processed data.
2. Value of reports
  1. Well-designed reports have useful information in a time series, making them a valuable data repository. And if the report covers the right questions, the process of gathering the information can generate valuable insights for the project team to act upon.
3. Principles of good reports
  1. - Title must be informative
  2. - Number of pages
  3. - Date
  4. - Time (must not change + must be in a useful place)
  5. - Same header on every page
  6. - Don't switch fonts
  7. - Don't use multiple font sizes (2 max, header + rest)
4. Classic reports (columnar)
  1. - Column widths decided by width of data not header
  2. - Sort columns on the left
  3. - Text columns almost always left justified
  4. - Numeric almost always right jutified
Trading
1. Information Systems relate tightly to Trading, almost all trading is done via IS
2. Elements of Trading
  1. Order
  2. Delivery Note
  3. Invoice
  4. Remittance Advice
  5. Returns Note
  6. Credit Note
  7. Account
  8. Statement
  9. Book-Keeping
MRP&MRPII / JIT
1. Just in Time
  1. "pull" system of production
    1. Orders provide a signal for when a product should be manufactured
    2. Demand-pull enables production only of what is required in the correct quantity and at the correct time
    3. This means that stock levels of raw materials, components, work in progress and finished goods can be kept to a minimum.
      1. requires a carefully planned scheduling and flow of resources through the production process
      2. Information is exchanged with suppliers and customers through EDI (Electronic Data Interchange) to help ensure that every detail is correct.
  2. 0 Targets of JIT
    1. 0 Defects - poor quality is inevitable
    2. 0 inventory - Rejecting the view that
      1. it is an asset
        Proof of work
        buffer against poor suppliers
        ensure machine utilisation
    3. 0 lead time / set up time
      1. ○ When it takes a day to set up - you need to make as much as you can to cover the cost of set up
      2. Lower set up time better
    4. 0 handling
      1. ○ Make it so that when one part is done it can move to the next part without much time i.e. next to each other
  3. Changes resulting from JIT
    1. Factory Layout
      1. ○ Re-laid the factory - e.g. put doors in the factory to make the incoming lorry part of the production line etc.
    2. Product Design
      1. ○ You design the product to be easier to make ○ Multi-disciplinary teams come in to make the product easier to make
    3. Customer
      1. Change relationships with customer, able to build around customer request
    4. Supplier
      1. Contracts change
2. Material Requirements Planning
  1. production planning and inventory control system used to manage manufacturing processes
  2. Software-based
    1. Can be done by hand
  3. 1. Ensure materials are available for production and products are available for delivery to customers.
    1. 2. Maintain the lowest possible material and product levels in store
      1. 3. Plan manufacturing activities, delivery schedules and purchasing activities
  4. Inputs
    1. BOM (Bill Of Materials)
      1. Statement of all the parts needed to make 1 product. Came in the 50's 60's
    2. MPS (Master Production Schedule)
      1. How many going to be made in a day or set time
        Can change
    3. Manufacturing Time
    4. Ordering Lead Times
    5. Order Schedule
    6. Stock Position
    7. Outputs
      1. Schedule of orders
        Each item required how many and the date order must be placed with supplier
      2. MRP software
        Can be done via spreadsheet but the more complex the better it is for MRP software
  5. Issue with MRP
    1. MRP ignores capacity
      1. Having materials to make 1000 of x but only able to make 500
      2. Assumes infinite manufacturing capacity
    2. MRPII made to resovle issues
3. MRPII (Manufacturing Resources Planning)
  1. MRPII differs as it incorporates processes limitation into it's ideology
    1. Where MRP has BOM MRPII adds BOP (Bill Of Processes)
      1. BOP calculates:
        - Number of items able to produce at any one time(start time and quantity)
        - Produces a shop floor schedule
        - What and when to order
        - Produces a stock ordering schedule
      2. BOP allows the right materials to be ordered at the right time when the production is actually going to take place
The Systems Analysis and Design (SAD) is the process of developing Information Systems (IS) that effectively use hardware, software, data, processes, and people to support the company's businesses objectives

Siguiente

Descripción

Resumen del Recurso

Recursos multimedia adjuntos

Similar

	Creado por Bhavit Chhatralia hace alrededor de 11 años