Embedded Files
UML and Waterfall
The use of UML and User stories have been selected for this development, as introduced in Section 1.4 Project Methodology.
This section describes the choice of tool for each section of the development and which methodology it fits with.
The following table (Table 15) shows the types of UML diagram that have been chosen.
Table 15 - UML Diagram Types and Purpose
UML are seen as Waterfall type tools to pre-plan the design of the development. This is shown in under Section 4 of Figure 14. The testing plan is used at the end of the lifecycle when the PoC is validated in meeting its goals.
The UML techniques have been studied by the author in the foundation degree prior to the top-up degree with Sheffield. The choice of UML is a continuation of past learning, with additional reading from "SAMS Teach Yourself UML in 24 hours" (Schmuller 2004).
Figure 14 - Annotated Waterfall Model Diagram (InQbation 2013)
The Test Plan (PoC Phase One)
The test plan for the PoC is very simple as the output can be verified in a simple way with the test data being used within the system. The test will be to produce an exceptions output report by entering into the tables known bad combinations of access.
The data will be manually plugged/inserted into to the database design to achieve this, the expectation is to produce a database query that will report where the exceptions are for a given application.
The test once the reports query has been built will be to enter one additional attribute row into the toxic table to see if this value appears in the report where it is known to be mapped to a particular user and role. If the attribute appears the reports output has been shown to be working and the test has been validated.
Agile Methods
The Agile methods will be used in phase two once the PoC test plan has been completed. The Agile methods are shown in Table 16.
Table 16 - Summary of Agile Methods and Purpose
The diagram in Figure 15 shows the iteration cycles for a software development. In the User Guardian development the GUI and online code that interacts with the database will be coded in iterations.
As an example of a first iteration could be to develop a single online page and pull some data from the database to ensure the technologies are working correctly.
Figure 15 - The Spiral Model (Technology UK 2013)
At the time the development is at sprint 2 or 3 most of the application should be in an operating state. This model of development cycle is useful when there are time and cost pressures. The project manager can take a view on the number of sprint that are taken before they make the development live. If the development is being scheduled a working version can be released that may not contain all the functions, but is at least working.
This differs from the Waterfall lifecycle where the development is scoped, tested and completed at set intervals. This means the whole development should be completed at the end. One issue with this approach is that time and resources have to be pre-allocated for contingency against any pre-envisioned issues, and could lead to a non-functioning application if major issues are not overcome.
The Agile Test Plan
As each sprint is completed the development will be sense checked against the user story narrative and goals to ensure that it functions as expected. The outcomes of the agile development are not normally know in facts or figures, unlike the Waterfall method used in the PoC where we can clearly check for a value to understand if the software is working as intended.
References
InQbation, 2013. Waterfall method of software web developement. [Online]
Available at: http://www.inqbation.com/waterfall-method-of-software-web-development/
[Accessed 27 December 2013].
Schumuller, J., 2004. SAMS teach yourself. 3rd ed. Indiana: SAMS
Technology UK, 2013. Other Life Cycle Models. [Online]
Available at: http://www.technologyuk.net/computing/sad/other_models.shtml
[Accessed 27 December 2013].
Page updated
Google Sites
Report abuse