Evaluating Eclipse Software Engine Basis Information Technology Essay

Published: November 30, 2015 Words: 5340

This work describes the criteria of software engineering process that is used to evaluate Java Eclipse as a software engineering tool. It is divided into three sections. The first section introduces the concept of software engineering, its methods and processes, followed by the description of the unified process which provides the set of criteria for evaluation of Java Eclipse. Furthermore section one also describes any other requirements which are associated with software engineering tools. The second section evaluates Java Eclipse on the set of criteria described in first section. A brief case study is also included to discuss features of Eclipse. The third section concludes the work with summary.

"Software Engineering is an engineering discipline that is concerned with the aspects of software production from the early stages of system specification to maintaining the system after it has gone into use" (Sommerville 2004). Furthermore the discipline of software engineering helps in solving real time complex problems that are associated with many software systems (Liu 2003). There are many definitions associated with the term software engineering, however a broad definition of software engineering comes from the IEEE, which describe it as "Software engineering is "(1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software," and "(2) the study of approaches as in (1).""(IEEE Standard 610.12).

1.2 Software Engineering Process

As described by Sommerville , "Software engineering process is the set of activities and associated results that produce a software product" (Sommerville 2004). It is an approach for the development of software. The process offers a framework for development of a particular software system. Development of different software systems may involve use of different software engineering processes. Although there are many activities that would be associated with software engineering process but there are some fundamental activities that are incorporated in the development of any software system which are listed below:

Requirement gathering

Software Specification phase

Software Architecture phase

Software Implementation phase

Testing phase

Documentation phase

Maintenance phase

Different processes are used for development of different systems for e.g. the process used for the development of a real time software system is different from what is used for interactive system (Sommerville 2004; Pressman 2000).

1.3 Software Engineering Methods

Software engineering methods describe the way in which software system is actually developed. These methods help in delivering software of high quality standard with low development cost. Software engineering methods have been developed and are used for different category of systems. Among these methods the Object Oriented (OO) methodology is best suited for development of interactive systems (Sommerville 2004).

Non Commercial versus Commercial

Unified Process

The unified process is a popular iterative and incremental process framework for developing software systems. The four phases are inception, elaboration, construction and transition. All these phases may be further divided into a number of iterations and the end product of each such iteration is an increment. This framework can be customized according to the standards required by different organisations and projects (Roff, 2003; Booch et al., 1999).

Figure 1: pictorial description of activities in a Unified Process (Wikipedia, 2006).

1. Inception Phase

This involves gathering requirements for the software system to be developed. It is the shortest phase in the development (Roff, 2003; Booch et al., 1999; Sommerville 2004).

2. Elaboration Phase

In the elaboration phase, the system is designed. In the early iterations of the elaboration phase, the risks factors are discovered and the system architecture is established and validated. In the later stages, a plan is created for which is delivered to the construction phase (Kendall, 2002; Sommerville 2004).

3. Construction Phase

In the construction phase the system is developed using the requirements and designs from the previous phases. The system is built on the deliverables of the elaboration phase. This is the largest phase in development process of a system (Sommerville 2004; Kendall 2002).

4. Transition Phase

This is the final phase in the development of a software system. The early deliverables of this system are used to add refinements and variations. The software system developed is deployed in this phase (Sommerville 2004).

Rational Unified Process

The rational unified process provides a framework for software development. It is customizable and the developers can customize it as per requirements of the system that need to be developed. It is a copyright of Rational Software and now IBM. This process is a hybrid process model as it brings together the elements of all the generic models. It supports iteration and is based on incremental development. Rational Unified process enables the users to select only those elements that are required for the development of the project. Furthermore, rational unified process doesn't only act as a developing process it also helps the organisation to develop the product, keeping the business context in focus (Sommerville 2004; Kruchten 2001). The set of principles and practices rational unified process is based on are stated as follows:

Develop Software Iteratively

Manage requirements

Use component-based architecture

Visually model software

Verify software quality

The rational unified process is based on four phases which are somewhat similar to those of the unified process but there are a few differences that mark the difference (Sommerville 2004; Kruchten 2001).These phases can be briefly described as follows:

Inception

The difference in this phase is that a business case is established besides gathering requirements. This business case includes business context, financial forecast and success factors for the software system to be developed (Sommerville, 2004; Kruchten 2001).

Elaboration

During this phase main focus is on analysis of the problem domain, establishing of framework for the system, development of project plan and to find the key risks involved (Sommerville, 2004; Kruchten 2001).

Construction

This phase is split into three parts i.e. designing, programming and testing. The system is constructed on the basis of principles from previous phases. The end result of this phase is the running software that actually is ready to be sent out to the customers (Sommerville, 2004; Kruchten 2001).

Transition

In this phase the developed system is delivered to the customers and is run in the real environment. It's the final stage and the delivered product is fully documented and ready to use (Sommerville, 2004; Kruchten 2001).

1.4 Computer Aided Software Engineering (CASE)

Computer aided software engineering is a software that helps in development of software systems. CASE supports all software process activities such as requirements engineering, system designing, programming and testing. Importantly it is an established fact that CASE helps in increasing the productivity and quality of the developed software system. CASE technology provides support by automating certain software development activities and also provides information regarding software that is being developed. These tools include editors, debuggers, compliers, data dictionaries etc. There are various activities that can be automated by using CASE technology (Sommerville 2004; Case, 1985; Premkumar and Potter, 1995). Some of these activities can be listed as follows:

Development of graphical system models.

Analysis of design by understanding the entities and relations.

Generation of user interfaces.

Debugging of programs.

Translation of programs from old versions to recent versions i.e. forward and reverse engineering (Sommerville 2004).

A Case for CASE

Now-a-days CASE tools are available for almost all routine activities involved in software development process which has led to the increase in productivity of quality software systems. Besides this CASE tools have helped in bringing down the cost of development of various software systems. CASE tools provide standardization of work practices in the process of software development (Sommervile, 2004). Some of the features of CASE tools are listed as follows:

CASE tools increase the speed of development by providing automation of many tasks.

These tools provide debugging and error checking options for better accuracy.

CASE tools support documentation at various development stages.

These tools provide full support for novice users to develop programs.

These tools reduce the maintenance costs (Sommerville, 2004; Lee).

Although CASE tools have so many advantages still there are a few limitations associated with them. These limitations can be described as follows:

Software engineering activities are considered to be team activities where there is a lot of interaction between team members. This feature is not supported by CASE tools (Sommerville 2004).

Research has shown that there is an increase in the cost of software and learning curve which has made organisations reluctant in adopting CASE tools (Premkumar and Potter 1995).

These limitations are subdued by benefits offered by CASE tools. CASE technology is quite mature now and there are many vendors which make CASE tools available in the market. CASE tools are used in organisations for different activities involved in software development process (Sommerville, 2004).

Tools in Market

According to Sommerville these tools can be classified on the basis of the following:

Functionality: In this, CASE tools are classified according to the functions they perform.

Process: Under this category the CASE tools are grouped on the basis of process activities that are supported by them.

Integration: Under this, the CASE tools are combined on the basis of how they are organized into integrated units for the support of software development activities (Sommerville, 2004).

According to Sommerville, a functional classification of CASE tools can be represented in a tabular format as follows:

Tool Type

Examples

Planning tools

PERT tools, estimation tools, spreadsheets

Editing tools

Text editors, diagram editors, word processors

Change Management tools

Requirements traceability tools, change control systems

Configuration Management tools

Version management systems, system building tools

Prototyping tools

Very high-level languages, user interface generators

Method support tools

Design editors, data dictionaries, code generators

Language-processing tools

Compliers, interpreters

Program analysis tools

Cross reference generators, static analyzers, dynamic analyzers

Testing tools

Test data generators, file comparators

Debugging tools

Interactive debugging systems

Documentation tools

Page layout programs, image editors

Reengineering tools

Cross-reference systems, program restructuring systems.

Figure 2: Functional classification of CASE tools (Sommerville 2004).

Some of the well known tools which are used by organisations can be grouped into tabular form as:

Company

Tools

Description

Oracle

Oracle Designer/2000

Designing Tool

Oracle Developer/2000

Development Tool

Oracle Reports

Documentation & Report generation

OTW Software, Inc.

Object Technology Workbench

Object Oriented Analysis and design, UML

Rational Software Corporation

Rational Rose

OOAD ; Booch Method

SoDA

Documentation generator

TestMate

Testing

ClearCase

Configuration Management

TNI

STOOD

OOD , HOOD4 Method ; Ada, C, C++, Code generation

Yourdon, Inc.

Analyst/Designer

Front-End

StructSoft, Inc.

TurboCASE

Structured analysis and design ; Object Oriented

Figure 3: Tools in Market (Vendor v 2.76, 2005)

1.5 Software Engineering (The unified process)

1.5.1 Requirement Engineering and Design UML

Requirements are the specifications and constraints that describe what the system should do for the customer or user. According to Sommerville "The requirements reflect the needs of customer for a system that helps solve some problems such as controlling a device placing an order or finding information" (Sommerville, 2004). Requirement engineering is the process of gathering, analyzing, documenting and verifying the requirements and constraints (Sommerville 2004). These requirements are modeled using different approaches. One of the widely used approaches to model the system is by using UML. The system is modeled in UML by using different modeling techniques (Roff 2003). These techniques can be briefly described as:

Domain Modeling

Domain modeling is used to model the domain within which an enterprise conducts its business. It specifies the application domain of the system describing the working domain of the product. It is used to model the domain requirements of a system (Sommerville, 2004; Oldfield 2002).

Use case Modeling

Use case model is used for gathering the functional requirements of the software system to be developed. This is done by using use case diagrams. Use case is a technique for capturing functional requirements of system. They describe various scenarios which imply how the system should interact with the users (Goodland and Slater YEAR; Roff, 2003; Booch et al., 1999; Ochimizu). In simpler words as described by Roff, "A use case simply describes the actions that users take on a system" (Roff, 2003). Use cases are simple to understand as they avoid the technical jargon and use simple language (Kendal, 2002).

Class modeling

In a class diagram the classes, their relationships, attributes and operations are described. Class diagrams describe the system in detail thus making it easier to design the system according to required standards. Moreover class diagrams describe the functionality and attributes associated with parts that make the software system (Roff, 2003).

Interaction Methods

The interaction methods describe the interactions between the objects and the system. These methods are described by two diagrams i.e.

Sequence diagram

A sequence diagram describes the various interactions between different objects in a system. Sequence diagrams concentrate more on actors and objects that are part of the system (Roff,2003). According to Chitnis et al., "A Sequence diagram depicts the sequence of actions that occur in a system" (Chitnis et al., 2002). These diagrams represent then dynamic behavior of the system.

Collaboration diagram

These diagrams are used in analysis of the system design and are used to model objects or roles and the communication that takes place between them. According to Roff, "Collaboration diagrams are used to model the interactions between the objects and roles, indicating the navigation that is allowed and available across each" (Roff , 2003). These help in the description of the system design that has been analyzed in previous phase.

State diagrams

A state diagram describes the changes in states of an object in a system. In designing a system, the state diagrams can be used to depict the changes in screens when the user inputs or invokes some sort of action on a particular screen (Roff, 2003 ; Chitnis et al., 2002).

Activity diagrams

These diagrams are used to describe the behavior of the system. Furthermore activity diagrams are used to model business workflows and represent complicated business activities (Roff 2003).

Physical diagrams

These diagrams are used to show the physical components of a system (Roff, 2003). Two types of physical diagrams are discussed below:

Component Diagrams

These diagrams are used to model the relation between various components of a system which are grouped according to location or functionality. They describe the functionality based on the version of the software package (Roff 2003).

Deployment Diagrams

These diagrams describe which software is installed on which piece of hardware and how those pieces of hardware interact with each other (Roff 2003).

1.5.2 Implementation

Implementation is the process of converting design from the previous phases into an executable system. This involves the generation of code for making the system work according to the requirements and designs obtained after the system is modeled (Sommerville 2004).

Editing

It is the process of writing or editing code/programs using a tool called editors. Editors are very helpful in writing efficient code. The editors are of different types. Some editors provide visual as well as textual editing and code writing. Some of them help by providing the programmer the ease of writing code syntax by automatic code generation.

Language Processing tools

Compilers

These language processing tools read a program or a unit of program written in one language and convert it into a program in another language. Many software tools have the capability of translating pieces of code or programs written in a high level language into machine or object code (Sommerville, 2004; Pressman, 2000).

Interpreters

Interpreters are programs that execute other unit of programs. These tools are incorporated in many software engineering tools (Sommerville, 2004; Pressman, 2000).

Debuggers

Debuggers allow the programmer to correct the syntax as well as logic of the written piece of code. Debuggers are programs that remove the bugs i.e. bad pieces of code, from the program (Sommerville, 2004; Pressman, 2000).

Testing

Testing is the process of validating and verifying the developed software on the basis of the requirements of the user. There are many sorts of tests that can be performed on the software that is developed. However the tests can be categorized into two fundamental types i.e. component testing and system testing. There are many tools that perform different tests on software. Besides doing the tests, these tools support test documents and reports (Sommerville 2004; Pressman, 2000).

Packaging & Deployment

Deploying applications, updates, and patches is one of the most common functions of every enterprise IT department. But if these software packages are not properly prepared for deployment, you risk bad packages crashing critical applications, driving up IT support costs, and angering end users. Deployment involves at least two different aspects: packaging the code, and distributing the packages to the various clients and servers on which the application will run. A primary goal of any Software Engineering tool is to simplify deployment, especially the distribution aspect, by making zero-impact (No registry entries are made on the machine) install and XCOPY deployment feasible. The self-describing nature of assemblies should remove the dependency on the registry, thereby making install, uninstall, and replication much simpler (Sommerville, 2004; Pressman, 2000);

1.5.3 System Documentation

In the process of software development, documentation takes place at all stages. Documentation is a very important feature of software development as it helps in describing details about every phase which helps in better understanding of software system. Software tools help in documenting different kind of reports associated with system development (Pressman 2000).

1.5.4 Maintenance/Re-Engineering

Once the software system is deployed it has to be checked from time to time to check for its proper working (Pressman 2000). According to Sommerville "Software maintenance is the general process of changing a system after it has been delivered" (Sommerville, 2004). Maintenance of a software system can be due to the listed three reasons:

For repairing faults in software

For changing operating environment of the software for e.g. operating system, changes in hardware etc.

For any addition or modification in systems functionality (Sommerville, 2004).

There are many software tools that help in maintenance of the software.

Re-engineering is a process of re-implementing software engineering techniques on an existing system for making it more maintainable. Although this technique is usually used for legacy system but it can be used for other software systems as well (Sommerville 2004). It consists of forward and reverse engineering.

Forward Engineering

It is also called code generation. CASE tools automate generation of code (Baxter and Mehlich, 1997).

Reverse Engineering

This is one important feature a software tool can support. In this technique the system is analyzed and all information is extracted which helps in documenting functionality and organzation of software (Sommerville 2004).

1.6 Additional Requirements

1.6.1 Collaborative working

Collaborative working implies to different people working to achieve a common goal. There are four basic categories of collaborative software which are listed below:

Electronic communication tools such as email, voice mail etc.

Electronic conferencing tools such as video conferencing, data conferencing.

Application sharing.

Collaborative management tools such as project management systems, workflow systems, online spreadsheets etc.

These tools help in making the process of collaborative working easy and efficient. There are various software tools that help in development of collaborative software (Zara, 2004).

1.6.2 Configuration Management

According to Sommerville, 'Configuration Management is the development and use of standards and procedures for managing an evolving software system' (Sommerville, 2004). Tools for configuration management support the storage of versions of system components, build systems from these components and track release of these versions in the market (Sommerville,2004).

Version Management

This involves the process of identification and tracking of versions of software. Furthermore tools for version management ensure that different versions of software can be retrieved as and when they are required (Sommerville, 2004).

Change Management

This involves analyzing the changes that are required for the system to perform with more efficiency and maintainability. Tools for change management ensure that changes that are required are well calculated in terms of risk and cost (Sommerville, 2004).

1.6.3 User Interface

User interface of a system allows interaction between the system and the user thus it is a very important feature as far as software development is concerned. There are many tools that allow easy development of interfaces by using the properties of 'What you see is what you get' (WYSWYG). Most modern tools such as VS.NET, Visual Studio 2005 and Eclipse etc. automate the process of interface development (Sommerville, 2004; Pressman 2000).

1.6.4 Prototyping

Prototype is an initial version of software system that is developed for acquiring more information regarding the design and working of the system. Prototypes can be used in few stages of software development for e.g. in requirements phase, in system design phase and in testing phase (Sommerville, 2004).

1.6.5 Help

Documentation and help are features that suffice the user to understand the working of software. Software tools generally provide help manuals and tutorials which enable the user to better understand the features of the tool and hence decreases the cost and time of learning (Sommerville 2004; Pressman 2000).

1.6.6 Cross platform

Software is supposed to be cross platform if it functions on more than one operating systems or computer architecture. This feature is supported by various tools used for software development for e.g. the code written using a tool can be moved across with much ease onto a different platform (Pressman 2000).

1.6.7 Portability According to Jim Mooney, 'An application is portable across a class of environments to the degree that the effort required to transport and adapt it to a new environment in the class is less than the effort of redevelopment' (Mooney, 2001). Some CASE tools that support the activities involved with portability of software units. Software tools support portability in all the processes of software development (Mooney, 2001).

1.6.8 Application Upgrade

Software applications are upgraded whenever a new feature is added or a new requirement is added in the current application. Tools support upgrades. Many new features are added to software tools. However the tool should have a normal upgrade frequency as it would not be very customer friendly if there are many upgrades in very short time duration (Pressman, 2000).

1.6.9 Backward Compatibility

Software is said to be backward compatible if it interoperates with the set of applications that used to function with its older product. Backward compatibility is a good process as it reduces the re-implementation or regeneration of a product. Software development tools should have the feature of backward compatibility as many organisations upgrade these with new features (Pressman 2000; Whatis, 2005).

1.6.10 Automation

There are various software development activities that can be automated. This allows high efficiency and productivity of software. Software tools support automation of processes involved in software development (Sommerville, 2004).

1.6.11 Performance

Software tools support all activities in the process of software development. This enhances the performance of these processes and increases the quality of the product (Sommerville, 2004).

1.6.12 Cost

Every software system has a cost of development, risk and mitigation. Software tools reduce the cost involved with development of software system. There are many cost effective software tools that are used for different processes in software development (Pressman, 2000; NIST, 2006).

2.0 Review of Eclipse as SET based on Concepts described

Eclipse is an open source, platform independent software framework for developing applications. Eclipse provides a universal platform for integrating different development tools. Eclipse provides a support for all the processes of software development, i.e. eclipse software framework supports building of an open development platform consisting of extensible frameworks and tools which support activities across the software developing life cycle (Eclipse.org ; Cernosek, 2005 ).

Eclipse is used in many organisations, educational institutions, research centers etc. Eclipse was introduced into the market by IBM as successor to its Visual age but now it comes from the Eclipse foundation (Eclipse.org; Cernosek , 2005).

One of the key benefits that eclipse provides is the support of all development tasks of software development by providing a single platform. Eclipse supports an environment for plug-in software. Eclipse comprises of three elements (Software AG, 2006; Rivieres, 2001).

These are listed as:

Workbench

Workspace

Platform Runtime

In addition to these, eclipse has plug-in features which extend its functionality (Rivieres, 2001).

The diagram shows the platform architecture of eclipse.

Figure 4: Eclipse Platform Architecture (Rivieres, 2001).

The workbench is the interface for the user to work with. Workspace provides the feature of storage such as files and folders i.e. creating and managing project resources. Platform runtime is the kernel which ensures that the components and plug-ins are loaded correctly (Rivieres, 2001).

According to Rivieres some of the areas of its functionality are:

Enterprise development

Embedded and device development

Rich Client Platform

Language IDE (Rivieres, 2001).

2.1 Extendibility - Plug-ins

Plug-ins are small units of eclipse platform function. These small units are developed separately and then added to the eclipse environment. Plug-ins provide an extension to the basic functionality of eclipse. There are some plug-ins that extend the functionality of other plug-ins. There are many development activities that are not embedded in basic functionality of eclipse development tool. These are covered by plug-ins available for eclipse (Rivieres, 2001). Some categories for which these plug-ins offer support are:

Application Management

Code Management

Deployment

IDE

J2ME

Training & Services

Modeling

Testing

Documentation

Editing

UML

Configuration Management

Rich Client Applications

Profiling (Eclipse Plugin Central).

2.2 Evaluation

Eclipse can be evaluated on the set of criteria defined above. The grid below represents the evaluation of this tool.

Principles

Grade (0-5)

Category

Built-in

Plug-in

Use Case Modeling

5

Inception Phase

Class Modeling

5

Inception Phase

UML diagrams

3

Inception Phase

Editing Facility

5

Construction Phase

Compiling Facility

5

Construction Phase

Debugging Facility

5

Construction Phase

System Documentation

3

All phases

Forward Engineering

5

Construction Phase

Easy to use interface

5

All phases

Cross platform compatibility

4

Design, Construction phase

Portability

5

Design, Construction phase

Ease of use

5

All phases

Tutorial Support

4

All phases

Cost

4

All phases

Reverse Engineering

4

IDE

4

Code Analysis

4

Construction Phase

Testing

4

Construction Phase

User Interface

5

Design Phase

Adherence to standards

3

All phases

Language integration features

4

Construction Phase

Figure 5: Eclipse Grid Analysis

Legend

Principle

Set of activities involved in software development

Grade

0 to 5 (0 - weak , 5 - strong)

Category

Phase in which the Principle is incorporated

Built-in

Tick if Principle is supported as a built-in feature

Plug-in

Tick if Principle is supported as a plug-in feature

The Usecase modeling technique is assigned grade 5. Although eclipse does not have its own usecase modeling tool but the most of the plug-ins such as eUML2, ArgoEclipse etc that are supported by Eclipse for usecase modeling are free of cost, are easy to use and support all activities like Usecase Diagramming and Documentation (Eclipse Plugin Central, 2006).

There are not many plug-ins that support all the UML diagrams. Moreover out of the 10 plug-ins that support all diagrams some tools such as Borland Together Edition, MagicDraw UML involve cost of purchase (Eclipse Plugin Central, 2006). Hence the grade allocated to UML diagrams is 3.

Similarly the grade assigned for Editing, Compiling, Debugging, Forward Engineering and Easy to use interface is 5.

The reason for this grade is that Eclipse provides good editing, compiling and debugging facilities with a stable environment for code generation and a user friendly interface (Eclipse.org, 2006).

System Documentation is assigned grade 3. This is due to the fact that Eclipse does not provide very strong system documentation facility as when compared to other products available in the market. Although its still grade 3 as it is a built-in feature and hence is free of cost as compared to other software tools (Eclipse.org, 2006).

Tutorial support, cross platform compatibility and cost are assigned a grade of 4. These are built-in features. Although Eclipse provides state of the art examples but these are not enough to describe the functionality of the tool.

Reverse Engineering, IDE, Code analysis and Testing are assigned a grade 4 due to the reason that these features are supported by not many plug-ins and also many plug-ins for these involve little cost (Eclipse Plugin Central, 2006).

As a result of these grades Eclipse gets an overall score of 91. This score shows that eclipse is a powerful tool and can be used in almost all stages in development life cycle. The built-in features may not support various activities though there are various plug-ins that support all activities with easy of use and full support thus enhancing tool's ability.

2.3 Future Changes - Eclipse Process Framework Project (EPF)

Eclipse Process Framework Project also called 'Beacon' is proposed for developing an open source process framework. Eclipse process framework project comprises of three goals. First aims at building up of standard process tools and language which would enable various users to collaborate and exchange best software practices. The second goal involves building of open source content for promotion of iterative and agile development methods. This would serve as sample content for foundation of various processes. The last goal is to make framework easy to use and adopt (Kroll, 2005).

Eclipse Process Framework is thought to benefit following categories:

Individual Projects

Enterprise or line-of-businesses

Academia

Vendors, technology companies, and companies

System integrators (Kroll, 2005).

2.4 Case Study

The case study, in appendix A, is about the use of Eclipse by NASA's Jet Propulsion Laboratory Maestro Team, for the Mars Exploration Rover Mission. The case study hails Eclipse as a feature-rich development environment that allows developers to efficiently create tools that integrate seamlessly across various platforms (Eclipse, 2006).

It also offers comparison with previously used tools. It talks about Eclipse open source as mature and comparable to software developed in-house or commercial products because of its quality and stability. Eclipse RCP Update manager is mentioned as a highly desired feature in keeping the application up to date. Ability to publish changes to their clients in a way that doesn't require the end user to manually download anything ended the forced software updates. Eclipse is serving as a framework for a project called Ensemble which is something of a consortium for multiple operations tools that are being developed within the organisation. The Maestro Team has presented Eclipse RCP and the Eclipse development environment to the community of operations tools developers within NASA with the idea that they will make it easier to transfer code between teams and connect programs developed in different groups. The different teams working within the Eclipse framework still have their areas of expertise. However instead of operating as more of an independent entity, there are now certain application functions the groups are no longer keeping to themselves. These components are offered in an effort to take advantage of the huge body of code that's developed within NASA, built as plug-ins to the Eclipse framework, that the participating groups are now open-sourcing within NASA. Thereby not only precipitating competition but also not reinventing the wheel (Eclipse, 2006).

The idea that taking advantage of collective intelligence is a better approach to software development than building programs in isolation benefits NASA in the same way it does the Eclipse community and hence the open source model has worked very well for NASA (Eclipse, 2006).

3.0 Summary

Fulfilling the evaluation criteria as illustrated by the grading grid and NASA case study, Eclipse comes forth as a software development tool that greatly aids the designing, developing, documenting and verification of software systems. Tools like Eclipse can be looked upon as futuristic approach that can take isolated pieces of java software and seamlessly integrate the computing, networking, and user environment under which they are running, thereby influencing a change is work culture and software design approach as seen is the NASA case study. However it is a fact that no single review can ever capture every potential problem with critical software of this complexity, especially when it must be run under a wide range of operational environments. Hence what remains to be seen is how the Eclipse developer community helps in the evolution of Eclipse Project Framework, as the software development tool is enhanced and the environment under which it runs is evolving.