As all the sections of the requirements document were successfully implemented into the MOF framework, the mapping is complete. The tables given in Appendix J present the sections of the requirements document, and where in the MOF framework they were implemented during this process.
5.5
Discussion
During this chapter we decided to apply our requirements document to the MOF project management standard, in order to test our demand of a framework independent product. In order to do this we had to map all the sections of the requirements document to the phases, SMFs and activities of the MOF framework.
Since the requirements document was generated to guide in the specification of re- quirements during the planning of a CC implementation, most of the document applied
Figure 17: Quick overview of the hardware implementation
[132]
to the Project Planning SMF of the Deliver phase of MOF.
Only one step was mapped to the Plan phase, as most of the phase is not limited to singular projects. The authority step of the requirements document was placed in the Business/IT Alignment and Reliability SMFs as this is where new projects are initially discussed and authorized. This worked out well, but as authorization is performed at several stages of the MOF process, this is not the only place it resides.
Most of the initial description steps of the Prerequisites/Constraints section were placed into the Envision SMF of MOF, as the three first steps of this section closely re- sembled the content of the vision and scope document in the Envision SMF. No problems were encountered here. The high-level requirements were added into the Solution design strategies part of the vision and scope document, and proved to fill its needs nicely by ap- plying user stories, actor lists and high-level functional and non-functional requirements. Furthermore, initial legal and compliance studies were added to the vision and scope document. This was not a part of the MOF model, but it seemed appropriate that the issues concerning these demands were handled at an early stage. No issues have been noted regarding this. Risk assessment also found its place in this SMF, as it is already mentioned as a part of MOF. Furthermore, the Authority step returned during Process number three of the Envision phase, as an approval of the vision and scope document is needed here.
As the initial legal and compliance studies are handled in the early stages of the project, one could argue that the premises of the project is not sufficiently stated, and that the foundation of the studies are weaker than if such were to be performed at a later stage. Even though this is true, it is important for the organization to approach such requirements early, thus uncovering clear breaches that might lead to problems later on in the project. We see no reason why such studies cannot be performed during the later stages of the project, but these should be performed in addition to the initial studies to be certain that the premises of the implementation is valid from the start.
We then move on to the Project Planning phase which starts with the choice of tech- nology. This meant that the Resources section of the requirements document was placed
here in order to map the available hardware resources. This aligned nicely with the MOF section called Customer Baseline, which amongst other things mapped the customer’s in- frastructure for assessment with possible products. The requirements for possible cloud deployment models, cloud service providers and cloud vendors then followed, which could be assessed against the customer baseline.
After this, the Detailed requirements of the requirements document was used in its entirety, as these related well to the user, operational and system requirements of the MOF model. The security requirements were also incorporated into this section to assess the security demands of the noted requirements. This concluded the mapping of the requirements guide to the MOF phases, as the Operate phase was out of scope for this study.
One problem encountered was that MOF advice that a choice of technology (deploy- mentmodel/servicemodel/CSP) is chosen before detailed requirements are created. We decided to try the MOF approach, and chose the technology before exploring detailed requirements. This shifted around some of our requirements sections, and we had to rely on the high-level requirements to guide the choice of technology.
A benefit of this approach is that one will be able to tailor the detailed requirements to the chosen technology. A drawback is that the choice of technology is based on a weaker foundation. No additional issues emerged because of this, and we find that choosing the technology early is a good idea especially if all, or parts of the technology are already stated in the preliminary planning stages.
We find that the sections of the requirements document were incorporated into the existing MOF methodology without any severe problems. This strengthens the belief that the guide is framework independent, and shows the flexibility and adaptability of the requirements document. We cannot, however, state that this is a proof of framework independence, and several other methodologies would need to be tested in order to solidify the claim. In addition, the tests should be performed during a real project, and not be limited to fictional cases.
6
Discussion, Further Work and Conclusion
In this chapter we first present a quick summary of the thesis results. After this the the- oretical and practical implication of our research is presented, discussing how the results may improve the process of planning and developing governmental cloud implementa- tions. At the end of this chapter the conclusion of the thesis is presented, and possible areas for further studies are proposed.