CUSTOM CASE STUDY
The site is highly secure, with conservative leases, and reliable but requires logging in multiple times per use case. Liberal site-paths, low load-times and responsiveness are sometimes slight issues. The individual site is comprised of multiple domains. On the LSBU campus network, users have to use their LSBU-User-ID for wifi AAA.
One considered change was a system that logs users on the campus network into the LSBU sites automatically, to the same account that is used on the wireless AP AAA.
This could be implemented with client-device apps that could use Wireless interface information, the LSBU User+Pass, to add to a created set of cookies on the client-device for use by the LSBU site.
Alternatively, the LSBU-site-servers could be made to automate login requests with the wifi-AAA server. The wifi’s AAA-service servers could be configured to push records of the active user-accounts and their MACs and/or other routing information to the site server. The site server would then receive requests from the client-device and recognise its associated User-ID.
Although it would improve user-experience, this aim (and neither mechanism) is not cost-efficient and presents a security concern for both sides.
Development Path Decisions
In some cases, “Existing system + solutions to problems = required system?” is true but, generally with systems due to be still active after a decade of use, a completely new system may be easier, better suited and/or more economical to implement. Also, solutions always have alternatives and are only momentarily sufficient.
Depending on the existing system and established requirements, a predictive or an adaptive approach is appropriate and will respectively employ specific lifecycles. If changes to the proposed system are to be expected within a cycle, an adaptive approach fits but a predictive approach may be appropriate – accounting for changes at cycle starts. Conversely, adaptive approaches may be impractical if time constraints are too tight and iterations or increments are expected.
If funding and time allows, a change may be best implemented on a new increment or an entirely new iteration for consistency assurance. New iterations may have the benefit of being constructed with the new requirement as a base functionality – and the allowance of re-envisioning.
Irrespective of funding – if time is severely limited, changes may best be implemented at as close a previous phase as possible – to minimise setbacks. However, this approach often creates inconsistencies in documentation and operational-stability.
Ultimately, whatever path is taken to reach completion state, there will always be new requirements to arise. The ‘required system’ is only ever as such for a limited period of operation, requirements can even be altered without the developers knowing – however, a system being new means higher preparedness for further changes.