Software process models

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

<!-- martinchinwe -->

<ins class="adsbygoogle"

style="display:inline-block;width:728px;height:90px"

data-ad-client="ca-pub-3432567292388333"

data-ad-slot="3193770573"></ins>

<script>

(adsbygoogle = window.adsbygoogle || []).push({});

</script>

to software process model

Selecting a Software Development Life Cycle (SDLC) methodology is a challenging task for many software development organizations. What makes it challenging is that only few organizations know the criteria to use while selecting a methodology to add value to the organization.

Table 2.0: factors for selecting a model

It is unfortunate that many software developers do not know that a model can apply to more than one Life cycle Model. To be able to choose the right model, it is necessary that the development organization study the business domain, user requirements, business priorities, and technology constraints be able to choose the right SDLC against their selection criteria. Some software models and where they can be applied is shown in table 2.0 [1].

Factors Affecting Stakeholder Participation

There are several factors which will impact the nature and quality of how stakeholders participate with a solution delivery team. These factors are summarized in Table 2.1.

Table 2.1: The factors impacting stakeholder participation on IT projects.

2.2. FRAMEWORK ACTIVITIES

The framework activities are based on a software process model that is suitable for all the projects that an organization undertakes [1]. Framework activities that can be applied to every project is called a common process framework. A common process framework (CPF) is a generic process framework that defines the broad activities that apply to all projects regardless of their characteristics. A project team can adapt the CPF to arrive at the process definition for a project. Any software process model consists of five activities [2]. These activities are called framework activities. A good process model must be able to define a set of framework activities that is applicable to any type of project [3]. The Association for Project Management defined a set of framework activities which has five activities. Each of the framework activities will occur in every project. However, the set of tasks or task set that is defined for each framework activity will vary depending upon the project type and the degree of rigor selected for the project. Therefore, a Concept Development Projects will have a different task set than Application Enhancement Projects [3]. These five framework activities are as discussed below:

Requirement Phase

The requirement is the first stage in the waterfall model. No matter the size of the software, this is the first stage, which can never be overridden. This is because no developer can develop effective software without understanding the problem perfectly. The requirement stage of waterfall model is some time regarded as the planning stages. It is made up of the following task sets:

· Scope definition

· Stakeholder identification

· Requirement gathering

· Requirement analysis

· Requirement specification

Scope definition

The scope definition defines the domain of the problem, the area of coverage.

Requirement gathering

The requirement gathering is the first activity in a framework activity sets. It is required to establish effective communication between developers and customer(s) and to define requirements for the work to be performed. It may involve inviting stakeholders, users, clients, the domain experts in meeting to discuss the functionality and attributes needed in the final product.

Requirement Specification

This is the document containing the decision reached after the analysis of the requirements and constraints available. The exact way in which the software should function is mentioned in this stage.

Design Phase

The actual work in software development starts at the design stage. It determines the quality of the software. Every type of resource which will be required for the smooth designing of the software is applied in this phase. What type of database will be required, what type of data should be supported, and so on are some of the important aspects that are decided in this phase. The algorithm of the process in which the software needs to be designed, is made in this phase. The algorithm forms the backbone of the actual coding process that takes place in the next phase. The design phase is made up of the following tasks:

· Data/class design

· Architectural design

· Interface design

· Component design

Implementation stage

The implementation stage is where the coding takes place. The software is coded as based on the algorithm selected. Hence it becomes very important that the algorithm should be properly designed. The software developer needs to go through constant software testing and error correction processes to ensure that there is no flaw. Normally, during the implementation stage, the software is divided into modules using the principle of separation of concern to reduce complexity. This principle states that the software should be divided into modules such that each module handles one main feature at a time to reduce the complexity of the system. This method is known as divide and conquers. After programming, the different modules developed by different programmers are unit tested, integrated and tested to know if the software works according to the specifications provided. This activity required to create one or more representations, generate code and conduct thorough testing.

Executing consists of the processes used to complete the work defined in the project plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan and other frameworks that might be applicable to the type of project at hand.

Execution process group include:

Direct and Manage Project execution

Quality Assurance of deliverables

Acquire, Develop and Manage Project team

Distribute Information

Manage stakeholder expectations

Conduct Procurement

Testing stage

In the testing stage, the integrated software is fully tested and all the discovered error corrected before it is sent to the client. The setup of the final software which needs to be installed on the client system is also designed and tested, so that the client does not face any problem during the installation of the software.

Deployment stage

At the deployment stage, the product is then handed over to the client. The client will evaluate the product based on the agreed requirement specification. If the product meets the specified requirement, the customer will accept the product and the developer will be paid. However, if the product did not meet up with the expectation, the developer may face mitigation in the law court for time wasted

