Need for doing a legal audit to detect all 3rd party instances

A lot of people do not even know about this concept ? What is a Legal Audit (or a similar name that may be followed by different software organizations). However, most project / program managers would know about using components from many different sources. And you would also have heard about patent disputes, where companies challenge each other about the software that they have written, and whether one of them was entitled to damages from the other for using a certain code over which the other claimed ownership (actually a patent is about the principle or concept or a specific feature, but you get the general idea).
How does this fit into the idea of something called a Legal Audit ? Patience.
Let me take a real life principle. In our team during the course of a product development cycle, the team is informed at the beginning of the cycle that they will not use any component from outside without speaking to their manager. However, during the middle of the cycle, I was speaking to the team about this (as a repeat) and later one of the team members approached me. It turned out that he was looking for an efficient XML parser and searched for an external component that would help him in this; he found something on the internet, downloaded and used it. Seems fine, after all, a lot of people might do this.
The problem was, we are living in a world where we need to respect the rights and copyrights of others, if we want others to respect our software. Our software has a global market of $40 million, and nobody would welcome a case against us for unlawful usage of an external component. It could be that we were fine with using this component, but nobody had done that kind of check. We looked at the component, and found that it had a license that was never going to be allowed for usage. The license wanted $1 for every customer usage of the software where this component was going to be installed, and if you think that we were ready to pay out tens of thousands of dollars for using such a component, I have nothing to say.
The Legal Audit is a way to do a scan of the software code to ensure that all the external components that are being used in the software are known, and the licenses are all approved towards this end. For product development where the product has been going through multiple versions, a lot of the components would have been in regular use over the years, and these can be quickly discounted. Most organizations would have a way to do this process in a way that minimizes the effort required.
Doing this process is essential, and in most cases, would require consultation with some software engineer or manager as well as with a legal expert (to sign off the final license agreements and to certify that the overall set of licenses used in the software are fine from the perspective of the organization).
And the Legal Audit can only be complete when the writing of new software is complete, since only then can it be sure that there is no further new code going to be written.

What is a CBSE process? What are the steps in CBSE?

The component based software engineering or CBSE process is nowadays gaining a new high in the field of software engineering. But still many of us are not aware of this development process. 

This article focuses up on the component based software engineering process as well as the steps involved in it. More commonly the component based software engineering process is known as “CBD” or component based development. 

About Component Based Software Engineering (CBSE) Process

- The CBSE process is treated as an individual branch of the software engineering that primarily emphasis up on the separation of concerns with respect to the wide ranging functionality that are present throughout a software system or application.

- This approach to software development can be thought of as a reuse based approach and is used for defining, implementing and composing the independent components that are loosely coupled in to the given software system or application. 

- With such a practice, an equally wide ranging degree of benefits is brought about in the software system both for the short term and the long term and also for the organizations that are involved with the production of that software system or application. 

- The components of the software system are considered to be a part of the platform where the development process begins by many of the software engineers. 

- The components are often converted in to services and are granted further characteristics that make it different from an ordinary component. 

- For example, this happens in SOA or service oriented architectures. 

- In other cases, the components are used to consume or produce events that cab be later used for EDA or events driven architecture. 

- An individual software component can be considered to be one of the following things:

1. Software package
2. Web service
3. Module encapsulating a set of related functions.

Principle behind CBSE Process

- All the processes of the software system or application are placed in to separate components so that the data remains safe and intact and separated from other dissimilar kinds of data. 

- There is a semantic relation between the data and the functions placed inside the components.

- It is this principle that grants the components the property of modular cohesiveness. 

- The co- ordination among components is facilitated via the interfaces of the components or modules.

- Whenever it is the turn of a software system or component to offer a service to the whole of the other system or application, it makes use of the provided interface specifying the service that can be utilized by the other components and how it is to be utilized is also instructed by that interface only. 

- This interface can be called as the signature of that particular component to which it belongs.

- One of the best things about the CBSE process is that the client need not have the knowledge about the inner working of the components in order to make use of it.

Steps involved in CBSE process

1. The first step is all about the creation of an interface specification using an IDL (interface definition language).

2. The second step deals with the creation of a component specification which consists of member functions and interfaces.

3. At this step the complete control of the development process is in the hands of the developers and the traceability metrics are based up on the CBSE principles.

4. Unit testing of the components using a test harness for making the entire process automated.

5. Component integration testing

With the CBSE process, the developers can make changes to a specific component easily as long as they adhere to their interfaces. 

What is the architecture of SilkTest ?

