Spring 2012 Master of Computer Application (MCA) – Semester V MC0084 – SPM & QA– 4 Credits (Book ID: B 0958) Assignment Set – 2

Book ID: B 0958 1. Describe the following: o Project Communication

o Project Development Phases

Answer:

Project Communication

There are many reasons that software projects get into trouble. The scale of many development efforts is large, leading to complexity, confusion, and significant difficulties in coordinating team members. Uncertainty is common, resulting in a continuing stream of changes that ratchets the project team. Interoperability has become a key characteristic of many systems. New software must communicate with existing software and conform to predefined constraints imposed by the system or product. To deal with them effectively, a software engineering team must establish effective methods for coordinating the people who do the work. To accomplish this, mechanisms for formal and informal communication among team members and between multiple teams must be established. Formal communication is accomplished through “writing”, structured meetings, and other relatively non-interactive and impersonal communication channels. Informal communication is more personal. Members of a software team share ideas on an ad hoc basis, ask for help as problems arise, and interact with one another on a daily basis. Formal, impersonal approaches include software engineering documents and deliverables (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data. Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections. Informal, interpersonal procedures include group meetings for information dissemination and problem solving and collocation of requirements and development staff. Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video based conferencing systems. Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.

Project Development Phase

Regardless of the methodology used, the project development process will have the same major stages: Initiation, Planning and design, project implementation and closing/maintenance. Initiation The initiation stage determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’s needs. The key project control needed here is an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them.The initiation stage should include a cohesive plan that encompasses the following areas: Study analyzing the business needs in measurable goals.

Review of the current operations.

Conceptual design of the operation of the final product.

Equipment requirement.

Financial analysis of the costs and benefits including the budget.

Select stake holders, including users, and support personnel for the project.

Project charter including costs, tasks, deliverables, and schedule.

This phase can also be called initiation phase, where in people have to identify the following, Information to be processed.

Functions required.

Performance required.

System behavior should be determined

No. of interfaces required should be estimated. This may be difficult to do. But tentatively allowed.

Some times project can be dropped during at this phase. Planning and Design After the initiation stage, the system is designed. Occasionally, a small prototype of the final product is built and tested. Testing is generally performed by a combination of testers and end users, and can occur after the prototype is built or concurrently. Controls should be in place that ensures that the final product will meet the specifications of the project charter. The results of the design stage should include a product design that: Satisfies the project sponsor, end user, and business requirements.

Functions as it was intended.

Can be produced within quality standards.

Can be produced within time and budget constraints. During this phase the following issues are addressed, How design should be converted into code?

Testing strategy should be planned

Strategy for module integration.

Architectural issues are evaluated

Interfaces are characterized etc.

Project Implementation Against the project plan and project organization structure defined in the previous stage, the project activities are executed, tracked and measured. The project implementation stage not only includes the completion of planned activities, but also the evaluation of the success, contribution of this effort, continual review and reflection of project status and outstanding issues against the original project business case. The implementation is basically concerned with the development of code and deploying the code. There should be synchronization between the code and design. Tools are available to synchronize both code and design. (Ex: UML – Visual Paradigm, Rational Rose etc). Once implementation is over, proper testing is required. Testing can be unit testing, performance testing, load testing, integration testing and system testing. Closing and Maintenance One of the key success criteria for continuous process improvement involves defining a formal process for ending a project. This includes evaluating the successful aspects of the project as well as identifying opportunities for improvement, identification of project "best practices" that can be leveraged in future projects, and evaluating the performance of project team members. Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. Maintenance is an ongoing process, and it includes:

Continuing support of end users

Correction of errors

Upgradation of software and hardware etc.

Documentation preparation (user manuals).

2. Describe the Development Life cycle models with respect to Project Planning.

Answer:

Development Life cycle models History The "waterfall model", documented in 1970 by Royce was the first publicly documented life cycle model. The model was developed to help cope with the increasing complexity of aerospace products. The waterfall model followed a documentation driven paradigm. The next revolutionary new look at the development lifecycle was the "spiral model", presented by Boehm in 1985. The spiral model is focused on risk management. Life cycle models describe the interrelationships between software development phases. The common life cycle models are: Spiral model

Waterfall model

Throwaway prototyping model

Evolutionary prototyping model

Incremental/iterative development

Automated software synthesis Because the life cycle steps are described in very general terms, the models are adaptable and their implementation details will vary among different organizations. The spiral model is the most general. Most life cycle models can in fact be derived as special instances of the spiral model. Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities. A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. Typically, a life cycle model addresses the following phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance. Much of the motivation behind utilizing a life cycle model is to provide structure to avoid the problems of the "undisciplined hacker".Spiral Model The spiral model is the most generic of the models. Most life cycle models can be derived as special cases of the spiral model. The spiral uses a risk management approach to software development. Some advantages of the spiral model are: Defers elaboration of low risk software elements

Incorporates prototyping as a risk reduction strategy

Gives an early focus to reusable software

Accommodates life-cycle evolution, growth, and requirement changes

Incorporates software quality objectives into the product

Focus on early error detection and design flaws

Sets completion criteria for each project activity to answer the question: "How much is enough?"

Uses identical approaches for development and maintenance

Can be used for hardware-software system development Waterfall Model This is the least flexible and most obsolete of the life cycle models. Well suited to projects that have low risk in the areas of user interface and performance requirements, but high risk in budget and schedule predictability and control. This waterfall model is the base model for all the other models. This model involves the following phases, Analysis or Requirements

Design

Implementation

Testing or verification

Maintenance

The waterfall model is one time model. It is not evolutionary model.Description for waterfall model To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes "requirements

specification" – they set in store the requirements of the software. When the requirements are fully completed, one proceeds to design. The software in question is designed and a "blueprint" is drawn for implementers (coders) to follow – this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs.Thus the waterfall model maintains that one should move to a new phase only when the preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them. Throw-away Prototyping Model This model is useful in "proof of concept" or situations where requirements and user's needs are unclear or poorly specified. The approach is to construct a quick and dirty partial implementation of the system during or before the requirements phase. Evolutionary Prototyping Model Used in projects that have low risk in such areas as losing budget, schedule predictability and control, large-system integration problems, or coping with information sclerosis, but high risk in user interface design. Incremental / Iterative Development An incremental development is an evolutionary model. This approach consists of step wise development, in which parts of some stages are postponed in order to produce some useful set of functions earlier in the development of the project. Increments may be delivered to the customer as they are developed. The development begins with the analysis of an increment at the requirements level. Each increment is then separately designed, coded, tested, integrated and delivered. In other words, the waterfall model is still followed, but for each separate increment. When the incremental model is used, the first increment is often a core product i.e., basic requirements are addressed, but many supplementary features remain undelivered. The core product is used by the customer. As a result of use or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer. The incremental model is shown in the following diagram.

3. Describe the following with respect to Software Quality Assurance: o Standards and Procedures

o Software Quality Assurance Activities Answer:

Standards and Procedures Establishing standards and procedures for software development is critical, since these provide the framework from which the software evolves. Standards are the established criteria to which the software products are compared. Procedures are the established criteria to which the development and control processes are compared. Standards and procedures establish the prescribed methods for developing software; the SQA role is to ensure their existence and adequacy. Proper documentation of standards and procedures is necessary since the SQA activities of process monitoring, product evaluation and auditing rely upon unequivocal definitions to measure project compliance.

Software Standards: Software standards are needed to achieve acceptable levels of quality in both software products and processes. Standards may be imposed externally or internally. In the first case, the software organization itself decides to adopt standards in order to achieve certain expected benefits. In the later case, the standards may be mandated to contractors by the customer. Popular standards organizations include, ISO (international standards for organization. o ISO-9001 is the standard refers to software.

o ISO-9003 is guide lines for software industry. IEEE ( Institute of Electrical and Electronics Engineers)

The main benefit of standard is that they enforce a uniform behavior within an organization.Types of standards Documentation Standards specify form and content for planning, control, and product documentation and provide consistency throughout a project. Design Standards specify the form and content of the design product. They provide rules and methods for translating the software requirements into the software design and for representing it in the design documentation. Code Standards specify the language in which the code is to be written and define any restrictions on use of language features. They define legal language structures, style conventions, rules for data structures and interfaces, and internal code documentation. Procedures are explicit steps to be followed in carrying out a process. All processes should have documented procedures. Examples of processes for which procedures are needed are configuration management, non-conformance reporting and corrective action, testing, and formal inspectionsStandards are to be documented according to the Standards and Guidelines in the Product Specification. The planning activities required to assure that both products and processes comply with designated standards and procedures are described in the QA portion of the Management Plan.

Software Quality Assurance Activities

Product evaluation and process monitoring are the SQA activities that assure the software development and control processes described in the project's Management Plan are correctly carried out and that the project's procedures and standards are followed. Products are monitored for conformance to standards and processes are monitored for conformance to procedures. Audits are a key technique used to perform product evaluation and process monitoring. Review of the Management Plan should ensure that appropriate SQA approval points are built into these processes. Product evaluation is an SQA activity that assures that standards are being followed. Ideally, the first product monitored by SQA should be the project's standards and procedures. SQA assures that clear and achievable standards exist and then evaluates compliance of the software product to the established standards. Product evaluation assures that the software product reflects the requirements of the applicable standard(s) as identified in the Management Plan. Process monitoring is an SQA activity that ensures that appropriate steps to carry out the process are being followed. SQA monitors processes by comparing the actual steps carried out with those in the documented procedures. The Assurance section of the Management Plan specifies the methods to be used by the SQA process monitoring activity. A fundamental SQA technique is the audit, which looks at a process and/or a product in depth, comparing them to established procedures and standards. Audits are used to review management, technical, andassurance processes to provide an indication of the quality and status of the software product. The purpose of an SQA audit is to assure that proper control procedures are being followed,

that required documentation is maintained, and that the developer's status reports accurately reflect the status of the activity. The SQA product is an audit report to management, consisting of findings and recommendations to bring the development into conformance with standards and/or procedures.

Book ID: B 0959 1. Describe the following: o System Testing

o Integration Testing Answer:System Testing

System testing of software is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. As a rule, system testing takes, as its input, all of the "integrated" software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole. 3.4.1 Recovery testing In software testing, recovery testing is the activity of testing how well the software is able to recover from crashes, hardware failures and other similar problems. Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed.Examples of recovery testing: 1) While the application is running, suddenly restart the computer and after that check the validness of application's data integrity; 2) While application receives data from the network, unplug and then in some time plug-in the cable, and analyze the application ability to continue receiving of data from that point, when network connection disappeared; 3) To restart the system while the browser will have definite number of sessions and after rebooting, check that it is able to recover all of them. 3.4.2 Security Testing Any computer-based system that manages sensitive information or causes actions that can improperly harm (or benefit) individuals is a target for improper or illegal penetration. Penetration spans a broad range of activities: hackers who attempt to penetrate systems for sport; disgruntled employees who attempt to penetrate for revenge; dishonest individuals who attempt to penetrate for illicit personal gain. Security testing attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration. To quote Beizer [BEI84]: "The system's security must, of course, be tested for invulnerability from frontal attack – but must also be tested for invulnerability from flank or rear attack." During security testing, the tester plays the role(s) of the individual who desires to penetrate the system. Anything goes! The tester may attempt to acquire passwords through external clerical means; may attack the system with custom software designed to breakdown any defenses that have been constructed; may overwhelm the system, thereby denying service to others; may purposely cause system errors, hoping to penetrate during recovery; may browse through insecure data, hoping to find the key to system entry. Given enough time and resources, good security testing will ultimately penetrate during system recovery. The role of the system designer is to make penetration cost more than the value of the information that will be obtained.

3.4.3 Stress Testing Stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Stress testing may have a more specific meaning in certain industries. In software testing, stress testing often refers to tests that put a greater emphasis on robustness, availability and error handling under a heavy load, than on what would be considered correct behavior under normal circumstances. In particular, the goals of such tests may be to ensure the software doesn't crash in conditions of insufficient computational resources (such as memory or disk space), unusually high concurrency or denial of service attacks. Examples: A web server may be stress tested using scripts, bots, and various denials of service tools to observe the performance of a web site during peak loads

Integration Testing Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together.

Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once. Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis. The purpose of integration testing is to verify functional, performance and reliability requirements placed on major design items. These "design items", i.e. assemblages (or groups of units), are exercised through their interfaces using black box testing, success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and inter-process communication is tested and individual subsystems are exercised through their input interface. Test cases (Inputs, Output and conditions for each functionality) are constructed to test that all components within assemblages interact correctly, for example across procedure calls or process activations, and this is done after testing individual modules, i.e. unit testing.The overall idea is a "building block" approach, in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages. Common integration types are, Big Bang

Bottom-up

Top-Down 3.2.1 Big Bang: In this approach, all or most of the developed modules are coupled together to form a complete software systems or major part of the system and then used for integration testing. The Big Bang method is very effective for saving time in the integration testing process. However, if the test

cases and their results are not recorded properly, the entire integration process will be more complicated and may prevent the testing team from achieving the goal of integration testing. 3.2.2 Bottom Up: All the bottom or low level modules, procedures or functions are integrated and then tested. After the integration testing of lower level integrated modules, the next level of modules will be formed and can be used for integration testing. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage. It is also stated in a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a "seed" model, whereby the beginnings are small, but eventually grow in complexity and completeness. However, "organic strategies", may result in a tangle of elements and subsystems, developed in isolation, and subject to local optimization as opposed to meeting a global purpose.

3.2.3 Top-Down: In a top-down approach an overview of the system is first formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of "black boxes" that make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model.

2. Explain the following Software Quality Assurance Standards: o ISO Standards

o SEI – Capability Maturity Model

o Comparison between ISO and SEI CMM Answer:

ISO Standards

ISO 9000 is a set of quality management standards, recognized worldwide, developed and controlled by the International Organization for Standardization (ISO) in Geneva, Switzerland. The documents that define the ISO 9000 standard, adopted by more than 100 countries, provide a quality management system philosophy and guidance, as well as specifications to which the quality system must adhere. This means that Avocent has established a systematic approach to quality management, and is managing its business to ensure that your needs are clearly understood, agreed and fulfilled. ISO 9001 (to which Avocent is certified) is the most stringent of the ISO 9000 standards. ISO 9001 requires that a company meet a set of requirements aimed primarily at achieving quality and customer satisfaction at all program stages from design through servicing. Avocent established a quality policy requiring support and

"buy-in" from all staff levels. Our employees ensure that we continue to meet our quality objectives.

CMM (Capability Maturity Model) CMM (Capability Maturity Model) is a model of process maturity for software development – an evolutionary model of the progress of a company’s abilities to develop software. In November 1986, the American Software Engineering Institute (SEI) in cooperation with Mitre Corporation created the Capability Maturity Model for Software. Development of this model was necessary so that the U.S. federal government could objectively evaluate software providers and their abilities to manage large projects. Many companies had been completing their projects with significant overruns in schedule and budget. The development and application of CMM helps to solve this problem. The key concept of the standard is organizational maturity. A mature organization has clearly defined procedures for software development and project management. These procedures are adjusted and perfected as required. In any software development company there are standards for processes of development, testing, and software application; and rules for appearance of final program code, components, interfaces, etc.

1. Initial level is a basis for comparison with the next levels. In an organization at the initial level, conditions are not stable for the development of quality software. The results of any project depend totally on the manager’s personal approach and the programmers’ experience, meaning the success of a particular project can be repeated only if the same managers and programmers are assigned to the next project. In addition, if managers or programmers leave the company, the quality of produced software will sharply decrease. In many cases, the development process comes down to writing code with minimal testing.

2. Repeatable level: At this level, project management technologies have been introduced in a company. That project planning and management is based on accumulated experience and there are standards for produced software (these standards are documented) and there is a special quality management group. At critical times, the process tends to roll back to the initial level.

3. Defined level: Here, standards for the processes of software development and maintenance are introduced and documented (including project management). During the introduction of standards, a transition to more effective technologies occurs. There is a special quality management department for building and maintaining these standards. A program of constant, advanced training of staff is required for achievement of this level. Starting with this level, the degree of organizational dependence on the qualities of particular developer decreases and the process does not tend to roll back to the previous level in critical situations.

4. Managed level: There are quantitative indices (for both software and process as a whole) established in the organization. Better project management is achieved due to the decrease of digression in different project indices. However, sensible variations in process efficiency may be different from random variations (noise), especially in mastered areas.

5. Optimizing level: Improvement procedures are carried out not only for existing processes, but also for evaluation of the efficiency of newly introduced innovative technologies. The main goal of an organization on this level is permanent improvement of existing processes. This should anticipate possible errors and defects and decrease the costs of software development, by creating reusable components for example.

Comparison between ISO and SEI CMM

Contrasting ISO 9001 and the CMM Clearly there is a strong correlation between ISO 9001 and the CMM, although some issues in ISO 9001 are not covered in the CMM, and some issues in the CMM are not addressed in ISO 9001. The levels of detail differ significantly: chapter 4 in ISO 9001 is about five pages long; sections 5, 6, and 7 in ISO 9000-3 comprise about 11 pages; and the CMM is over 500pages long. There is some judgment involved in deciding the exact correspondence, given the different levels of abstraction. The clauses in ISO 9001 with no strong relationships to the CMM key process areas, and which are not well addressed in the CMM, are purchaser-supplied product and handling, storage, packaging and delivery. The clause in ISO 9001 that is addressed in the CMM in a completely distributed fashion is servicing. The clauses in ISO 9001 for which the exact relationship to the CMM is subject to significant debate are corrective action and statistical techniques. The biggest difference, however, between these two documents is the emphasis of the CMM on continuous process improvement. ISO 9001 addresses the minimum criteria for an acceptable quality system. It should also be noted that the CMM focuses strictly on software, while ISO 9001 has a much broader scope: hardware, software, processed materials, and services [Marquardt91]. The biggest similarity is that for both the CMM and ISO 9001, the bottom line is “Say what you do; do what you say.” The fundamental premise of ISO 9001 is that every important process should be documented and every deliverable should have its quality checked through a quality control activity. ISO 9001 requires documentation that contains instructions or guidance on what should be done or how it should be done. The CMM shares this emphasis on processes that are documented and practiced as documented. Phrases such as conducted “according to a documented procedure” and following “a written organizational policy” characterize the key process areas in the CMM. The CMM also emphasizes the need to record information for later use in the process and for improvement of the process. This is equivalent to the quality records of ISO 9001 that document whether or not the requiredquality is achieved and whether or not the quality system operates effectively. This statement is controversial in itself. Some members of the international standards community maintain that if you read ISO 9001 with insight (between the lines so to speak), it does address continuous process improvement. There is faith that weaknesses will improve over time, especially given regular surveillance audits. Corrective action can be interpreted in this way, although that may not be consistently done today. This will undoubtedly be one of the major topics for the next revision cycle for ISO 9001.

3. Explain the following with respect to CASE tools: o Integrated CASE environments

o CASE repository

Answer:

Integrated CASE Environments

An I-CASE environment is a collection of CASE tools and other components together with an integration approach that supports most or all of the interactions that occur among the environment components, and between the users of the environment and the environment itself.

The critical part of this definition is that the interactions among environment components are supported within the environment. What distinguishes a CASE environment from a random amalgamation of CASE tools is that there is some thing that is provided in the environment that facilitates interaction of those tools. This `something' may be a physical mechanism such as a shared database or a message broadcast system, a conceptual notion such as a shared philosophy on tool architectures or common semantics about the objects the tools manipulate, or some combination of these things. The integrated CASE (I-CASE) include (1) smooth transfer of information (models, programs, documents, data) from one tool to another and one software engineering step to the next; (2) a reduction in the effort required to perform umbrella activities such as software configuration management, quality assurance, and document production; (3) an increase in project control. That is achieved through better planning, monitoring and communication; and (4) Improved coordination among staff members who

are working on large software Project. But I-CASE also poses significant challenges. Integration demands consistent representations of software engineering information, standardized interfaces between tools, a homogeneous mechanism for communication between the software engineer and each tool and an effective approach that will enable I-CASE to move among various hardware platforms and operating systems. Comprehensive I-CASE environments have emerged more slowly than originally expected. However, integrated environments do exist and are becoming more powerful as the years pass. The term integration implies both combination and closure. I-CASE combines a variety of different tools and a spectrum of information in a way that enables closure of communication among tools, between people and across the software process. Tools are integrated so that software engineering information is available to each tool that needs it; usage is integrated so that a common look and feel is provided for all tools; a development philosophy is integrated, implying a standardized software engineering approach that applies modern practice and proven methods. To define integration in the context of the software engineering process, it is necessary to establish a set of requirements [FOR89a] for I-CASE: An integrated CASE environment should provide the following, Provide a mechanism for sharing software engineering information among all tools contained in the environment.

Enable a change to one item of information to be tracked to other related information items.

Provide version control and overall configuration management for all software engineering information.

Allow direct, non-sequential access to any tool contained in the environment.

Establish automated support for the software process model that has been chosen, integrating CASE tools and software configuration items (SCIs) into a standard work breakdown structure.

Enable the users of each tool to experience a consistent look and feel at the human/computer interface.

Support communication among software engineers.

Collect both management and technical metrics that can be used to improve the process and the product. The range of possible ways of providing the `glue' that links CASE tools together inevitably leads to a spectrum of approaches to implementing a CASE environment. One of the main points we make in this book is that there are many ways to build a CASE environment. While many people concentrate on the selection of CASE tools and components when assembling a CASE environment, they largely ignore the need to support the interactions among those components. We concentrate less on which components should be chosen, and much more on how the selected components can be made to work together effectively. Whether a chosen approach to component interaction is appropriate in a given context will depend on many overlapping factors: the needs of the organization in question, the available resources, and so forth. A detailed assessment of these related factors and constraints is necessary to determine the CASE environment most suited to the problem at hand.

CASE repository

The repository is a "thing" – a database that acts as the center for both accumulation and storage of software engineering information. The role of the person (the software engineer) is to interact with the repository using CASE tools that are integrated with it. The repository is a relational or object-oriented database that is "the center of accumulation and storage” for software engineering