Maintenance Phase

The cycle of software development does not end with handing the software to the client. Software designers may have to constantly provide support to the client to resolve any issues which may arise. During the maintenance phase, support and debugging is provided for all such problems.

It should be noted that these phases are the same for the any process model. However, the umbrella activities (actions and task set) are not the same.

Decommissioning

The decommissioning occurs when the software has been maintained for so long that it has deteriorated. At this stage, the software is thrown away and new software development.

Waterfall model

The first work on waterfall model was done by Winston Royce in 1970 [2][3]. He recommended that waterfall model should be applied after a significant prototyping phase had been used to understand the core technologies to be applied and the actual requirement that the customer needed. The waterfall model is a one of the traditional process models which use a step-by-step method to achieve a task. It is a linear and sequential process model in which one stage of the process model must finish before the next stage can commence: The output of a stage is an input to the next stage [4]. In a pure waterfall model, there is no movement to the previous stage during the development; once a stage is completed, it will never be revisited for modification. In this model, each stage proceeds in order with no overlapping during the development process. For that reason, the waterfall model requires that all the requirements must be available before the development can commence since further changes in requirement will not be considered later. Meanwhile, in real life, it is always not possible to gather the entire requirement within a finite time interval. This due to the fact that the requirement needs of client changes with time and may like to incorporate the new requirement in the software. Because of the lack of iteration in the waterfall model, it is inflexible and therefore does not respond to changes. The block diagram of a pure waterfall model is shown in Fig. 2.1.

The pure waterfall model applies verification and validation to each stage before moving to the next stage. If a stage did not give positive results during verification and validation, the developer will remain there until a positive result is obtained. Meanwhile, in most cases, the defects in waterfall model are detected at the testing stage only since testing team is not involved in other stages [4]. It is to be noted that the waterfall model is time wasting since the teams to work on the next stages will remain idle until the preceding stage is finished. Verification at each stage ensures early detection of errors / misunderstanding. It should be noted that each phase has specific deliverables.

Assumptions of waterfall model [5]

The following are the assumptions of the waterfall model

1. Requirements are completely before design begins

2. Requirements rarely change

3. Users know what they want and rarely need visualization

4. Design can be conducted in purely abstract space and trying rarely leads to error

5. Systems are not so complex

6 the technology will all fit nicely into space when the time comes

Application of waterfall model

When the requirement is stable and unchangeable

Since the waterfall model does not allow the changes in the requirements at the late later stage of development, the model is used only when the requirements of the system are fully understood and gathered and changes in requirements are limited to the requirement available at the commencement of development [6].

When the clients are not accessible

It is used for software development for multiple clients that live at different and remote areas from the developer. This becomes necessary because the cost of reaching out to the stakeholders for more requirements is too high.

In already existing system

It is preferred in the development of embedded software for already existing hardware. The software may not change in the future because the architecture is already fixed.

Advantages

Although the use of waterfall model has been made less useful by the use of the more recent methods, it has some advantages that make it a good option in some type of software development. These advantages are:

i. The requirement is clear before the development starts and changes not allowed

Because all the requirements are gathered before the start of the development, it is unlikely that core functionality will be omitted. Because no change is allowed during development, no time is wasted in incorporating new requirement.

ii. It is easy to understand and implement

The linearity and sequential nature of waterfall model makes it easy for the developers to know and implement the model.

iii. A minimal resource requirement

Due to the fact that one stage must finish before the next stage can commence, the same team that carried out one stage may be the same team to carry out next stages. By some doing, the human resources used in this model is minimal compared to models where the stages can overlap.

iv. Effective documentation of each stage

Since software is intangible, it needs to be made visible for effective management. This can be done by using models, diagrams and documents. The waterfall model relies on effective documentation to indicate the quality and progress of the development for effective management.

v. It makes it easy to measure progress

In this model, the output is generated after each stage (as seen before), therefore it has high visibility. The client and project manager gets a feel that there is considerable progress [7]. Here it is important to note that in any project psychological factors also play an important role.

Disadvantages

In literatures, a lot of research has been done on the problems associated with the waterfall model.

i. Lack of user involvement after requirement stage

In modern process models, especially agile model, users are involved throughout the software development life cycle to ensure that requirements are correctly interpreted. However, in waterfall mode, after the requirement stage, the users are not involved again and this leads to errors in the implementation of requirements.

ii. It is not flexible

This model is rigid and does not allow the client to modify the requirement after requirement stage. This makes it not suitable in areas to involve rapidly change software features.

iii. Time is wasted in preparing documents