When you test an application GUI, Gui objects are manipulated such as windows, menus, buttons etc. using mouse clicks and keyboard. SilkTest interprets these objects and recognizes them based on its class properties and methods that uniquely identify them. SilkTest simulates the operations done by the user (mouse clicks and keyboard entries) and verifies the expected results automatically.
SilkTest has two components that execute as separate processes:
- Host Software
- Agent Software
The machine on which the host software component runs is called the host machine. Host software is the component that is used to develop test plans and test scripts. Test scripts can be created, edited, compiled, run the scripts and then debug them.
The agent software is the component that interacts with the GUI of your application. The agent software drives and monitors the Application Under Test (AUT). It translates the commands in the 4Test script into the GUI specific commands. The AUT and the agent software have to run on the same machine. Each GUI object has a unique match to the 4Test object.
SilkTest testing process involves four steps:
- Creating a test plan.
- Recording a test frame.
- Creating test cases.
- Running test cases and interpreting these results.

Component Based Development (CBD)

Component-based development is a CBSE activity that occurs in parallel with domain engineering. Using analysis and architectural design methods discussed earlier, the software team refines an architectural style that is appropriate for the analysis model created for the application to be built. Once the architecture has been established, it must be populated by components that are available from reuse libraries and/or are engineered to meet custom needs.

For those requirements that are addressed with available components, the following software engineering activities must be done:
- Component qualification : It examines reusable components. These are identified by characteristics in their interfaces, i.e. the services provided, and the means by which consumers access these services. This does not always provide the whole picture of whether a component will fit the requirements and the architectural style. This is a process of discovery by the software Engineer. This ensures a candidate component will perform the function required, and whether it is compatible or adaptable to the architectural style of the system. The three important characteristics looked at are performance, reliability and usability.

- Component adaptation : It is required because very rarely will components integrate immediately with the system. Depending on the component type, different strategies are used for adaptation or wrapping. The most common approaches are:
* White box wrapping : The implementation of the component is directly modified in order to resolve any incompatibilities. This is, obviously, only possible if the source code is available for a component, which is extremely unlikely in the case of COTS.
* Grey box wrapping : This relies on the component library providing a component extension language or API that enables conflicts to be removed or masked.
* Black box wrapping : This is the most common case, where access to source code is not available, and the only way the component can be adapted is by pre/post processing at the interface level.
It is the job of the software engineer to determine whether the effort required to wrap a component adequately is justified, or whether it would be “cheaper” to engineer a custom component which removes these conflicts.

- Component composition : The component composition is a task assembles qualified, adapted, and engineered components to populate the architecture established for an application. To accomplish this, an infrastructure must be established to bind the components into an operational system. The infrastructure provides a model for the coordination with one another and performs common tasks. Among the many mechanisms for creating an effective infrastructure is a set of four “architectural ingredients” that should be present to achieve component composition.
* Data exchange model: Mechanism that enables users and applications to interact and transfer data. The data exchange mechanisms not only allow human-to-software and component-to-component data transfer but also transfer among system resources.
* Automation: A variety of tools, macros, and scripts should be implemented to facilitate interaction between reusable components.
* Structured storage: Heterogeneous data contained in a “compound document” should be organized and accessed as a single data structure, rather than a collection of separate files.
* Underlying object model: The object model ensures that components developed in different programming languages that reside on different platforms can be interoperable.

- Component update : When systems are implemented with COTS components, update is complicated by the imposition of a third party. The organization that developed the reusable component may be outside the immediate control of the software engineering organization.

Software Components

Components are the software units that are context independent, both in the conceptual and the technical domain. A component contain a self-contained entity that exports functionality to its environment and also imports functionality from its environment using well defined and open interfaces. Components may support their integration into the surrounding by providing mechanics such as configuration functionality.

Software components can also be characterized based on their use in the CBSE process. In addition to COTS components, the CBSE process yields :
- Qualified components: Assessed by software engineers to ensure that not only functionality, but also performance, reliability, usability, and other quality factors conform to the requirements of the system/product to be built.
- Adapted components: Adapted to modify (wrapping) unwanted or undesired characteristics.
- Assembled components: integrated into an architectural style and interconnected with an appropriate component infrastructure that allows the components to be coordinated and managed effectively.
- Updated components: replacing existing software as new versions of components become available.

Software Component :
A software component simply cannot be differentiated from other software elements by the programming language used to implement the component. The difference lies in how software components are used.

Component model :
A component model defines specific interaction and composition standards. A component model implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model. The standards have to contain a set of elements or services which are shown in the following alignment :
- Interfaces: Specification of component behavior and properties; definition of Interface Description Languages (IDL).
- Naming: Global unique names for interfaces and components.
- Meta data: Information about components, interfaces, and their relationships; APIs to services providing such information.
- Interoperability: Communication and data exchange among components from different vendors, implemented in different languages.
- Customization: Interfaces for customizing components.
- Composition: Interfaces and rules for combining components to create larger structures and for substituting and adding components to existing structures.
- Evolution Support: Rules and services for replacing components or interfaces with newer versions.
- Packing and Deployment: Packing implementation and resources needed for installing and configuring a component.

Reuse of Components :
The main purpose of software components is software reuse. The main types of software reuse are white-box reuse and black-box reuse. White-box reuse means that the source of a software component is fully available. Black-box reuse is based on the principle of information hiding. Software components are reused in general through black-box reuse. Components hide the inner working as much as possible.