FIT9030: Week 4

David spent the first 30 minutes or so of todays lecture completing the left over slides from last week on Requirements Gathering [PADIS]. Joint Application Design Sessions was the first topic, whereby the key stakeholders get together in a ‘war room’ (there is to be no fighting in the war room) with the required resources to fact-find, model, create policy and verify activities. That is to, complete the Analysis phase of the System Development Life Cycle in the space of a day or two.

Next we moved onto Vendor Solutions, this is an aspect of Systems Analysis that I think will become more and more prevalent in the coming years with Open Source programs on the rise along with those who are able to customize the packages sufficiently to make them a superior option. David mentioned that a 60-65% fit for a businesses’ System Requirements is sufficient to make an out of box solution work although his argument was supported only by a single anecdote.

The Requirements Gathering lecture came to a close with the Validation of Requirements (which is best conducted with near working prototypes) and a summary of the Analysis Phase:

• Gather information (review documents, current practices, conduct interviews, prototyping, questionnaires, JAD sessions, Vendor Solutions)
• Define System Requirements
• Prioritize Requirements
• Prototype (feasibility and discovery)
• Generate and evaluate alternatives
• Review with management

This weeks lecture was titled Beginning Analysis, this was somewhat confusing as I thought Requirement Gathering was part of the Analysis phase. The topics of the lecture:

• Analysis Models
  • Used to reduce complexity via abstraction (mathematical, descriptive, graphical). In Analysis Logical Models are used which are elaborated into Physical models in the Design Phase.
  • Models used in the Design Phase include:
    • Event List
    • Data Flow Diagram
    • Entity-Relationship Diagram
    • Data Flow Definition
    • Data Element Definition
    • Process Description (structure English)
    • Class Diagram (UML)
    • Use Case Diagram (UML)
    • Sequence Diagram (UML)
    • Collaboration Diagram
    • Statechart Diagram
• Events (OO Systems are event driven)
  • Simplistically, an occurrence at a time and place(to trigger all System Processing). Events can be divided into External(ie: customer orders warhead), Temporal(Time) and State(eg: status/qty). See Event Table below
• Objects and System Requirements
  • Things (Customer, Employee, Supplier, Order, Item, Account) = Objects, Properties/Characteristics/Relationships = Attributes, Behaviors = Methods
• UML
  • The standard modeling technique for OO

We skipped through the last two of the items above, Dave mentioned we would cover these in more detail next week.

In the tutorial we completed the interview for our assignments which will now enable us to complete an Event Table for the Employee Testing System Assignment. Apparently our interview went very well (I think this was a successful chance for Dave to give students some positive re-enforcement prior to attempting the assignments).