The waterfall model is the model that requires so much documentation. A lot of time is wasted at each phase to document the each stage. This wasted of time would have been used to do the real work.

iv. Poor quality product

The waterfall model leads to poor quality software because iteration is not allowed. It should be noted that the problems that the developer could not solve during a given phase will not be solved again. This leads to poor quality since the error will never be solved.

v. It does not encourage improvement

In this model, software and hardware are frozen after development. This frozen software cannot be modified and therefore improvement is not allowed. But as technology changes at a rapid pace, such freezing is not advisable especially in long-term projects.

vi. It leads to blocking state

In the waterfall model, one stage must finish before the next state resumes. Due to this, a lot of time is wasted by the team to be involved in next stage waiting for the preceding stage to finish.

2.3. Prototyping model

Software prototyping is the process of creating incomplete versions of the software program being developed so that the client can evaluate it to ascertain if it satisfies his requirements. It simulates only few observable functions compare to the final product that will be produced [8]. Sometimes, prototype produced is used by users of the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions. This type of prototyping is called demo software. It is also used by users to describe and prove requirements that developers have not considered, and that can be a key factor in the commercial relationship between developers and their clients. A prototyping model is a software process model used when the client or user has little or no clue on the requirement of the software to be built.

2.3.1. Steps in prototyping

1. Requirements gathering

The developer will be required to get some basic information about the new system such as the objective of the system, the input and out information. It is to be noted that only functional requirement will be considered while most non-functional requirements will be ignored.

2. Quick design of the prototype

This involves the design of the aspects of the software that will be visible to the client. This aspect includes the user interface layout, output display format.

3. Construction of prototype

The quick design leads to the prototype construction. In the prototype, all the visible parts of the functionality are implemented.

4. Customer evaluation and feedback

The developed prototype is given to the users to evaluate to see if it meets the expected requirement of the client. The client will examine the prototype and then give feedback to the developer.

5. Prototype refinement

At this stage, the developer will use the feedback from the evaluation stage to modify the prototype to suit the customer.

6. Deployment

When the client approves a prototype, the developers will then develop the final product for the software.

2.3.2. Types of prototyping [10]

There are three types of prototyping model. These models are Throwaway Prototyping, Extreme prototyping and Evolutionary Prototyping.

2.3.2.1. Throwaway/Rapid prototyping

Throwaway prototyping is also called close-ended prototyping. It refers to the creation of a model that will eventually be discarded rather than being modified to produce the final delivered software. A simple working model of the system is constructed, after the initial requirements gathering is accomplished, to show the users what their requirements will look like when the final product is developed. It involves creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The most important factor in rapid prototyping is speed. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is discarded, and the system is formally developed based on the identified requirements. The Throwaway Prototyping is always used because it can be done quickly and also its ability to implement interfaces that the users can test.The user interface is what the user sees as the system and it tells him how the system will work.

2.3.2.2. Evolutionary prototyping

The Evolutionary Prototyping or breadboard prototyping is used to build a very robust prototype which can be constantly refined to get the final product. In Evolutionary Prototyping, developers focus on developing a system using functionalities they understand fully well instead of considering all the functionality. In order to minimize risk, the developer does not implement poorly understood features. The partially developed system is sent to the customer for evaluation. As users work with the system, they detect opportunities for new features and send requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration management practices to change the software requirements specification, update the design, recode and retest. Evolutionary Prototypes are a functional system which can be used for commercial purposes before the main product become ready.

2.3.3. Applications of prototyping model

Prototyping model is most beneficial in systems that will have many interactions with the users. This implies that the greater the interaction between the computer and the user, the greater the benefit of using the prototyping model. It should be noted that prototyping is not ideal for systems with little user interaction, such as batch processing or systems that mostly do calculations.

· It is always used in the analysis and design of on-line systems, for example transaction processing, where the use of screen dialogs is much more in evidence [8].

· The development of human-computer interfaces is the most important area where the prototyping model is most needed.

· Unfamiliar technology

When software on a new technology is to be developed, the best method is the prototyping model. This helps the client and the developer to understand the technology before the start of the main work.

Advantages of Prototype model:

· Users are actively involved in the development

Because the users are actively involved in the development of the software, the probability of the customer rejecting final product is low.

· The user understands the software better

Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

§ Errors can be detected much earlier

Since the users participate in the development, error can be detected at the early stage when the cost of correcting error minimal.

· Quicker user feedback

The participation by the user in the development provides quick feedback leading to better solutions.

Missing functionality can be identified easily

The user can identify any missing functionality very early during the evaluation stage.

Disadvantages of Prototype model:

§ Leads to implementing and then repairing way of building systems.

