How To Get Good Marks For The O-Level project
The marking schedule is divided into 6 sections. The names of the sections are: (i) The Problem (ii) Design (iii) Implementation (iv) Testing (v) Documentation (vi) Evaluation. Each section is divided into a number of subsections.
The marking schedule does not indicate the order in which tasks should be completed even though the sections do relate to the phases of a SDLC. To illustrate this we will find it is likely that during the completion of our project our "problem description" will be revised many times as we become more knowledgeable about or clients problem.
The problem
a. Description of the problem (2)
This means using establishing a model of the current system. The
information for the model comes from interviews, observation and
documentation. Making up "scenarios" along with workflow
diagrams is a useful way of identifying the processes of an
existing system. To get the 2 marks for this section you would
produce (i) A background introduction about the business (ii) A
context diagram (iii) Descriptions of all or some of: hardware,
software, people, procedures, networking and data (iv) scenarios
(v) identification of business related problems with the current
system. (vi) samples of output that the system produces.
b. Specific Objectives (3)
The specific objectives are a list of things that the new system
must be able to do. In a way the specific objectives define the
scope of the new system. The list of specific objectives
will ALWAYS include the objective that "the system meets or
exceeds user expectations". There are several things to think
about when creating the list of objectives: (i) objectives must
be measurable. This means there must be a way to test whether or
not the objective has been met. (ii) objectives need to relate
to problems identified in section 1a. (iii) objectives can
relate to opportunities such as the ideas of differentiation,
increased accuracy, and greater efficiency. Anything that will
give the business a competitive advantage can be
considered as a candidate for a specific objective. (iv)
finally, objectives need to be realistic. We have to
consider factors like availability of resources, scope
constraints, and time constraints when agreeing to specific
objectives with end-users (new system stakeholders). NOTE that
is highly likely that when thinking about specific objectives
you will need to go back to the earlier modeling work to get a
clearer picture of the current system. The approach that we are
using is called evolutionary prototyping. This means that we
will create models at different stages of the SDLC and
incrementally improve these over time. We will need to go back
and revise work carried out earlier in the SDLC as our
understanding of the requirements of the new system improves.
c. Evaluation of existing solutions (2)
At this stage we are required to identify the parts of the
current system that do not meet the objectives of part 1b. We
might also identify parts of the current system that are no
longer required. At this stage we need to have a more formal way
of representing our model of the current system. This means
using a data dictionary and dataflow diagrams. Though not
mentioned in your Form 5 syllabus, it is a good idea to think
about using entity relationship diagrams for data modeling. It
is worth the trouble to learn to use the education version of a
CASE tool as this will ensure that the different models remain
balanced as and when we change things.
d. Description of alternative solutions (2)
In the real world we would look first at "off the shelf"
software. In most cases this is likely to be the best solution.
The reason for this is that "business is business and the
processes for all businesses are pretty similar". In some cases
there might be the need for slight modifications to be made. It
is not likely that we, as system analysts, would choose to
develop new software from scratch. However, the O-Level marking
schedule is biased towards the development of a system rather
than purchasing something. For this reason we should suggest at
least one alternative that involves the development of software.
I would suggest that you have a design alternative that includes
using a database that is accessed by a User Interface that you
have built with Visual Basic. You should have several design
alternatives.
Each alternative should include (i) A narrative description of
the alternative in a single paragraph. (ii) A description of
hardware AND the reasons for the choices of hardware that
you feel will be necessary. (iii) A description of software
requirements and how the software is likely to be developed (iv)
Description of the data requirements of the system and the means
for accessing/storing this. (v) Any networking requirements (vi)
A description of what people are required to operate the system
once it is implemented (vii) A description of the procedures
that will be carried out by operators of the proposed system.
(viii) a budget (ix) schedule (x) resources needed for
development (xi) expected return on investment (ROI)
e. Evaluation of alternative solutions (2)
At this stage we are interested in choosing the best of our
design alternatives. We analyse each alternative by considering
feasibility factors and strategic factors.
Feasibility factors determine the chance that the proposed
system can be built at all given time restraints, resource
constraints and scope constraints. We consider Technological,
Economic, Operational and Scheduling factors. We assign a mark
between 1 and 10 for each feasibility factor and then add these
up. The strategic factors are to try to identify whether a
proposed system is going to be useful or not. A high score for
strategic factors would suggest a valuable and useful system
proposal. We can chart feasibility factor totals against
strategic factor totals to show which alternatives are
candidates for design. Good design alternatives have high
feasibility factor scores (system can be built) and high
strategic factor scores (the system will be useful).
Design
f. Overall Plan (3)
This section will specify when and what remaining system
development tasks will be carried out. We can use a Gantt chart
to diagrammatically show this. Your Gantt chart should clearly
show milestones and it should also show which tasks precede
other tasks. The plan needs to be aligned with the scheduling
constraint defined in the design alternative. Be careful to look
at your objectives to ensure that your new system will do what
the user wants and that your overall plan will ensure that the
objectives are met.
g. Description of method of solution. (3)
For this project we will be prototyping with Visual Basic and an
Access database. We should show the screen displays and TOE
tables that we have prototyped and also print a report that
clearly shows your proposed database design. The database design
will include field and key information as well as any validity
checking that is to be carried out by the database engine.
We should provide scenarios that show how tables change when a
database transaction takes place.
We will need to have a completed data dictionary which includes
process specifications. Structured English can be used for the
process specifications. We also need a complete set of dataflow
diagrams.
h. Hardware requirements (4)
This section requires that we provide as much detail as possible
about the hardware for the proposed system We MUST justify our
hardware choices. Be careful to try and select what is needed
– not more and not less. Include details about storage capacity,
display and printer specifications and any networking hardware
you might need. It is good to also consider hardware to support
disaster recovery plan and preventative maintenance
solutions (UPS, surge protector, tape drive, disk mirroring).
i. Software requirements (3)
Include the software that you have created but also whatever you
feel is necessary in the way of an operating system / networking
system as well as information about any software required for
security (virus protection, backup software)
Implementation
j. Method of solution related to problem (2)
The method of solution should include the use of screen maps.
Structure charts, process specifications and related code. There
needs to be a clearly defined path for creating a product from
the design specification of part 2.
k. Method of solution accurate (2)
The code that we generate should accurately reflect the design
work completed in section two. Demonstrate that this has been
done by showing samples of input screens processing and output
that your finished system is able to produce.
It is important, for the purposes of implementation, that your
process specifications in the data dictionary reflect the
software code produced for the system. I would suggest putting
the system specification and the related software coding next to
each other in this section of your project.
Testing
l. Test Strategy (3)
There is a need for a testing plan. There is an information
sheet that specifically details what is to be included in
testing. This information should be used and modified to develop
a testing strategy for our own project.
m. Test Results (4)
There must be a serious attempt made to find errors in the
software that has been developed. This will include some or all
of the tests identified in the testing worksheet. You will need
to clearly identify the test used and the data sets that you
have decided to use for testing purposes. Note that we would
expect to "white box" test process specifications and "black
box" test coded modules. The importance of testing can not be
over emphasized! Note that this part of the project has more
weighting than any other.
Documentation
n. Technical documentation (2)
This consists of deliverables from different phases of the SDLC.
These documents already exist if we have been building our
system properly! It is just a matter of organizing them nicely
so that we can find information conveniently when required. The
technical documentation is going to be every piece of
information that a programmer might need to be able to make
alterations to the software. This will include (i) details about
the database (ii) process specifications (iii) code listing for
each module (iv) test results (v) sample screen shots and sample
output.
o. User documentation (3)
This is everything a user needs so that they can operate the
system that has been developed. Instructions should be clear and
well organized. It is easy to test the quality of instruction
material – give the instructions to users and observe how
successful they are at operating the new system. Testing the
user documentation will be a part of the testing schedule for
our project.
Evaluation
p. Our evaluation (3)
We should look at the objectives identified at the start of the
project. Go through each objective and see whether or not it has
been achieved. Also look closely at the test results. It will be
possible to make a comment about the success or otherwise of the
project based on the analysis of these two factors.
q. Future development suggestions (2)
Any problem identified in testing will be an obvious place to go
for future developments! However, also consider what might be
added to the system if there is more time, better use of
technology and more money to do things with. It is important to
consider future possibilities that we are reasonably sure are
going to provide a competitive advantage for a business or
organisation.
There is a section titled "technical skill" , a mark for which is determined by the teacher . To obtain a high mark for this you will need to demonstrate a high level of expertise with a programming language, database design, system modeling and the ability to put together information nicely so that it can be read and understood easily. This last section is worth 3 marks. The total marks possible is 50.
Mike M
Friday, May 21, 2004
