Explain empirical vs defined & prescriptive process?

To make any process successful it has to be controlled in a way that it achieves its predefined goals or we can say it should be guided along the path of success. This fact holds good for any type of process in this world and so does for the processes in the field of software engineering.

In the field of software engineering, two approaches have been identified for keeping a control over the development and other related processes namely:


1. The empirical process control method and
2. The defined process control method.


In this article the above mentioned two approaches have been compared so that you get a better understanding of both the programs. So let us see how these two approaches control the processes.

The Empirical Process Control Method

- The empirical process control model was defined to exercise or control the process via following some frequent adaptations as well as frequent inspections.

- These inspections and the adaptations both are meant for the generation of the unpredictable and unrepeatable outcomes or results and can be thought of as being imperfectly designed.

- Since for the past many years the various software development methodologies have been known to be controlled by the latter approach i.e., the defined process control method.

- But we all know that every time a certain same output or outcome cannot be expected from the software development processes.

- Therefore, most of the agile software development methodologies are controlled by the empirical process control model and the most famous example being that of the “scrum” agile software development methodology.

- The term empirical process control model itself justifies as the term empirical means the information acquired by the means of experimentation and observation.

- Here the information is achieved by means of inspection and adaptations which serve as a means for the observation and experimentation.

- The process of the empirical control is constituted of a continuous cycle of adaptation of the process as per the requirements and inspection of the process for correct working.

- The empirical control process model has three pillars as we can make out from the definition of the process control model without which it cannot be called as the empirical process control method:
1. Transparency
2. Inspection and
3. Adaptation.

- The first pillar i.e., transparency indicates that the outcomes of the affects of the empirical process control model and the aspects affecting the outcomes should be visible to the programmers and developers who are responsible for controlling the whole process.

- The second pillar i.e., the inspection indicates that all the aspects of the control process should be monitored quite frequently to enable the fast and early detection of the unacceptable variances.

- The third pillar i.e., the adaptation indicates the adjustment of one or more aspects as required of the control process if the software system or application being processed is observed to lie outside the acceptable limits implying that the result will also be unacceptable.

- The defined process control model approach is adopted when the underlying mechanisms of the software system or application are well understood by the programmers and the developers.

The Defined Process Control Model

- The defined process control model can be thought of as a theoretical approach.

- When a well defined set of inputs is given, it is obvious that the same outcomes will be generated every time the program executes.

- With the well understood technologies and stable requirements, one can very well predict a whole software project.

- Even nowadays the empirical process control model holds as the essence of the agile software development processes.

- Empirical process holds good for the complex development processes which encounter difficulty in the production of repetitive outcomes.

Overview of Localization and what is Software Localization

Localization is the process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets. Translating and adapting both the content (text and style) and the presentation (graphical and technical components) of an EXISTING product according to the language and cultural characteristics of the target audience or region for which it is intended.

- Localization testing are not strictly a part of the development of world-ready software.
- Localization becomes possible once you have developed world-ready software.
- The end result of localization is a product that is appropriate for the target locale's business and cultural conventions, appears custom built for the end user's cultural and linguistic background does not change the original intended meaning.
- Users can interact with a successfully localized product in their own language and in a setting that feels natural to them.

Software localization is the process of adapting a software product to the linguistic, cultural and technical requirements of a target market. Software localization is the translation and adaptation of a software or web product, including the software itself and all related product documentation.
- This process often requires a lot of work hours and tremendous effort from the development teams.
- There are a number of tools that were specifically created in order to simplify the localization process.

Software Localization Process

- Identification of what must be translated from a software.
- Adopting a localization strategy.
- Schedule for localization process should be established and deadlines should be created.
- Recruiting adequate, professional translators.
- Ensure the accuracy and coherence of translator's work.
- Consult the development team.
- Define a properly internationalized product that won't need to undergo changes for each of the envisaged foreign languages.
- Testing the product for each and every one of the languages in question.

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.