§ Practically, this methodology may increase the complexity of the system as the scope of the system may expand beyond original plans.

§ Incomplete application may cause the application not to be used as the

Full system was designed.

§ Incomplete or inadequate problem analysis.

2.3. Iterative and incremental model

The iterative and incremental model is any combination of both iterative model incremental model for software development [11]. It is a discipline for developing systems based on producing working software deliverables. In incremental development, different parts of the system are developed at various times or rates and are integrated based on their completion. This method is used for software with large development effort and short delivery time. The product is decomposed into a number of components, each of which is designed and built separately, and delivered to the client when it is complete. This allows partial utilization of the product and avoids a long development time. It also avoids a large initial capital outlay and subsequent long waiting period [12]. The basic idea behind this method is to develop a system through repeated cycles and in smaller portions at a time. This allows software developers to take advantage of what was learned during development of earlier parts or versions of the system. In this model, learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration stage, design modifications are made and new functional capabilities are added. The series of releases is referred to as increments, with each increment providing more functionality to the customers. After the first increment, a core product is delivered, which can already be used by the customer. Based on customer feedback, a plan is developed for the next increments, and modifications are made accordingly. This process continues, with increments being delivered until the complete product is delivered. .

2.3.1. Applications of iterative and incremental model

Project development is exposed to many constraints such as the time schedule, cost, human resources and quality. The use of iterative and incremental model is used to forestall the negative impacts of the above constraints. This model is applied under the following conditions:

· Project with tight delivery date schedule

When the delivery date is too short for the expected functionality to be delivered, the best model is this model. It allows the developers to deliver some core functionality that can be delivered within the time limit and deliver the remaining functionality later.

· When manpower is limited

When a developing firm encounters a loss of manpower while a project is in progress, the only option is to negotiate with the client for incremental delivery. This helps the contractor to meet up with the schedule.

· When only few requirements are well understood

When the requirement of a project is not well understood, this is the model used to deliver the understood requirement in the first increment and then include the rest in subsequent requirement.

· The cost of the project is too high

When the cost of carrying out a project is too high, it becomes necessary to use incremental and iterative model. This ensures that limited resources are used to implement some of the functionalities for business purpose before the resource becomes available for expansion.

Other projects where the model can be applied are shown in below:

§ When the requirements of the complete system are clearly defined and understood.

§ When major requirements are defined, but some details will evolve with time.

§ When there is a need to get a product to the market early.

§ When a new technology is being used

§ When resources and the needed skill set are not available

§ When there are some high risk features and goals.

Advantages

1. Faulty elements of the software can be quickly identified

After each iteration, regression testing is conducted. During this testing, faulty elements of the software can be quickly identified because few changes are made within any single iteration.

2. Generally easier to test and debug

It is generally easier to test and debug than other methods of software development because relatively smaller changes are made at each iteration stage. This allows for more targeted and rigorous testing of each element within the overall product lifecycle.

1. A functioning product is available at the end of every iteration

At the end of each iteration process, a working product is delivered. This is a measure of milestone in this model. Iterations may be run simultaneously. A design team starts the next iteration while the current one is under test,

1. Product requirements may be changed to optimize future iterations,

This model allows the change in the requirements. When the requirement is changed, it is reflected in the next increment.

1. Control of the progress and project risks

This model has the ability to control risks since any risk detected can be affected in the next increment without the need to call back the product

Disadvantages

1. Resulting cost may exceed the cost of the organization.

The overall cost of developing a full software through a series of increments is higher that the cost of developing one full software in one delivery.

1. Architectural problem due to additional functionality

When additional functionality is added to the product, problems may arise related to system architecture which was not evident in earlier prototypes. In a situation whereby no comprehensive planning and design is carried out, a change in the system functionality can lead to confusion.

1. Needs good planning and design.

Because of the need for a change in requirement, this model needs a very comprehensive planning and design to accommodate future changes in requirement. This elaborate planning and design makes the model too tasking.

Selection between evolutionary prototyping or iterative and incremental model

The evolutionary prototyping model and the iterative and incremental model are two models that give selection problem. The conditions for selecting one of the two models is shown in table 3.1.

2.4. Spiral life cycle model.

The Spiral Life Cycle Model is a type of iterative software development model which is generally used in high risk projects. The spiral model is intended for large, expensive and complicated projects [14]. It has the property of managing risk at regular stages in the development cycle. The first publication on spiral model was published by Barry Boehm in 1988. It combines some key aspect of the waterfall model and rapid prototyping (throwaway) methodologies, but added emphasis in a key area many felt had been neglected by other methodologies. This aspect includes deliberate iterative risk analysis, particularly for large-scale complex systems. In Spiral model, all the activities are arranged in the form of a spiral. The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representation of the following activities:

