Week 11 and 12 are both coming along a bit late. The 3 secondary assignments which were due in the last week took up most of my study time and my review process was somewhat derailed. I have definitley noticed that I do not adsorb as much from the lectures if I don’t keep up with this quick review within 48 hours of first hearing the lecture.
Week 11 was all about the User Interface, the key points taken from this lecture were:
3 Principles of user centered design [UCD]
Focus early on the users and their work (interviews, questionnaires, observation)
Evaluate designs to ensure usability (must be easy to learn)
Use iterative development (prototyping with case tools will assist a great deal with this)
3 metaphors of human-computer interaction
Direct Manipulation – User interacts with objects on the screen (evolved into the Desktop metaphor)
Document – electronic documents, ie: forms
Dialog – command and response.
Principles of visibility and affordance
Visibility – everything that is expected to appear does and in the expected location, ie: submit button should immediately be visible on all forms.
Affordance – appearance should suggest function ie: an envelope suggests email function.
Standards and guidelines are also important to ensure visibility and affordance (particularly Microsoft and Apple’s standards which are publicly available)
Conceptual – What the user understands about the logical tasks/functions of the system
User interface is a very large field and this quick skim over the lecture does not cover a large fraction of what we discussed in the lecture and the tut. In the interest of getting back on track with posts the above points will suffice.
The are some crazy examples of how far GUI design can go on Youtube based on Linux:
Quick review this week with a number of assignments still on the ‘to-do’ pile.
Week 9 -> Structured Design.
We jumped out of the Object Oriented development methodology to take a look at the Design phase in the eyes of a traditional Systems designer. What we saw:
System Flowchart – Need system boundaries in Design phase.
source: week 9 lecture slides
Structure Chart – Describes processes in the System Flowchart in more detail using transaction analysis.
Today’s catch up lecture was title ‘The Nature of Good Design’ and began our work on the Design phase [PADIS]. David’s analogy for the Design phase in comparison to the Analysis phase was, ‘the analysis phase is like the architects rendering of a how a house will look and its features… the design phase is the conversion of that outline into a blueprint from which the house can be built’.
After finishing our lecture on Use Case Diagrams and Class Models, David completed a lecture titled “Finishing Analysis”.
This stage can be broken down into:
Prioritizing System Requirements -> Describe relevant strategic decisions required for implementation -> Determine alternative approaches for development -> Evaluate and Select an approach -> Write up request for proposal and evaluate vendor proposals (should be prior to selecting approach?) ->Present findings to management.
Put simply the final stage of analysis is to (along with management) decide on what Design, Implementation and Support path will best suit the needs of the organization.
* 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
These 4 final steps really are just drawing a conclusion from the information gathered in the Planning phase and earlier Analysis phase steps.
Pearl of the week: In the final stages of Analysis with presentations to management it is very easy to respond ‘Yes’ to management requests which would result in serious ‘scope creep’. Ensure the solution will solve the key issues with the resources allocated (this is superior to attempting to solve everything with more than the allocated resources).
When determining alternatives, particularly for businesses, a tiered approach is best; Low Automation and cost, Mid Automation and Cost, High automation and cost. In presenting/selecting alternatives the POSTEL analysis method is relevant as a ‘big picture’ view is necessary.
Build or Buy? Buy will become increasingly prevailent
After a weeks break David presented an introductory lecture on the Object Oriented Analysis Phase [PADIS]. As we had already covered Class Diagrams in the previous lecture we moved straight into Use Case Modeling. All of the diagrams used in the Object Oriented Analysis phase (and discussed in this week) are members of the Unified Modeling Language:
Source: Paulo Merson
The Diagrams/Models covered in the Object Oriented Analysis phase are:
Week 5 is here and we started the week with the lecture, tutorial double of Systems Analysis and Desgin(by David Grant). I missed the first 10 minutes of the lecture, which I guess involved some revision of the previous weeks lecture on Analysis Models.
The week 5 lecture titled “Traditional or Structured Approach to Analysis”… I think the title should be amended to ‘Structured or Object-Oriented Approach to Analysis“.
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 wassomewhat 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.
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
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).
Another packed lecture from David grant for Systems Analysis and Design yesterday. The first half was a completion of last weeks unfinished lecture on Systems development methodologies. We had a more in depth look at the Object Oriented Approach and its associated methodologies, primarily iterative/spiral which is the current trend. Extreme Programming, The Unified Process and Agile Modeling (a hybrid of the two former) came next. I had not realized previously that my work place utilizes Agile Modeling with SCRUMs and SPRINTs, another timely point that related directly to my job came about when David mentioned that the Agile model would only be successful with experienced, self managing developers (haha … :|). From this lecture I became a little more confused on the distinction between models and methodologies. I recall David mentioning something on the differences but that has escaped me and when looking at wikipedia’s explanation (wiki link) it appears that they are basically substitutable terms;
‘The framework of a software development methodology consists of:
* A software development philosophy, with the approach or approaches of the software development process
* Multiple tools, models and methods, to assist in the software development process.‘
I have found the lecture and course work structure very good for this subject as it uses a consistent process; Introduction of broad concept -> Introduction of Practices -> Analysis of Practices which feels to me like conceptual clustering.
Speaking of which, following the introduction to Extreme Programming, The Unified Process and AGILE modeling, we looked at them in further detail:
Pearl of the week – Object Oriented Methodologies
Extreme Programming – Lightweight, efficient development process, utilizing informal stories and programming pairs. This methodology relies on heavy user involvement and continuous testing and integration.
Agile Modeling – Hybrid of XP and UP, uses Interactive and Incremental modeling. Really a logical evolution of XP and UP based on practical feedback.
The mysterious CASE tools,where introduced again in this lecture but again not covered in detail. I imagine this is because we need to understand all of the concepts in detail before using the tools but by mentioning them the topic it will not feel entirely new when we get onto it.
We completed the previous weeks lecture back on the SDLC getting some revision on the first of the 6 phases [PADIS], Planning.
Steps of the Planning phase
Defining the Problem
Confirming Feasibility [POSTEL]
Launching the Project
The current weeks lecture was a bit shorter and focused on phase 2 of the SDLC [PADIS], Analysis and Requirements Gathering. The key outcome of which was how System Requirements should be compiled; through review of documentation, interview, observation, prototypes, questionnaires, vendor research and joing application design sessions. Most of the Analysis phase is quite intuitive:
Gather information
Define System Requirements
Prioritize System Requirements
Prototype for feasibility and discovery
generate and evaluate alternatives
Also mentioned in the lecture was Business Process Re-engineering however this practice is now becoming more modular and should be driven by the business management (although a systems analyst would provide suggestions or plant seeds as the case may be).
In the tutorial we spent about 35 minutes on the Malcolm Gladwell talk, but the points where valid concluding that Systems design must pay great mind to humanistic aspects and influences.
We will start our assignments next week which should further reinforce what we have covered thus far.
The second lecture presented by David Grant for Systems Analysis and design was focused on systems development models, primarily the Systems Development Life Cycle [SDLC]. We did not get through the whole lecture which was not surprising as it was almost 70 power point slides.
Quite interesting that we should cover this topic a week after the company I work with hit the switch on a new system upgrade for 60,000 web and email hosting clients (a chain of revealed bungles ensued with disastrous results). In the wake of confounded clients and postal resellers I can’t help but think it would have been nice if the project manager had checked out this lecture.
We started off with the SDLC as it is the foundation of development models from which most others are founded on:
P – Planning -> Define business problem and scope, produce schedule, confirm feasability, POSTEL (investigate: political, operational, schedule, technical, economic and legal as influencing factors for planning.), Resource allocation (staff and funding). Launch date.
A – Analysis -> Gather more detailed information, Define and prioritize system requirements (get client to sign these!), Build prototypes(using CASE tools), create and evaluate alternatives, Review with management.
D – Design -> network, application architecture, Interfaces, database, prototype, system controls.
I – Implement -> Construct software components (write code), test program, document system, train users, migrate legacy data, install system
S – Support -> Maintain and enhance the system, support users.
Next came some scheduling models comprising of Waterfall, Overlapping and Iteration of which I perceive Iterative to be the most applicable to all but the simplest business scenarios. The business environment is much too fluid to imagine a single launch phase.
We then investigated some approaches to system development:
Structured – Procedural/Process centric
Information Engineering -Data centric
Object Oriented – Concept based (I believe this approach is now the most popular with the rise of JAVA). As I have done most of my own programming in using the OO paradigm, the most intuitive for me.
Which brings me to the pearl of the week:
Information Engineering – A Data Centric approach to system development recognizing that the types of data created by a business is one of its most stable aspects. After hearing about this in the lecture I checked this methodology out on Wikipedia (see here).
I was interested to read that there are several variants and that the creators of this methodology have gone on to create other methodologies including an Object Oriented type. With such a huge number of methodologies and variants on each of them I understand David’s statement at the beginning of the lecture (which was something like: In practice Systems Analysts don’t actually apply these theories directly, it just helps to be aware of them). As per usual conceptual understanding/comprehension in conjunction with experience is superior to rote learning 150 models and methodologies.
Heading straight to the tutorial again after the lecture was easier this week. This week group presentations were due. We did not commit a great deal of time to preparation for this and I am glad I did not spend any more than I did. Primarily because (although interesting) the presentations were not really focused on the course scope, secondly, it was not an assessable piece of work and thirdly because we did just as well putting together our ideas over email and adjusting on the day. I agree with Linus Torvalds in his strategy of avoiding meetings and phone calls instead favoring email threads. With email threads everyone gets a turn to speak, everyone has to think before they submit their opinion and repetition is reduced. Email threads > Group meetings.
The whole tut was taken up by group presentations with intermittent additions by David, it was really enjoyable but again, not sure how related to the course it was. I look forward to doing some more practical work in the tuts as this will re-enforce the theoretical topics covered in the lectures.
