Knowledgeware

Abstract

This paper introduces a controlled software process that is reusable for the management of Knowledgeware. The development of good quality software is a critical element of successful competition in today's ever changing software market shares. However, the making of these software are becoming more complex when requirements are hardly known whilst the product time to market is short.

A component based design incorporated into an iterative incremental software development focuses on generating early releases of working products by aiming to deliver business value immediately from the beginning of the project. Regardless of the development method in use, it is important that software developments are constructed in a controlled manner.

1.0 Introduction

Knowledgeware is a subsidiary company of BizSoft which has just been recently set-up. Knowledgeware's functional business entails exploitation of newer technologies which involves the analysis of large and often disparate bodies of organisational data for patterns that could potentially be used to improve a number of different aspects of their clients business. This is based on BizSoft's data mining and data integration back-end, Genetic Algorithm (GA) technology with visualisation front-ends that are customised to specific user requirements. Though, client's requirements are vaguely defined and the time to market for the products is short.

The aim of this paper is to provide the management of BizSoft a software process model that will ensure that Knowledgeware meets their client's commitment. Section 2 provides a breakdown of the problem analysis, section 3 looks at the software project characteristics, section 4 provides a guarded software process solution to the issues found. Finally section 5 concludes the paper with some process improvement and future recommendation.

2.0 Problem Analysis
2.1 Exploratory design, Implementation and Documentation

Examination of the existing process used during the pilot project reveals some flaws about the way Knowledgeware underwent their application developments. The design phase was done in an exploratory manner in that the products were designed to explore the data whilst the output result was also not defined. This eliminates a well-structured process of analysis and design stage of the given system under construction. More so, no real specification will be produced which makes verification and validation difficult when the system keeps changing. As a result, process documentation is very minimal, which in turn makes system maintenance complex to achieve.

2.2 Lack of change control

A simple requirement or design change to the system without an assessment of its impact on the overall project will produce a negative outcome in terms of cost, scheduling and resources, when requirements are added, deleted or modified out of a controlled environment within the system (Wiegers, 2003, p.328).

2.3 Insufficient planning and estimation

The pilot project overruns its schedule due to inadequate planning and estimation which puts constraints on other resources i.e. budget and cost.

Lederer and Prasad cited in (Pfleeger and Atlee, 2009, p.131) identified insufficient analysis, frequent changes and lack of proper understanding leads to inaccurate planning and estimation.

2.4 Inadequate Risk Management

Elimination of the analysis and design phase leaves little or no room for risk assessment, which means the system will be built with unidentifiable risk. Furthermore, unrealistic schedule, budget and continuous changes increases the project risk (Hughes and Cotterell, 2008 pp.162-167; Pressman, 2005, p.728,).

2.5 Lack of understanding

It was also observed that the pilot project was highly speculative from the onset. They is an assumption that some of the system requirements are known but getting the best use out of it is unclear. These difficulties arise as a result of vaguely defined requirements which lead to lack of understanding. 1 illustrates the current software process in used at Knowledgeware.

3.0 Project Characteristics
3.1 Changing Requirements

As the business analyst works closely with the customer to provide a solution, existing systems requirements will evolve as soon as the customer's gets an understanding of the solution. More so, non-existing requirements will continue to emerge.

3.2 Risk Management

(Barry Boehm and Jo Ann Lane)

No software development is free from risk, and one crucial activity of development is identifying and managing it. Managing risks requires an early identification of any threats to the development or operation of a system, and then monitoring these threats during development. In an iterative and incremental development, risks in the development stage can be tightly monitored and controlled. The emphasis on short cycles that lead to early implementation helps to address technological problems from the start. The planning and prioritising of increments is done taking into account the risks that may occur. Unforeseen problems can also be avoided by starting the integration of increments early.

Risks are mainly associated with making decisions that may be wrong and with misunderstanding requirements.

3.3 Time to market and Project duration
3.4 Reuse of components
3.5 Early Customer feedback

Early feedback from the system stakeholders is very important in order to ensure that requirements are captured and implemented properly. More so, it act as a means of system validation for the stakeholders.

4.0 Controlled Process

According to (Nuseibeh and Easterbrook, 2000) “the primary measure of success of a software system is the degree to which it meets the purpose for which it was intended”. In order for Knowledgeware to achieve customer's expectation they must adopt a process model that helps in ascertaining that purpose. By working closely to understand the needs of their stakeholders, analysing, documenting, and communicating customers need across the process for proper implementation.

4.1 Requirements Gathering with Analysis and Design

The first stage of any software business proposal is to determine the wants and needs of the business from the software application. Requirements describe what the system will do, and this allows the business analyst, developers and the stakeholders to come to a conclusion on the description during and after the research; a process known as requirements elicitation which in turn leads to analysis of the educed requirements and negotiation of gathered information (Sawyer et al. 1997).