1. Formulate plans to:

Identify software targets, implement the program, and clarify the project development restrictions

1. Risk analysis:

An analytical assessment of selected programs, to consider how to identify and eliminate risk

1. Implementation of the project:

The implementation of software development and verification

Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. However, the spiral model has some restrictive conditions, as follows:

1. The spiral model emphasizes risk analysis, and thus customers have to accept this analysis and play their role. This requires the client to trust the developer as well as being willing to spend more to fix the issues. It is very important for the customer to cooperate since risk analysis is the reason why this model is often used for large-scale internal software development [15].
2. If the implementation of risk analysis, will greatly affect the profits of the project, the spiral model should not be used.
3. Software developers have to actively look for possible risks, and analyze it accurately for the spiral model to work.

The first stage in spiral model is to formulate a plan to achieve the objectives with these constraints, and then strive to find and remove all potential risks through careful analysis and, if necessary, by constructing a prototype. When some risks cannot be ruled out, the customer has to decide whether to terminate the project or to ignore the risks. When the project is finished, the results are evaluated and the design of the next phase begins.

2.4.1. Steps in spiral model development

The steps in the spiral model can be generalized as follows:

1. The new system requirements are defined in as much detail as possible.

This involves interviewing a number of users, stakeholders, domain experts and the clients involved in the project.

2. A preliminary design of the new system is created.

This involves designing the first blueprint of the system to be developed. This model may be discarded later.

3. A first prototype of the new system is constructed from the preliminary design.

This is usually a scaled-down system, and represents an approximation of the visible characteristics of the final product.

4. A second prototype is developed by taking the following four steps:

· Evaluating the first prototype in terms of its strengths, weaknesses, and risks;

· Defining the requirements of the second prototype;

· Planning and designing the second prototype;

· Constructing and testing the second prototype.

5. The entire project can be aborted if the risk is deemed too great, depending on the client’s decision. In software development a lot of risk factors are considered. These risk factors are:

· Development cost overruns,

· Operating-cost miscalculation

· Any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.

6. Evaluate the existing prototype

The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed.

7. Iterate until the customer is satisfied.

The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

8. The final system is constructed, based on the refined prototype.

9. The final system is thoroughly evaluated and tested.

10. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

2.4.2. Application

· The spiral model is mostly used in large and risky projects. For smaller projects, the concept of agile software development is becoming a viable alternative.

· It is used in the development of software that needs high reliability and safety. For that reason, the military had adopted the spiral model for its Future Combat Systems program.

· It is also reasonable to use the spiral model in projects where business goals are unstable, but the architecture must be realized well enough to provide high loading and stress ability.

· It is used in the information technology system development

Advantages of Spiral Model

· It is very flexible

The Spiral Life Cycle Model is one of the most flexible SDLC models in place. Development phases can be determined by the project manager, according to the complexity of the project.

· Project monitoring is very easy and effective.

Because each phase, as well as each loop, requires a review from concerned people, the model more transparent.

· It manages risk effectively

The risk management is one of the inbuilt features of the spiral model, which makes it extra attractive compared to other models. Because of the risk management ability of this model, it is used in a large and complex system where risk is unavoidable.

· Changes can be introduced later in the life cycle

The spiral model allows the introduction of changes at any stage of development with minimal cost change. Because of the nature of the model, coping with these changes is not a very big problem for the project manager.

· Time schedule and cost estimate with high accuracy

This model has the ability to estimate time schedule and cost with high accuracy. Project estimates such as time schedule and cost become more and more realistic as the project moves forward and loops in spiral get completed.

· A highly customized product can be developed using this.

Disadvantages of Spiral Model

· Cost involved in this model is usually high.

Because of the cost of complex risk analysis, the cost of developing software using the spiral model is always high compare to other models.

· It is very hard to learn and use

It is a complicated approach, especially for projects with a clear SRS.

· It needs so much expertise

Skills required in evaluating and reviewing project from time to time, need expertise. For that reason, organizations that use spiral model always lack manpower.

· It involves a lot of time wasting protocol

Rules and protocols should be followed properly to effectively implement this model. Doing so, throughout the span of a project is tough and wastes time.

· Due to various customization allowed from the client, using the same prototype in other projects, in the future, is difficult.

· It is not suitable for low risk projects.

· Meeting budgetary and scheduling requirements are tough if this development process is followed.

· Amount of documentation required in intermediate stages makes management of project very complex affair.

2.5. Rational Unified life cycle model.

