Monday 7 December 2009

Don't be Fooled

A LOT OF PEOPLE SEEM TO THINK THAT EVERY LITTLE TINY ACTIVITY NEEDS AN ACTIVITY DIAGRAM...

I JUST WANT TO NOTE THAT REMEMBER THE DIAGRAMS ARE SUPPOSED TO BE FOR PRESENTATIONAL PURPOSES...SO LONG AS U CAN UNDERSTAND THEM AND PRESENT THEM WELL ENOUGH THEN YOUR ACTIVITY DIAGRAM IS CORRECT.

THIS MEAN YOU DO NOT NEED TO CREATE AN ACTIVITY DIAGRAM FOR VERY SMALL ACTIVITIES, HOWEVER YOU CAN INCORPORATE THE LITTLE ACTIVITIES WITHIN THE DIAGRAM FOR THE BIGGER ACTIVITIES. IT ONLY MAKES SENSE TO DO IT THAT WAY BECAUSE BIGGER ACTIVITIES WILL ALWAYS DEPEND ON SMALLER ACTIVITIES WITHIN THEM.

Saturday 21 November 2009

Events?

External event- an event that occurs outside the system, usually initiated by an external agent or actor.
• Agent (actor) or organisational unit that supplies/receives data from the system
• Customer- order/return
• Must be defined clearly by its name (event name). Description should include the action that the external agent wants to pursue
e.g.) customer places an order – this title of an event describes the external agent (customer in this case) and the action that the customer wants to take (place an order for product).


Temporal event- an event that occurs as a result of reaching a point in time
• Generated by system automatically
e.g.) payroll or store statistics reports (end of day stats/footfall etc.)
• No agent/actor required to make demands, system generates outputs when they are needed periodically
e.g.) internal outputs needed include....management reports, operational reports, internal statements and documents
external outputs needed...statements, status reports, bills, reminders and quotes


State event- an event that occurs when something happens inside the system that triggers the need for processing. Also called internal events.
e.g.) stock falls below minimum stock level (reorder level) so the system initiates prompt to reorder or reorders automatically

Using Predictive approach to SDLC:

Project planning – to plan a schedule and obtain relevant approval in order to go ahead with the proposed project.

Analysis- to understand the processing requirements as well as the needs of the business .
Design- to define the solution system based the requirements and the relevant decisions from the analysis section.

Implementation- to construct a prototype and test it to ensure the system operates as it should and nothing is missed out. Users and the necessary personnel need to be trained to use the system.

Support- to keep the system updated and in optimum functionality and to keep it running to improve the user’s experience.

The Systems Development Life Cycle:

2 approaches:
1. Predictive- assumes project can be planned out in advance
2. Adaptive- more flexible, assumes project cannot be planned out in advance

Unified Process(UP) and Extreme programming (XP)

Unified process (UP): 6 best practices
• Develop iteratively
• Define and manage system

Extreme programming (XP): write programs in pairs
• Test everything
• Small developments

Activities of analysis

Activities of analysis
• Gather information to learn problem domains
• Define system requirements
• Build prototypes for discovery of requirements
• Prioritise requirements
• Generate and evaluate alternatives
• Review recommendations

Mathematical Models:
Is used to show the precise aspects of a system (operations) where it can be represented using formulas or mathematical notes

Descriptive Models:
Is a model used to describe a process or procedure of a system in the form of structured English text or pseudocode. This type of text could include lists, reports and even memos to represent important steps of a system.

Graphical models:
The use of diagrams and schematic representations such as flow charts and event diagrams etc. Which describe different aspects of the system. This model could be one of the easiest to understand in a short amount of time, however may need to include aspects from either the mathematical oe descriptive models beside it in some cases.

Friday 16 October 2009

The first Blog-CISD

i have come to understanding; after a lot of informing from my lecturer that many businesses fail due to a number of facts. some being that the businesses themself prefer to save money rather than carrying out certain types of risk assesment with the programming. another being that the communication between the developer and the business lacks detail of the actual requirements. etc etc we could bring up many different reasons such as "pass the blame" but knowing all this means that:

we have to learn from their mistakes and not our own which could cost billions of dollars in losses per day eventually.

WE NEED TO DO WHAT THEY DON'T, WE NEED TO BE WHAT THEY AREN'T AND WE NEED TO EARN WHAT THEY SHOULDN'T!