It is noted that modeling techniques envisage capturing the inputs, processes, and the deliverables in an agreed environment. The modeling process argues in favour of measurements and establishing certain standards to validate the outcomes. Therefore, it is important to establish methods for validation of the model. This chapter discusses a framework for the assessment of preparedness in each phase of the model with support from various existing models associated. It includes broad understanding of the whole gamut of the challenges related to IT acquisition preparedness exercise across all the phases. Goal-Question-Metrics (GQM) principles are adopted to validate various hypotheses developed to assess phase specific deliverables. This process is described in detail to appreciate the cyclic behavior of the assessment model conceptualized for an IT acquiring organization. It is also indicated that this framework can be used at any point in the acquisition life cycle.
TopRole Of Modeling Techniques In Software Engineering
Historically, the introduction of IT has been characterized by a series of major deployments occurring at intervals often measured in years or even decades. These long cycles of times reflect in part the traditional waterfall acquisition process. This form of acquisition model presumes a linear development process that proceeds in stages from development of a comprehensive requirement specification to design, implementation and integration, next to testing, installation and maintenance. Furthermore, modified versions of the model acknowledge some role for feedback between each of these stages (Boehm, 1981).
The Software Engineering field has been primarily focused in information systems development improving the reliability and efficiency of data services. However, the current users of these services are being increasingly interested in deeper functions integrated in the information systems supported by the knowledge related with the data conceptual domains (Cuena and Molina, 2000).
It is evident from contemporary literature review that preparedness of an organisation is least addressed during IT acquisition process at macro level while each element in the organisation such as suppliers’ credibility assessment, understanding acquisition process on project mode and even assessing user’s involvement with respect to IT acquisition success are discussed in isolation (Misra, Satpathy & Mohanty, 2007). Furthermore, the discipline of IT architecture and engineering (especially, software architecture and engineering) is relatively immature in comparison to other disciplines (AFEI, 2010).
In recent years, a wide variety of non-standard software solutions are in use. This sort of approach limits effectiveness and increases cumulative costs in deploying IT resources. In order to address this type of situations, various software engineering models have argued in favour of analyzing the need for deliberative IT acquisition processes that include requirements gathering, strategic mission alignment, cost benefit and alternatives analyses (Robillard & Sambrook, 2008; Brown, 2010). It is often argued that best practices for IT acquisitions should include an emphasis on iterative development, increased opportunities to test and evaluate technology in practice, and capture realistic concepts of operations. The best practices also look for organized processes for design and evaluation of systems that provides scope for strong coupling among practitioners, researchers, and industry (National Research Council, 2007). However, due to long IT acquisition cycles, it is considered difficult to incorporate rapid technological changes while ensuring the tight coupling of the stakeholders’ views. Due to rapid technological changes, IT acquisition life cycles are shortened though organizations are tempted to acquire new technologies because of the premium in value added benefits. But this form of linear IT acquisition process often fails to deliver the expected IT capabilities in the organization. Furthermore, requirement elicitation crawl may end up making the ultimate design overly cumbersome, complex, or costly to implement, leading to cost overruns, delays, and even program cancellation. Additionally, users, who not only have input to the front end of the process, may find that the IT process capabilities delivered do not meet their needs. In circular reference, new process capabilities, new technology opportunities and ever increase in requirements make the systems developed unsustainable. Thus systems developed become difficult and expensive to manage changes dynamically. Though many artifacts of a system grow organically, reality is that large systems emerge from incremental additions in ways entirely unanticipated by the designers of the original systems. If the original system is successful, users will almost certainly want to add new functionality.