The Rational Unified Process (RUP) is an object-oriented and Web-enabled program development model [16]. It is used for developing object oriented programs. It establishes four phases of development, each of which is organized into a number of separate iterations. The RUP is not a single concrete prescriptive process, but rather an adaptation process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget [17]. The Rational Unified Process is a software process product, originally developed by Rational Software, which was acquired by IBM in February 2003. The product includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RM C) product which allows customization of the process [18]. The IBM Rational Unified Process® (RUP®) is a comprehensive process framework that provides industry-tested practices for software and systems delivery and implementation and for effective project management [19]. The flow diagram of Rational Unified Process is shown in Fig.2.5 [20]. It is one of many processes contained within the Rational Process Library, which offers best practice guidance suited to your particular development or project need.

2.5.1.Six Best Rational Unified model Practices [19]

Six Best Principles are involved in the Rational Unified Process paradigm in software engineering. These six ideas are followed when designing any software project to minimize faults and increase productivity. These practices are:

· Develop iteratively

It is best to know all requirements in advance; however, often this is not the case. Several software development processes exist that deal with providing solutions on how to minimize cost of changes in terms of development phases.

· Manage requirements

Developers should know that requirements set by users. For that reason, the user can change the requirement at any time. Therefore, it is necessary to manage the requirement so that changes will not lead to confusion.

· Use components

Breaking down an advanced project is a very important principle that must be followed strictly. This makes it possible for individual components to be tested before they are integrated into a larger system. It also encourages code reuse in object-oriented programming.

· Model visually

Use diagrams to represent all major components, users, and their interaction. Unified Modeling language is one tool that can be used to make this task more feasible.

· Verify quality

Testing should be made a major part of the project at any point of time. Testing should become as the more rigorous as the project progresses, but should be a constant factor in any software product created.

· Control changes

Since most projects are created by many teams, sometimes in various locations and different platforms may be used, it is essential to make sure that changes made to a system are synchronized and verified constantly.

These best practices have made it possible for the developers to improve the quality and predictability of their software development efforts. The use of this model reduces the waste of resources due to unexpected development costs since it is well structured [18].

Discussion of the activities of each phase

The RUP establishes four phases of development, each of which is organized into a number of separate iterations that must satisfy defined criteria before the next phase is undertaken. In the inception phase, developers define the scope of the project and its business case. Meanwhile, in the elaboration phase, developers analyze the project's needs in greater detail and define its architectural foundation. The elaborate stage leads to the construction phase, developers create the application design and source code; and in the transition phase, developers deliver the system to users. RUP provides a prototype at the completion of each iteration stage. This brief explanation can be shown in table 2.3.

Table 2.6. The support disciplines.

Table 2.7. The enterprise management disciplines.

The new enterprise management disciplines come at a cost. The attempts at implementing management should be applied judiciously and with minimal interruption to your current business functions. It is important to understand that although some overlap exists between the enterprise management discipline activities and existing RUP activities, the scope is different.

2.6.2. The EUP Best Practices

Develop iteratively.

Developing in iterations allows projects to address risks on a priority basis. It allows for a constant measure of progress, as iterations have a fixed timeslot and a specific goal to be met. After each iteration, stakeholders provide a view of the progress of the project and can therefore set realistic expectations for the remainder of the project based on the actual progress of working code.

Manage requirements.

A key to delivering a system that meets the stakeholders' needs is identified and then managing the requirements for the system. This includes gathering, documenting, and maintaining of requirements, incorporating changes in a systematic manner, and potentially even tracking and tracing the requirements to the design. The requirements management process can be very well defined and prescriptive, often involving significant effort and expense, but with the benefit of producing accurate and detailed documentation of the decisions.

Use proven architecture.

Because not all the architecture is component-based, the enterprise unified model pays attention to proven architecture instead of using component-based. For example, web services are another architectural option, as are procedural languages such as COBOL, and you can easily extend the RUP to work with these technologies. The true best practice is to identify and then prove through prototyping an architecture that is appropriate for the system that you are building.

Use modeling.

Modeling helps people envision and think through concepts and then share those ideas with others. Modeling can be done with high-powered, GUI-based software applications or can simply be sketches on whiteboards. The writing a use case as simply writing documentation, which really shows how people will interact with your system is non-virtual modeling.

Continuously verify quality.

Testing happens in every iteration of a RUP project instead of a single, large testing effort at the end. Ensuring quality goes beyond testing software to ensure it meets the requirements - reviews of requirements, design, and mock-ups with stakeholders are also part of continuous quality verification. Testing for and catching defects early is much more efficient than a comprehensive approach to testing at the end. An effective way to ensure quality is an implementation technique called test-driven development (TDD), which is based on the idea that developers should write a test before they write new business code to ensure that they always have a 100% regression unit test suite for their system.

