Capability Maturity Model for Software - Assignment Example

Assignment 2 Draft

Abdul Alsalem

ID1260029

Introduction

It is virtually impossible to build any software without first identifying its requirements. The requirement gathering phase is the initial stage of the software development cycle. This is the stage where software developers and engineers gather specification information from the clients and users. While many techniques exist, there applied in certain circumstances and in many cases multiple techniques are used for the same project. Software developer ought to understand that they are building software products not for themselves but for the clients. In that case, requirement gathering procedures become an integral part of any software development cycle, where clients and users are involved (Turban, et al, 2005).

Planning and developing large systems is like playing a multilevel chess game, it is always a demanding process that calls for absolute attention. Software projects are usually furnished with new information based on a dynamic business opportunities and user needs. A software development cycle iteratively incorporates such information to produce better versions of software products. In that case, most software gathering techniques are iterative. Methods such as rapid application development, prototyping are examples of such iterative approaches. On the other hand, some methods might stand out of the development cycle and not necessarily repeat themselves. Joint Application Development (JAD) is one such method, though its aspect of iteration is vague dependent on its application on different software development projects (Turban et al, 2005, Chung & Cooper, 2003).

Requirement gathering is not the only critical component of the software development cycle. Once developers/engineers and clients agree upon common specifications, the framework for acquisition must also be discussed. Organizations have a variety of acquisition methods based on the needs and financial capability to acquire new software systems. In-house development, acquisitions of systems from vendors (COTS) and the use of application service providers (ASPs) are methods used to acquire new software. The efficiency of each method can only be truly understood if it’s practically applied (Turban, 2005).

Critical Review of the JAD Methodology

The JAD requirement gathering methodology is a cooperative method that involves users, project sponsors and developers in a single forum. In this manner, their role is to actively participate in the software specification process. Project sponsors and other managers have the last say on the structure of the product, (Bass, 2006; Turban et al, 2010). While JAD is methodology that is commonly used to assess the requirements of given software, there are other assessment algorithms that give structure and order to the process.

The Rapid Application Method (RAD) is another requirement gathering method. RAD is similar to JAD in some aspects. RAD integrates some aspects of JAD, such as client inclusion in the development process. However, RAD differentiates from the JAD progress by integrating other methods such as CASE tools and prototyping to develop software systems. RAD uses an iterative approach unlike JAD, where requirements, design specifications and the software products are refined in sequence. On the other hand, JAD is not an ideally iterative gathering method. JAD sub processes are distinctively separate. RAD emphasizes speed in the development process whereas JAD concentrates on delivering a high quality product. Using a RAD approach enables developers to improve the initial versions of a software product until it attains operational capability. JAD and RAD requirement gathering approaches all involve clients and users in the earliest phases of the project (Turban et al, 2005).

The JAD approach can also be compared to Prototyping. The latter is a requirement gathering approach where developers build an initial stub based on general ideas from the client. Unlike JAD, Prototyping can only be used where a customized version needs to be built or when a client opts for a new development. Developers develop a small scale working model of the entire system using features that interest clients and users the most. User interaction is limited in Prototyping, while in JAD both clients and users are involved early in the project. However, the Prototype method allows the users and clients to review versions of the products in a bid to improve it (Turban et al, 2005; Bass, 2006).

JAD, RAD and prototyping share a number of advantages. One of these advantages is time efficiency; since users, analysts, sponsors and the developers are physically involved in consultative meetings, there is less overhead time. Users simultaneously agree on system specifications, therefore saving valuable time meant for development However for RAD, there is a big likelihood that users will appreciate the product. Moreover, all methods strive to minimize maintenance costs and make the implementation process manageable. Unlike the RAD method, JAD and prototyping has the ability to reduce the number of cycles a project has to go for it to become efficient. Additionally, prototyping is suited for the development of decision support system and information systems where user interaction is frequent. Moreover, JAD and prototyping base their software revisions on client and user reviews which can make them sturdier than software built through the RAD method (Turban et al, 2005)

