Page 107 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes To give an example of this way of thinking from our day job:
Every couple of years my company plans and hosts a large event where ~400 of our customers
all fly in to one location for a multi-day event with various activities. We have some staff whose
job it is to organize the logistics of this event, which includes tracking which flights everybody
is booked on, arranging for transportation to/from airports, arranging for hotel rooms, name
tags, etc. The last time we arranged this event all these various pieces of data were tracked in
separate spreadsheets and reconciliation and cross-referencing of all the data was literally done
by hand using printed copies of the spreadsheets and several people sitting around a table going
down each list row by row.

Notes Obviously there is some room for improvement in how we are using software to
manage the event’s logistics.
The next time this event occurs we plan to provide the event planning staff with a more intelligent
tool (either an Excel spreadsheet or probably an Access database) that can track all the information
in one location and make sure that the various pieces of data are properly linked together (so for
example if a person cancels you only need to delete them from one place, and not a dozen
separate lists). This solution would fall at or near the very left end of the SEMS meaning that we
will just quickly create something with very little attention paid to using mature software
engineering practices. If we examine this project against the 3 criteria we have listed above for
determining it’s place within the SEMS we can see why:
Importance: If this application were to stop working the business doesn’t grind to a halt,
revenue doesn’t stop, and in fact our customers wouldn’t even notice since it isn’t a customer
facing application. The impact would simply be more work for our event planning staff as
they revert back to the previous way of doing things (assuming we don’t have any data
loss).

Complexity: The use cases for this project are pretty straightforward. It simply needs to
manage several lists of data, and link them together appropriately. Precisely the task that
access (and/or Excel) can do with minimal custom development required.

Life-Expectancy: For this specific project we’re only planning to create something to be
used for the one event (we only hold these events every 2 years).
Let’s assume we hack something out quickly and it works great when we plan the next event. We
may decide that we want to make some tweaks to the tool and adopt it for planning all future
events of this nature. In that case we should examine where the current application is on the
SEMS, and make a conscious decision whether something needs to be done to move it further to
the right based on the new objectives and goals for this application. This may mean scrapping
the access database and re-writing it as an actual web or windows application. In this case, the
life-expectancy changed, but let’s assume the importance and complexity didn’t change all that
much. We can still probably get away with not adopting a lot of the so-called “best practices”.

Example: We can probably still use some of the RAD tooling available and might have
an Autonomous style design that connects directly to the database and binds to typed datasets
(we might even choose to simply leave it as an access database and continue using it; this is a
decision that needs to be made on a case-by-case basis).
At Anvil Digital we have aspirations to become a primarily product-based company. So let’s
say we use this tool to plan a handful of events internally, and everybody loves it. Maybe a
couple years down the road we decide we want to package the tool up and sell it as a product to

100 LOVELY PROFESSIONAL UNIVERSITY