Manage changes.

Change is a must in any software development. Change must be expected and handled appropriately for a project to run smoothly and to take advantage of changes that may give them a competitive advantage. A wide range of artifacts such as documents, models, plans, tests, code, and so on - will potentially be affected by any changes.

Collaborative development.

Systems are built by teams of people, and if these people do not work together effectively, the overall project risks are failing. The agile software development community has done significant work in identifying and promoting collaborative development techniques. Primary techniques include pair programming, where two people work together to develop code; modeling with others, which promotes the concept that several people are more effective modeling together than they are working separately; and active stakeholder participation, which promotes the concept that project stakeholders should provide information and make decisions in a timely manner and be involved with the development effort itself.

Look beyond development.

Not only do you need to build and deploy a system into production, but you also need to operate and support it after it is deployed. Good developers know this and understand that they need to work with operations and support professionals to ensure that their needs are met. Furthermore, good developers also realize that their system must fit into the overall organization, the implication being that they need to ensure that their system reflects common enterprise norms - their systems will take advantage of the existing architecture and infrastructure and will follow accepted enterprise guidance.

Deliver working software on a regular basis.

The primary measure of success for a software development project should be the delivery of working software that meets the needs of its users. Effective developers deliver working software on an incremental basis, delivering the highest priority functionality remaining at each iteration stage of the development.

Manage risk.

Effective project teams strive to identify and then manage the risks that they face, either mitigating them completely or reducing their potential impact as appropriate.

Advantages of the enterprise unified model [24]

There are numerous benefits that the Enterprise Unified Process (EUP). In addition to the benefits associated with adopting iterative processes such as the Rational Unified Process (RUP), the EUP also offers the opportunity for:

Reduces software development costs.

Implementing a strategic approach to reuse components for the enterprise can significantly reduce your cost of developing software. Just having an enterprise view of architecture will lead to fewer ‘stovepipe’ applications, which are costly to develop and maintain.

Improved software/business alignment.

By improving enterprise business modeling efforts, understanding of the overall business will improve and thereby increase the chances that the systems will be built to reflect their true needs. With a portfolio/program management approach to choosing projects, projects will be prioritized and then executed based on business needs, thereby improving alignment with the business.

Higher quality

Reusing software can lead to higher quality, as reusing an already tested component can lead to fewer defects. Leveraging enterprise architectural solutions that have been tested and proved to work ensure that applications built upon those architectures will improve in quality.

Greater adaptability

By having an effective approach to enterprise software issues, changes will be easily managed within the marketplace, such as new legislation or new competition more effectively.

Reducing time to deliver the systems

An improved enterprise-level software process will reduce the overall time to deliver systems for several reasons. First, an improved portfolio management approach enables the developer to identify projects which are more likely to succeed, reducing the change of late and/or cancelled projects. Second, an effective enterprise architecture strategy enables work to be done on a common platform, reducing the learning curve of project teams. Third, improved reuse increases your development velocity by enabling you to take advantage of existing assents instead of creating systems from scratch each time.

Increased end user productivity

By integrating operations and support into software Life-cycle enhances the end users usage of the system and to respond to their feedback. End user requests for fixes and enhancements are automatically included in the requirements for new releases of systems and ensure that their needs are incorporated.

Increased developer activity

With an effective approach to enterprise administration, developers can gain the technical resources that they need, such as workstations and network logon IDs easily. This enables them to focus on their jobs, developing working software, and not on trying to get access to resources.

Disadvantaged of the enterprise unified model[25]

· It is weakly structured;

· It mixes requirements with different levels of detail or abstraction;

· It does not attach rationales to requirements;

· It does not offer a big picture of what UEML is about;

· It seems to address requirements that are beyond the “reasonable” scope of a UEML;

· It contains requirements that are not sufficiently clear or too complex and need further refinement.

2.7. Agile life cycle model

The agile development methods evolved from the old and well-known iterative and incremental life cycle approaches. The development of agile modeling was led by Scott, Amber in 2000. It initially was called extreme modeling but at the suggestion of Robert Cecil Martin, was renamed agile model in 2001. Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing teams [26]. Agile model is a practice-based methodology for developing software systems. It is a collection of values, principles and practices in software engineering and it compares more flexible to the traditional software development model. It promotes adaptive planning, evolutionary development and delivery and encourages rapid and flexible response to change [26]. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. Agile methods to break tasks into small increments with minimal planning and do not directly involve long-term planning. Agile Modeling enables developers to develop customized software that actually meets their current customer needs and is flexible enough to adjust to accommodate changes in the future. In agile, less time is invested for documenting requirements.