The next stage in the process is to analyse the requirements and draw a systematic architectural design which will enable developers to build the system in a component-based manner (Chan 2004; Hull et al. 2001). The purpose of this design technique is to enable software reuse, lessen cost and identify risk (Crnkovic et al. 2003; Rothenberger et al. 2003; Nuseibeh, 2001). According to (Sommerville, 2007, p.70), “component-based software engineering has the obvious advantage of reducing the amount of software to be developed thereby reducing cost and risks, which also leads to faster delivery”. However, for a faster delivery to happen the proposed model needs to be managed effectively.

Since Knowledgeware are dealing with different bodies of organisational data, it is essential that during the analysis and design phase the data structure is agreed. This will enable developers to build components in relation to the way the data are structured for respective components (Jasmine and Vasantha 2007; Sommerville, 2007, p.440-443). More so, any dependencies that exists between components are fully specified (Budgen, 2003, p406).

One of the side effects of component-base design is that changes are inevitable (Crnkovic and Larsson 2001), thus it's essential to structure and baseline the design such that changes as a result of requirements evolvement are controlled in a versioned comportment. Version control and baselining will be discussed further in section 4.3 under management and documentation.

Early feedback from system stakeholders will help stem issues of numerous modifications to the system. Furthermore, all the proceedings between the business analyst and stakeholders are documented to identify evolving functionality and system constraints (Sawyer et al. 1999). However in this case, client requirements are loosely defined which makes it difficult to identify essential functionality, risks and system constraints. Although, it is often noted that most clients know what they want but they cannot articulate what they know (Larman and Basili 2003). A solution to this problem is to build a rapid prototype of the system's user interface so that user can relate with the prototype interface for better expression on how the system component will be placed and the interaction among the system components (Pfleeger and Atlee, 2009, p.299; Scacchi 2001), as this will help in clearing any uncertainties. Extracts from the case study shows that the requirements are vaguely defined; hence an evolutionary or throw-away prototype will help in gathering more requirements, noting issues, logging risks and design validation (Pfleeger and Atlee, 2009, p.77; Sommerville, 2007, p.377, p.381 and p.395). 2 shows the process feedback between prototyping and design via requirement gathering.

4.2 Model implementation and its rationale

Due to the time constraint, associated risk and continuous refinement of requirements understanding, it's crucial for Knowledgeware to adopt a software process model that will accommodate all these instances.

4.2.1 Rationale

Earlier on in section 4.1 we used a prototype to aid the system understanding and design. The prototype system can either be used in a combined process of a linear sequential model and incremental process model or each model individually. The table below shows the process combination. For ease of understanding each box in table 1 is given a quadrant number in a clockwise manner.

Linear Sequential

Iterative

Big Bang

Quadrant 4

Quadrant 1

Incremental

Quadrant 3

Quadrant 2

Table 1 Process combination (Mark Udall, 2009)

Models found in respective quadrants

Quadrant 1 which represents iterative/Big-Bang:

Quadrant 2 which represents iterative/Incremental: Spiral (Boehm, 2000), RAD (Budgen, 2003, p.242), RUP (Rational, 1998), Evolutionary Development (Budgen, 2003, pp.245-246), DSDM (Pressman, 2005, pp.116-117), Extreme Programming (Patesch et al. 2003), Crystal (Hughes and Cotterell, 2008, p.92) and Scrum (Pressman, 2005, p.116-117; Schwaber 2000).

Quadrant 3 which represents Linear Sequential/Incremental: Waterfall and Evolutionary Development (Scacchi, 2001).

Quadrant 4 which represents Linear Sequential/Big Bang: Waterfall (Cusumano and Smith, 1995), V-model.

Following on from table 1, first we need to determine the driving factor that prompts the use of these models. This is illustrated in table 2

Iterative

Linear Sequential

Characteristics

Big-Bang

Incremental

Incremental

Big-Bang

Risk

Medium - High

High

Low

Low

Changes

Likely

Likely

Unlikely

Unlikely

Team Experience

Medium

Low - Medium

Medium - high

High

Duration of Project

Long

Short

Short

Short

Requirements

Loosely defined

Loosely defined

Properly defined

Properly defined

Technology skills

Medium

Low - Medium

Medium - high

High

Project size

Big

Big

Big

Small

Time to Market

Short

Short

Short

Long

Table 2 Project characteristics of Software Process Model.

Looking at table 2, it's obvious that Knowledgeware will have great difficulty in putting into practice a linear sequential model in that it requires a well defined requirement, hardly caters for changes, has a low risk and the model is implemented by a well established team. A motion to support these claims comes from various material sources, firstly, in the linear model there is a need to establish what is required of the final system from the onset which is often impractical with the assumption of unlikely changes to the system under construction (Pfleeger and Atlee, 2009, p.76; Jalote and Agrawal 2005, Budgen, 2003, p.51; Hawryszkiewycz, 2001, p.116-117, Scacchi 2001; Martin 1999; Boehm, 1996). Furthermore, other sources like (Sommerville, 2007, p67) and Royce the inventor of the waterfall model as cited in (Abbas et al. 2008) went on to say the model is not really linear in that it involves some cycle of iterations activities. More so, it pushes risk forward in time if the design is wrong (Kruchten, 2001).

