E-Learning Material Web Application Design

Why do we need a process? The Process Communication Modelling web applications

Why do we need a process? Developing apps. is hard work Robust process helps bring a project to maturity repeatedly and reliably Need to guide our activities Need to define artefacts of process Any piece of info. that is produced by the workers of a process Need to direct tasks of team Must dictate criteria for monitoring progress

The Process Deployment TestEvaluation Planning Requirements Analysis Design Implementation Initial Planning

The Process Process based on OO methodology Process is ‘iterative’ Each process repeated and refined until requirements met Different from ‘waterfall’ process Each stage completed, ‘put to bed’ before moving onto next stage

The Process Remember it’s an abstract model Not set in stone Large companies may have success with strict process Small teams may have more relaxed approach If a process is successful it must be accepted and used by the team

Communication Fundamental to success Represent new application To be built What do we need to do? Being built What is left to do? Is what we have done correct so far? As it was built User documentation

Modelling Constructing models helps manage complexity of application Assists delegation of work to different teams One reference point Don’t forget project management tasks! Planning, risk management, progress monitoring, etc.

So Far we Know Iterative process more realistic Process should reflect working culture Models allow us to communicate our intentions and our results Worthless without some discipline Manage the project!

Remember SSADM? Before we started the analysis, we gathered the requirements of the system We then looked at the results from different views and produced a data model Is an E-Business application any different?

No it isn’t We need to capture functional requirements How does the system behave in response to user and external system input? What does the user want to achieve with the application?

Oh no, not UML! Use cases capture and express interaction dialogue between system users (actors) and system itself Textual description What an app. should do, without constraining how it should do it

Use Cases Each use case should represent whole process ‘The customer tells the system to checkout. The system examines the contents of the shopping cart and produces an itemised list of all the items that are ready to be purchased. Taxes and delivery charges are calculated and added to the total in the relevant currency. The customer confirms the order and tells the system to process the order.’

Checkout use case checkout Online customer

Recap We record our requirements (nothing new) Textual descriptions of processes We break the big problems into smaller, manageable ones (heard that before) Use case descriptions We communicate our findings Use case model