Separation of development, test (homologation) and production environments are important to achieve segregation of functions involved. It is appropriate that the rules for the software development to transfer to a production environments are well defined and documented.

The development and test activities can cause serious problems such as, for example, wholly or partially unauthorized file or system changes. I ought to be rated the level of separation required between the production environment and test and development environments, to prevent operational problems. It is appropriate that a similar separation should also be implemented between development and test functions. In this case, the existence of a reliable and stable environment is needed, in which tests can be performed and which is capable of preventing unauthorized access of personnel development.

When developing and testing staff have access to the production environment, they can introduce untested or unauthorized code, or even change the actual data of the system. In some systems, this capability can be hardly used to implement fraud or introduction of malicious code or not tested. This type of code can cause serious operational problems. The development of staff and in charge of the tests also pose a threat to confidentiality of production information.

The development and testing activities may cause unintended changes to software and information if they share the same computing environment. The separation of resource development, test and operational is this very desirable way to reduce the risk of accidental modification or unauthorized access to operational software and business data. It is recommended that the following controls should be considered:

• What software development and production of software are, whenever possible run on different processors or different domains or directories;
• That the development and testing activities occur separately, as far as possible;
• What compilers, editors and other utilities are not accessible from the production environment, when this is not a necessity;
• that the process of accessing the production environment is different from the access development to reduce the possibility of error. Users should be encouraged to use different passwords for these environments and splash screens display appropriate identification messages.

Finally, it is pertinent that the development of personal passwords to get access to the production environment, and in a controlled manner and only for systems support the production environment. It is also important that controls are used to ensure that such passwords are changed after use.

Visit our blog and check out more content! Discovery the scriptcase!

By ,

December 21, 2015

a

You might also like…

No-code: Ease or Trap? What no one tells you about creating without coding

With the popularization of No-code and Low-code platforms, application development has reached a po...

Top 10 Rapid App Development Tools You Need to Know

In this highly fast-moving digital world, rapid application development tools must be available to ...

You might also like…

Get new posts, resources, offers and more each week.

We will use the information you provide to update you about our Newsletter and Special Offers. You can unsubscribe any time you want by clinck in a link in the footer of any email you receive from us, or by contacting us at sales@scriptcase.net. Learn more about our Privacy Police.