A suitable model for Knowledgeware will be an iterative incremental model. Reason being an iterative incremental approach delivers a working version of the software to the customer in each iteration with the highest prioritized functionality in early stages (Boehm and Lane 2007; Sommerville, 2007, p.84; Jalote and Agrawal 2005; Hull et al. 2002). It also manages evolving requirement, control changes, mitigates risks at early stages, helps in team leveraging lesson learnt (Kruchten, 2001). Unlike the iterative big-bang model which delivers the software in a longer duration, the iterative incremental model delivers in a shorter time (Gerogiannis and Ipsilandis 2007; Jalote et al. 2004; Paasivaara and Lassenius 2004).

Going back to table 2, the iterative incremental model has different models identified under quadrant 2. As an alternative to implementing a specific model under this quadrant, Knowledgeware will execute a combination of these models in that most of the models have similar merits and different demerits; however, these disadvantages will be catered for in a tailored iterative incremental development to suits Knowledgeware's need.

4.2.2 Implementation

The first step during implementation is to build some of the prioritized system functionality. (Kruchten, 2001) observed that an attempt to fit all the functionality into the first iteration is like going in the opposite direction. In order to avoid this situation it is essential for Knowledgeware to form a team of trained staff on new techniques and tools to be used. Reason being Knowledgeware's staff experience ranges from lowly experience graduate to moderate experienced developers.

The iterative incremental model proposed for Knowledgeware will be timeboxed. The use of a timeboxed ensures that fixed functionality are built within the allocated iteration time frame, therefore when existing requirements evolve and new requirements emerge they are scheduled for the next iteration (Gerogiannis et al. 2008; Cockburn 2008; Jalote et al. 2004; Larman, 2003, p.248). Each iteration is allocated a time frame of 3 - 4 weeks based. For instances let say the prototype system has taken 2 months to educed requirements, design, implement,test, produced some form of artefacts and the entire project length is 6 months. This means the iteration stages are divided into 3 with some few weeks left for some project contingency.

Early on in the project tests are designed against the system functionality. These test cases are then enhanced during each iteration process for testing the newest functionality once requirements begin to evolve and emerge (Pfleeger and Atlee, 2009, p.447; Sommerville, 2007, pp.547-553). More so, all the features are thoroughly tested; any errors found during test are re-built and tested again for impact analysis. If the product is robust enough then stakeholders are invited to get a feel of the system. Whilst the next enhance version of the product goes through the all process again within its allocated period (time boxed) until a complete working version of the product is built within the project duration. 2 shows the complete process model for Knowledgeware.

4.3 Management and Documentation

It is evident that one of the main advantages of an iterative incremental development is the ability to adapt and respond to changes; on the other hand these changes can as well render the process model to be ineffective when changes are not managed and controlled efficiently. Hence, there is a need for continuous process management for each activity in order to control and minimise risks.

4.3.1 Configuration and Change Management

As requirements evolve during and after elicitation, it is important to manage the changes being made to the requirements document (Nuseibeh and Easterbrook 2000). In order to manage and control changes effectively, a change control and traceability policy process has to be established. This will ensure that changes are analysed in terms of cost, scheduling, resources and estimation of completion. This also provides a means of communication among the project stakeholders (Wiegers, 2003, p.332; Peter and Pedrycz, 2000, pp.82-84). The traceability policy will ensure that requirements are uniquely labelled through the use of a traceability list by mapping requirements in a one-to-one, one-to-many and many-to-many interaction among system elements (Sommerville and Sawyer, 1997, p.229). The purpose of the list is to aid system design coverage for existing and emergent requirements when changes are proposed (Ramesh and Jarke 1999; Pfleeger and Atlee, 2009, p.223).

Furthermore, the process documents have to be baselined whilst subsequent updates to the documents and iteration releases are versioned controlled (Sommerville, 2007, p.690; Koskela, 2003; Estublier, 2000). This will ensure that the customer and Knowledgeware have an understanding of what the end product of the systems iteration will be like and any proposed changes will need to be formally agreed through the control board via a change request form. Another valuable option for managing changes in a timeboxed process is to treat the change as a new requirement and cater for it in the next iteration (Jalote et al. 2004).

4.3.2 Process documentation

The essence of documentation is to ensure that the latest information is being acted upon, as well as helping to track the development life cycle and maintenance of the system (Pfleeger and Atlee, 2009, p.219; Sommerville, 2007, pp.136-139). However, documentation are regarded as part of the project deliverable in that each phase of the process produces some form of document as an output (Hawryskiewycz, 2001, p.136). 3 illustrates the associated documents produced by each activity in the process model; however, these documents are subsequently updated for each iteration.

5.0 Conclusion

This essay has critically reviewed the current software process model being practised at Knowledgeware by analysing the existing model, evaluating the characteristics that suit the process model there by proposing an iterative incremental approach.

The iterative incremental implementation development approaches ease the evolution from analysis and design into implementation. It gets the development teams going and helps them produce concrete, repeatable results in the quickest, most cost effective manner with a minimum amount of rework in a controlled process managed effectively. Finally, a future recommendation of iterative pipelining can be implemented once the team is sufficiently experienced and used to the proposed process. However, the management of Knowledge has to advocate a continuous process improvement.

References

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!