A comparison of their demerits shows that each has unique disadvantages. Even though prototyping results into user friendly products, it is might largely replace analysis and design stages of the project. This implies that developers will not be able to develop consistent documentation for users (Turban et al, 2005). RAD disadvantages are also unique. Software development with RAD results into software products which have limited functionality. Critics might argue that these products are of less quality. Additionally, RAD might not be able to effectively respond to changing business conditions. Consequently, RAD-developed software products might have a short shelf life. Unfortunately, for complex projects with large data sets RAD implementation might involve an infinite amount of iterations which is undesirable (Turban et al, 2005). On the other hand, physical meetings of all concerned parties do not guarantee that users and clients in the JAD process will actively participate in the meetings. Additionally, a JAD approach is not suited for mission critical or technical projects, where user inclusion is limited in productivity. It is evident in the JAD-based project, sponsors and clients might have different motives and aspirations that impend a uniform development environment. Concentrating on the business side of the project slows down the pace of the technical aspects of the project (Turban et al, 2005).

An analysis of the pros and cons of these three models does not necessarily reveal the superiority of one approach over the others. However, it implies that some models are more suited for some types of developments than others. In this specific class project a JAD approach was not efficient since there the client incentive for the project was business-oriented. Additionally, because the company’s needs were unique, prototyping could have adequately been used to develop a system based on the client’s basic specification. This could have saved the client financial losses due to downtime of essential IT services. Additionally, the project would not be subjected to infinite iterations to achieve a minimum standard of quality for his product.

A Critical Analysis of the COTS Model

Businesses use variety methods to acquire software systems based on the needs, costs and the profits they derive from these systems. COTS is one of these approaches that clients use to acquire software products for their businesses. COTS procured systems rely on initial analysis to determine whether existing software solutions offer near functionality for clients’ needs. Additionally, vendors determine whether the client’s non-functional specifications can be met by existing products. Moreover, the analysis assesses the vendor’s willingness to cooperate with client in terms of issuance of rights and consequential maintenance of the systems. In general this analysis does not just focus on the product characteristics but also on the vendor’s disposition.

COTS acquisition plans tend to be less costly than other approaches since the cost of development is spread out across all consumers. Nonetheless, the amount of time used for integration into the business system is greatly reduced because there is less development time. COTS also offers a wide platform of user reference through which businesses can refer to get valuable operational information on the systems. Additionally, packaged software is robust because it undergoes numerous iterations of ‘bug-fixing’ and enhancement. However, it is not always profitable for businesses to acquire off-she-shelf information systems. Large enterprises usually have specific software needs that cannot be met by existing software. Additionally, the cost-benefit ratio of buying these software packages is low. The time companies spend on optimizing purchased software to suit their organizational needs is immense. Vendors might distance themselves from costly bug fixes and force companies to fund software changes using their own resources. Sometimes glue coding the purchased software to fix existing differences between software packages and the host systems might expose businesses to numerous losses due to down time and loss of information (Morisio, 2002).

Custom development is another widely used acquisition plan. Large companies might feel they have specific needs that would not be well serviced with existing software. Therefore, they might opt to make their own custom software. In house development can be achieved by a variety of methods. In-house custom development involves the use of an IT department in the organization. However, this method might become expensive for small companies who cannot afford an IT department. Companies might opt to outsource system and software developers from other companies to reduce costs. Though custom devised software serves company needs, they might be too costly to realize any benefit from their consumers. Additionally, software defects might cripple mission critical systems or business systems with a large influx of customers.

Contemporary business computing has ushered in a new era of computing known as cloud computing. Cloud computing has many options; public computing, private computing and hybrid computing. In this case public computing provides the greatest benefits to the client’s with medium-sized and large companies. Companies that need IT services for their company might obtain SaaS (Software as a Service) applications from application service providers who have a well implemented cloud networks. This saves the company a considerable amount of money that would be used in a COTS acquisition approach. One major advantage of public cloud computing platform is the ability to scale up resources when the demand is high. Companies are often inhibited by redundant systems which cannot match consumer demand; therefore, limiting their potential to earn more money from their ventures (Dialogic, 2015).