Agile development is based on these principles:

· Building working software that people can get hands on quickly.

· Forming cross-functional teams empowered to make decisions.

· Rapid iteration, with continuous customer input along the way.

· Customer satisfaction with rapid delivery of useful software

· Welcome changing requirements, even late in development

· Working software is delivered frequently (weeks rather than months)

· Working software is the principal measure of progress

· Sustainable development, able to maintain a constant pace

· Close, daily cooperation between business people and developers

· Face-to-face conversation is the best form of communication (co-location)

· Projects are built around motivated individuals, who should be trusted

· Continuous attention to technical excellence and good design

· Simplicity—the art of maximizing the amount of work not done—is essential

· Self-organizing teams

· Regular adaptation to changing circumstances

The agile model has many versions, thus:

· Extreme programming

· Scrum

The most popular agile method is Scrum. Scrum is an agile development method, which concentrates particularly on how to manage tasks within a team-based development environment. It is the most popular and widely adopted agile method because it is relatively simple to implement and addresses many of the management issues that have negatively affected IT development teams for decades. On the other hand, Extreme programming is a more radical agile methodology, focusing more on the software engineering process and addressing the analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product [27].

The agile model is so important in software development because it encourages customer participation. The customers are involved in the development team to ensure that there is no confusion during the requirement analysis and designing. It also encourages the participation of the development team in the management of the project. In this case the development team gives free hand to plan the development and schedule.

The agile model has not documented intensive since the measure of progress is the delivery of a working software increment unlike the traditional model which uses document as a milestone. In agile model, only document needed is just documenting sufficient enough to support the situation at hand. The process flow for agile model is shown in Fig.2.7.

Best practices of agile modeling

There are several modeling-oriented best practices. The summary of these best practices is shown in Fig.2.8. These best practices are as follows [28]:

Active stakeholder participation

Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques.

Architecture envisioning

At the beginning of an agile project, the team will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution.

Iteration modeling

At the beginning of each iteration stage, a bit of modeling will be done as part of iteration planning activities.

Just barely good enough (JBGE) artifacts

A model or document needs to be sufficient for the situation at hand and no more. Unlike waterfall model, document is limited.

Look ahead modeling

Sometimes, requirements of higher priority are fairly complex, motivating the developer to invest some effort to explore them so as to reduce overall risk.

Model storming

Throughout iteration it will be necessary to model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue.

Multiple models

Each type of model has its strengths and weaknesses. An effective developer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand.

Prioritize requirements.

Agile teams implement requirements in priority order, as defined by their stakeholders, so as to provide the greatest return on investment (ROI) possible.

Requirements envisioning

At the beginning of an agile project you will need to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements.

Test-driven development (TDD)

Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.

Disadvantages of agile model

· Demands to much man power

The agile model needs a lot of manpower to carry out software development. At times, two persons per development tool are required for effective software development. A situation where two persons are needed per development tool is called pair programming.

· Hindered when team members lack accurate communication

Because the agile model needs informal and formal communication between the team members for effective operation, its aim is defeated when the members fail to communicate very well with one another.

Other disadvantages

· In case of some software deliverable, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

· There is a lack of emphasis on necessary designing and documentation.

· The project can easily get taken off track if the customer representative is not clear what the final outcome that they want.

· Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

Advantages of agile model

· It flattens the cost of change

This implies that the change in the requirement at the late stage does not adversely affect the cost of change. This is because, the software is delivered incrementally and therefore a change in the requirement will be reflected in the next increment and therefore has no effect on the cost of the present incremental.

· The agile model accommodates changes in requirements

Since the agile model is used to develop software for the present need, any change in requirement is accommodated in the next increment.

· It is not affected by the employ turnover

Since it applies pair programming, when a developer leaves the team, the second person who is already versatile with the process will then replace the outgoing member.

· It makes manpower training very easy

The use of pair programming acts as a training opportunity for new team members. By staying with old member, the new member will learn the work very easily.

Other advantages of agile

· Customer satisfaction by rapid, continuous delivery of useful software.

· People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.

· Working software is delivered frequently (weeks rather than months).

· Face-to-face conversation is the best form of communication.

· Close daily cooperation between business people and developers.

· Continuous attention to technical excellence and good design.

· Regular adaptation to changing circumstances.

· Even late changes in requirements are welcomed

Applications

· It is used for time critical applications.

When the delivery deadline is too tight, an agile model is recommended since it encourages incremental delivery of the software.

· It is used for projects with high possibility of requirement changes

The freedom agile gives to change is very important. New changes can be implemented at very little cost because of the frequency of new increments that are produced.

· It is used for software that will operate on many differing platforms