Development & Support

For more than 15 years, VISUALOGIC has been providing value-added Application solutions and  services on a wide range of  clients in Malaysia. Our broad range of Application solutions and services ensure that as you decide to adopt or expand your use of technology we are able to assist at every steps of the way, now and in the future.

We offer significant experience and expertise in a broad range of technologies and applications especially on the IBM AS/400 (iSeries) platform, with a portfolio of services that includes:

Our approach to software development is based on some of the most reliable, effective and globally accepted methodologies in the industry today. We adopt a configurable software development process that is based on many years of experience in using object technology to develop mission critical software in a variety of industries.

This methodology allows us to define a clear, repeatable process for quality software to be delivered to our customers on time, every time. Our processes are tailored to meet customer requirements and are aimed at delivered maximum, tangible value to them within determinable project boundaries of cost, schedule and effort. This methodology is supported by tools, which automate large parts of the process including visual modeling, requirements and change management as well as documentation and testing.

At Visualogic, we help define your requirements, write specifications and design, develop, test and integrate software across multiple platforms – including internet technologies – enabling your systems to function in new operating environments.

Our objective is to work with customers and to evolve a final system from an initial outline specification whereby it should start with well-understood requirements and add new features as proposed by the customer.

There are two main division to handle software development which are, management division that responsible in project planning and management, configuration management, quality assurance, installation and training and construction division that’s is the one who handle the requirements definition, system and software design, system coding development, implementation and unit testing, integration and system testing and operational maintenance.

 

Maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes. A common perception of maintenance is that it is merely fixing bugs.

The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis, testing, maintainability measurement. Best and Worst Practices in Software Maintenance Because maintenance of aging legacy software is very labour intensive it is quite important to explore the best and most cost effective methods available for dealing with the millions of applications that currently exist. The sets of best and worst practices are not the same. Just as practice that has the most positive impact on maintenance productivity is the use of trained maintenance experts, while the factor that has the greatest negative impact is the presence error-prone modules in application being maintained.

Keys benefit of refactor

 

  • Make things clearer
  • Prepare things for expansion
  • when not to refactor, if it is not fixing the bug
 
Testing

It is one of the most critical parts of Software Engineering

  • find bugs,among many things
  • Prove the existence of bugs, not their absence
  • make changing things easier
  • provide concrete quality metric
  • help you see and understand what software should and should not do
Kind of test:

unit tests, system test, integration tests, fuzzy tests, stress test, regression tests

Test delivery options:

Automated: run over and over. Run for every build

Manual: run occasionally(when you have the time)

Test development methods:

Black-box: Written with no knowledge of internal workings of the software – does sfware do what it sould?

White-box: Developer writes them with the understanding of the internal workings of the program – does the software not do what it should not?

Reverse engineering is the process of discovering the technological principles of a human made device, object or system through analysis of its structure, function and operation. It often involves taking something (e.g., a mechanical device, electronic component, or software program) apart and analyzing its workings in detail to be used in maintenance, or to try to make a new device or program that does the same thing without using or simply duplicating (without understanding) the original.

Reverse engineering has its origins in the analysis of hardware for commercial or military advantage. The purpose is to deduce design decisions from end products with little or no additional knowledge about the procedures involved in the original production. The same techniques are subsequently being researched for application to legacy software systems, not for industrial or defence ends, but rather to replace incorrect, incomplete, or otherwise unavailable documentation.

The term reverse engineering as applied to software means different things to different people, prompting Chikofsky and Cross to write a paper researching the various uses and defining a taxonomy. From their paper, they state, “Reverse engineering is the process of analyzing a subject system to create representations of the system at a higher level of abstraction.”It can also be seen as “going backwards through the development cycle”. In this model, the output of the implementation phase (in source code form) is reverse-engineered back to the analysis phase, in an inversion of the traditional waterfall model. Reverse engineering is a process of examination only: the software system under consideration is not modified (which would make it re-engineering).Software anti-tamper technology is used to deter both reverse engineering and re-engineering of proprietary software and software-powered systems. In practice, two main types of reverse engineering emerge. In the first case, source code is already available for the software, but higher-level aspects of the program, perhaps poorly documented or documented but no longer valid, are discovered. In the second case, there is no source code available for the software, and any efforts towards discovering one possible source code for the software are regarded as reverse engineering. This second usage of the term is the one most people are familiar with. Reverse engineering of software can make use of the clean room designtechnique to avoid copyright infringement.

On a related note, black box testing in software engineering has a lot in common with reverse engineering. The tester usually has the API, but their goals are to find bugs and undocumented features by bashing the product from outside.

Other purposes of reverse engineering include security auditing, removal of copy protection (“cracking”), circumvention of access restrictions often present in consumer electronics, customization of embedded systems (such as engine management systems), in-house repairs or retrofits, enabling of additional features on low-cost “crippled” hardware (such as some graphics card chip-sets), or even mere satisfaction of curiosity.

The Certified Reverse Engineering Analyst (CREA) is a certification provided by the IACRB that certifies candidates are proficient in reverse engineering software.

Reverse engineering tools can be used to enhance system comprehension and retrieving missing design document. Although the correctness and completeness of the tools result is varies and sometimes questionable, however, it can be a good starting option to understand a system.