Working with external teams to ensure that they fit your requirements into their schedule

I work in an organization that is fairly large, being a $500 million organization, having a number of products being worked upon by different product teams. As a part of this process, there are also many common components that are made by a few central teams, which provide functionality common to most of the products. For example, when you consider that functionality such as reading and writing to optical media, being able to open and write to video files, etc are common functionality, it makes a lot of logical sense to ensure that these functionality are done by a common team and then other teams pick it up. It is not such a open and dried system though, there are elements of complexity in these systems though:
- The various product teams that pick up these common components or code have different schedules, while the common component teams follow a set schedule (in most cases, this schedule is set primarily by the most important product team - for example, if you take the case of Microsoft, the MS Office or the Windows team will have a much higher priority than somebody working on Skype, and the schedule for a common component will be more geared towards the schedule of Office rather than that of Skype)
- The features needed for each product could be different, even if these are tweaks. The common components may provide a core technology, but even in these, there could be significant differences. A product that is geared towards an expert in the field of video would demand support for a more comprehensive set of video formats, while a more entry level product would just want support for a few widely used video formats. The makers of the common component have to work towards balancing the needs for such different requests for requirements, using the priority of the products that are requesting such features as a variable in making decisions.

As a result, if you are not part of the most important team, you have to keep in mind that your requests, even though important to your team, and critical, may not make it to the final list of items that the component team is working on. We have been in that position, and it can be pretty painful, but you are reminded that it is a decision meant for the good of the organization. What can you do about such a situation ? Well, there are a number of items that you can do:
- When you know that such a prioritization problem can happen, you need to ensure that for requirements which require a modification in the common component, you start working a bit early on those requirements and have the relevant discussions with the component team early. The later you present your requirements to the external team, the more problematic will be the conflicts that the external team will have to factor in, and the higher the probability that your requirements will not make it.
- Strike up a discussion with the product team that drives the requirements of the component team and learn about what are some of the new features that they are looking for. Evaluate those to see which of those fit into your requirements, which will give you a higher chance of ensuring that your features do make it.
- Even if the requirements differ like the point made earlier about different products requiring different levels of video format support, getting into discussions early and having more discussions geared towards such kind of support can ensure that the component team is able to provide alternative functionality, such as the same component providing different levels of functionality depending on variables that are passed to the component.

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 factors are considered during component qualification in component based development?

Component based development is now becoming a common practice nowadays for re- using the validated software components of the already existing software systems or applications as a measure to shorten the development periods and enhance the quality of the software system or application.

The component based development focus on the development of new software systems by selection of the software components within the system architecture. Furthermore, the component based development has been known to accelerate the productivity of the development process and reduce the project costs. 

However, the success of the component based development depends on the suitability of the components chosen for the development of the new software. In this article we have discussed about the factors that should be considered during the component qualification in component based development. 

Due to some factors like increasing complexity and continuous change, it is required that the software should be changed to make the both ends meet. As a consequence, the software system or applications becomes more and more complex which means more and more errors. Assembling pre- existing software components not only increases the maintainability of the systems but also lends it more flexibility. Moreover, the system is assembled rapidly. It would not be wrong to call a component an independent entity intact with a complete functionality.

Process of Component Qualification

- Component qualification is a process that involves determination of the suitability of the component for being re- used in the next software system or application to be built. 

- This process of component qualification often comes to a great help whenever there is a competition for the products in the market.

- There are numerous factors that should be considered while counting for the qualification of a software component. 

Factors Considered during Component Qualification

- The most important factors are of the functionality and services that are being provided by the software component. 

- The factors also consist of many other aspects like those mentioned below:

1. Standards that have been used to develop the software component.
2. Quality aspects like usability, reusability and component reliability and so on.

- The components should have been developed under some standards and provide functions common to most of the different software systems and applications should be qualified.

- Further, the qualified components should exhibit the property of re- usability to a high extent. 

- Components form high level aggregations of the smaller software pieces. 

- All these components together provide a black box building approach which encapsulates the implementation detail from the development environment and is re- usable with the interfaces.

- For a component to be qualified, the component should have been developed in such a way that it is able to connect to a software component during the run time of the system. 

- Or we can say that in order to be qualified, the component should exhibit the quality of independent deployment. 

- This is necessary because this approach makes use of the resources. 

- The component qualification is one of the development activities that are under taken by the component based software development. The other three activities are:

1. Component adaptation
2. Assembling components
3. System evolution

- All the above mentioned three activities follow up after the component qualification. 

-The components that are required are defined by the system architecture and requirements. - The characteristics of the component interfaces usually form the basic criteria for their qualification even though the degree of fitness of the component in requirements and architecture is not provided by the interface. 

- Interface here means the services that are provided by the component and the means through which these are accessed by the consumers. 

Designing Conventional Components- Graphical Design Notation and Tabular Design Notation

A set of constrained logical constructs that emphasize on maintenance of functional domain are used for designing conventional components. These logical constructs are sequence, condition, and repetition. Structured programming is a design technique that constrains logic flow to three constructs: sequence, condition, and repetition. These structured constructs help in reducing the complexity of the program and enhances readability, test ability and maintainability.

GRAPHICAL DESIGN NOTATION
- Activity diagram is a descendant of flowchart in which all elements of structured programming are represented.
- In a flowchart, each step in the process is represented by a different symbol and contains a short description of the process step.
- Structured programming constructs should make it easier to understand the design. If unnecessary complexity is introduced by using them without violation, it is better ti violate them.
- Dogmatic use of structured constructs introduces inefficiency.

TABULAR DESIGN NOTATION
- Decision tables translates actions and conditions into a tabular form.
- A decision table is used when a complex set of conditions and actions are encountered within a component.
- Decision table is divided into four quadrants. Upper left quadrant lists all conditions. Lower left quadrant lists all actions. Right hand quadrants form a matrix indicating condition combinations and corresponding actions

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.