However, cloud computing platforms might have critical security flaws, which can expose data-dependent companies to massive infiltrations and financial losses. On the hand a company might opt to acquire a private cloud for security and stability purposes. Although this option is more secure, it hits companies with more costs than other options. A cross comparison between the COTS acquisition plan and the Public Cloud SaaS option shows that the cloud computing approach is more feasible than the other. In the case of the project, cloud computing has considerable cost incentives for the client since major development and maintenance costs are leveraged to the cloud platform providers. Additionally, the cost-benefit ratio is high since cloud platforms can be used as marketing platforms for this expanding business (Dialogic, 2015).

Microsoft is one company that offers SaaS for business. Microsoft hosts Enterprise Resource Planning (ERP) software on its cloud platform known as Microsoft Azure. Microsoft Dynamics GP®, an ERP software gives small business with great growth potential the ability to expand their IT systems without necessary hardware updates. Microsoft Dynamics GP initial costs are up to 40% cheaper than the COTS-acquired software. Moreover, COTS acquired software has a constant price whereas cloud-deployed platforms such as Dynamics GP are priced depending on the size of the business. Therefore, SMEs can significantly cut their IT costs by using cloud platforms. Microsoft GP combines a lot of functionality to give businesses a wholesome package that include accounting tools, human resource management tools, an inventory management kit among many other capabilities. Business also have the ability to scale up whenever demand rises without having to worry about the downtime costs. Nevertheless, a tool such as Microsoft Dynamics GP offers business valuable analysis that they can use to optimize their business operations (Microsoft, 2016).

Reflection on the JAD-Based Group Work

The meetings were exhaustively used to obtain the client’s vision of the project. However, member contribution to the interview was fairly low for some members because members had just started their final year project, and honestly it was hard for them to juggle between the two events.

The members of this group did a number of face-face meetings, while other meetings were held through the Google Hangouts platform. The customer contribution to the JAD process was also fairly low; on average there was an average of 17% client participation. In the end, we realized that it was better to focus on the IT aspects of the project rather than the business part of it. It would have been ideally easier to build a prototype first then modify the prototype to fit iteratively fit client’s specification.

Commentary of the Groups Capability Maturity Model Level

The Capability Maturity Model (CMM) is a standard model that can be applied to assess the development of a software project. Basically there are five levels in the model; chaotic, repeatable, defined, managed and standard. These levels define the level of organization within a software development process. The highest level is level five (standard) and the lowest, level 1(chaotic), between these two levels there other three levels which define how a development project is progressing (Paul, 1993).

This group has only been able to attain level 3, which is the defined stage. According to the CMM protocol, software development processes belongs to the third stage if there are well established processes. These processes can be able to track costs, schedule and check the functionality of the whole program. Additionally, the necessary protocols are in place to ensure a rigid development discipline is followed (Paul, 1993). Currently, we have been able to formally identify the customer specifications through a standardized JAD approach. Moreover, the customer has identified the procurement processes through the COTS approach. It signifies that the necessary mechanisms are already there to allow the acquisition of the software.

The group is unable to progress to the next level, which is level 4 (managed), since the client has not been able to install the software system. Once this is done the group will be able to progress to level 4 (managed) in good fashion. Additionally, the aim of the group is to reach the highest level possible in the CMM hierarchy. This can be achieved once the software is updated on the client’s systems. At this stage the reviews generated from the client’s systems and opinions from the client himself will be used to improve the system through a competitive improvement process.

Conclusion

Summative of this report, one can abstract that software development is an incremental process. Progress made on previous stages becomes the basis for future development phases. Among the first stages of the software development cycle is the requirement collection phase. During this phase the developers collaborate with the clients and potential users to abstract the general specifications for the project. There are a variety of methods that can be used to gather information from the clients and users among them is the Joint Application Development model (JAD). While there are other available approaches, the nature of the project usually determines the choice of model. Similarly, businesses can use a variety of methods to acquire software tools. The Commercial-of-the-Shelf model is an affordable approach for enterprises without unique IT needs. However, the advent of cloud computing has opened new opportunities for the software franchise business. Cheaper cloud computing platforms are currently reducing the need for buying of-the-shelf software. Among all other platforms, cloud SaaS platforms are suitable for businesses who need speed, reliability and scalability in their businesses.