Archive for August, 2010

Quality Testing: How a high quality product will ensure satisfaction of your customer

qaHow will the development of a high quality product make the life of your customer and, as a consequence, your own life better?

To answer this question we suggest the following options:

1. Testing of the software will reduce the number of its returns for further development (including returns from the Customer and end users) during its implementation and, what is more important, its operation and maintenance phase. This will allow:

-  for a reduction in  time spent by  developers  in enhancements, correction and administration of the product;

-  for less  consultant and developer diversion  (for these enhancements) from other projects;

-  As a result of the two aforementioned points – the project will  keep to a certain budget and terms? time frame?  – Surely any directors dream!

2. Project testing will contribute to a considerable reduction of errors and requests that come to a technical support team. This will allow:

- for less time to be spent by technical support team specialists and also people who will be involved in correcting possible errors;

- for an increase satisfaction and loyalty of the Customer which is quite crucial.

3. Project testing will help reduce the risks of possible software failures resulting from which the Customer may lose real money.

The main specificity here is in the fact that the emergence of a failure in the “field environment” is very costly and testing can help reduce the number of such failures. This is what the Customer may get, meaning they cansave  money on testing. At the same time, the return of investment (ROI) is achieved by means of reducing the number of problems in operation; the Customer doesn’t lose any money when, due to system failures they do not receive it from their clients.  The Customer is ready to pay for this, thus increasing the project budget.

This happens to be the most honest way of treating the Customer. When the contractor makes a cheap product with a number of faults and then persistently demands money from the Customer for support, administration and error correction, the strategy “Money for your own mistakes” is a surefire recipe for success.

4. Testing of requirements. This type of testing at the earliest stages of project implementation will allow  for a reduction at the minimum expense of a large number of errors  and  for a reduction in time for developers who are often  limited by  incomplete, unclear, and non-testable,  requirements. To postpone testing is to reject it. Passing up testing once will see it passed up for good.  (A stitch in time saves nine! ← this is what you’re saying in a less literal way.)

Softage offers product software testing and quality assurance services. Contact us through our website http://www.softage-group.com/ for a free project quote.

Posted in Uncategorized at 01:08

No Comments »

How to Introduce Architecture and its Changes

The specifics of describing architecture and its changes is in the fact that as opposed to a program code it has no evident representation, except for those cases when it is clearly documented. However, even in this case it is hard to guarantee the correspondence of documented architecture to the factual high-level logical structure which in reality exists in the system.

Structural models can become means of describing architecture and its changes. There are currently a large number of notations and tools supporting structural modeling of software. The possibility of the automatic extraction of models from a code guarantees their precision and allows for their timely updating. This possibility becomes crucial for choosing the necessary tools as the compliance of the model with the factual structure of the existing code in the process of modeling the architecture and its changes happens to be exceptionally important for securing a precise and manageable process.

For the further study of program systems architecture we will use a notation of structural modeling accepted in KLOCwork Architect tool which allows for the automatic extraction of models from a program code and their editing. Here is a brief review of the notation:

Program system models utilized by KLOCwork Architect are somewhat similar to Entity-Relation models. They belong to a class of container models. The model’s basic elements are as follows:

Architecture Block.KLOCwork Architect model consists of so called architecture blocks. Architecture blocks introduce into models structural elements of a program system irrespective of the level of abstraction in which the modeling takes place. Architecture blocks have at least two major attributes, such as name and type. Names of architecture blocks are predetermined by the names of those structural elements of the system which they introduce into models. Types of architecture blocks substantially depend on the level of abstraction where modeling takes place, and a concrete task within which the research of the architecture is carried out. For example, to model systems built within any component technologies “components” will be the type of architecture blocks used. For modeling systems of building software the chiefly used types will be “folders” and “files”.

Relation. In the model KLOCwork Architect relation means a one-way relation between a pair of architecture blocks. Just like architecture blocks, relations can be of various types. The following types of relations can be used as an example:

Instancing: A instances B (block A is a function, block B is a class).

Access to data: A reads data from B (block A is a function, block B is a class or a class attribute).

Between any pair of blocks there can be a random number of differently directed relations. Their types can also be differentiated at the same time.

Posted in Corporate software, Outsourcing at 12:08

No Comments »

Architecture Refactoring

architecture_toolsRefactoring is one of the most successful approaches to changing existing software. It is the approach based on systematic transformations of the initial code. Refactoring is the change in the internal structure of software aimed at facilitating the understanding of how it works and simplifying the modification without tackling the observed behavior. It is commonly understood that during a software development process the system design is created first and only then is its code is written. In the course of time the code is modified and the system wholeness, i.e. the correspondence of its structure to the initial design slowly gets worse. The further development of the system gradually shifts from a directed, guided activity to hacking. Refactoring appears to be quite the opposite practice. With its help any chaotic and misguided project can be transformed into a well-designed code. Each step of the process is quite simple. For example, one of the steps involves transferring the field or method from one class into another, class separation, etc. However, the total effect of such minor and seemingly insignificant changes proves to be cumulative and can radically change a project for better. The process of refactoring is a direct opposite to a gradual system code degradation.

For documenting and cataloguing refactoring methods, one uses semiformal notation in which every method is described by means of a so-called pattern. Any pattern describes and names typical tasks which constantly appear in the process of work, and also the principle of their solution. As a result, such solutions can be used over and over again. Patterns name, demarcate and identify key aspects of a general solution structure. Patterns also form the dictionary of solutions to a certain problem area and allow two specialists in that field to name typical solutions and understand each other without explaining the core of solutions.

The refactoring of an object-oriented code has proved to be an efficient means of solving tasks of program evolution and support. However, presently there are practically no studies dealing with refactoring at a higher level of abstraction – the level of software architecture. Correspondingly, the transfer of this methodology to a higher level of abstraction is interesting.

Posted in Corporate software, Outsourcing at 12:08

No Comments »

Functionality of Identity & Access Management Systems

In their nature, IAM systems appear as an in-house or external single data storage about users. Their major objective is to ensure that data accounts granting the necessary rights appear in all the applications required by the user (preferably there should be one single account for all the applications).

Here is what this process looks like:

A request is compiled in the system regarding the necessity of granting a certain group rights (possibly, by means of acquiring data on regular operations from a corresponding system)

The request is confirmed with all responsible persons including specialists capable of assessing the consequences of such an access

When confirmed, this request is broadcast into instructions and is to be executed by system administrators

System administrators carry out all the necessary settings

The system controls the faultlessness of these settings, their completeness and sufficiency

The instructions may be carried out in the automated mode.

In order to allow the user to remember only one data account Identity Management systems are integrated with Access Control Management and Single Sign-On solutions.

Allowing the user to authenticate themselves in all the applications with the help of one set of credentials presents significant challenges, because applied systems support a limited and often non-crossing set of authentication methods. Moreover, the credentials format in various systems may not coincide (from the banned use of certain symbols up to problems with coding).

The accomplishment of this task requires:

  • specialized agents to which the application can delegate authentication functions (under the condition that the application is capable of actually delegating this function);
  • intermediary authentication servers to convert credentials from one format into another.

Among the chief parameters characterizing IAM-systems are:

  • document management properties
  • flexible use and application for organizations with their own traditions
  • the possibility of integration with existing document management systems
  • the possibility of applying the electronic digital signature

in the compilation and approval of requests

  • a list of supervised platforms and applications including requested rates of creating new agents for new platforms
  • accounting system development.

Posted in Corporate software at 12:08

No Comments »