Dimensions of SCM Challenge #4 - Schedule & Technological Diversity

[article]

and scheduling for the change from the beginning of development. Sometimes feature isolation is not done, either because it cannot be done, because the development process does not encourage it, or because the need for isolation was not obvious at the start of development. In this case, workflow gates at the end of the life cycle can be used to help reconcile the delivery schedule(s). Since the features are not isolated, the choices will generally be to deliver what is available, or spend more time and effort disentangling things. As a CM specialist, you will offer lifecycle and tool support for this, but try to avoid being in these meetings-they're usually pretty loud.

Dimension: Technological Diversity

Combining two or more different technologies within a project can cause organizational problems and information flow problems. Organizational problems usually arise when the different technologies are managed by different organizational units. If a project requires a Java web interface communicating with a mainframe server, the Java and mainframe elements will probably be developed by different teams. The need to coordinate development resources from different teams is one potential source of organizational problems. Please refer to the (later) article on Organizational Structure for a discussion.

Information flow problems occur when members of the team don't know understand the details of a technology, or don't understand the requirements or process behind a technology. Even if a technology is well-integrated into the development environment, team members who are unfamiliar with the technology can make mistakes in designing around the technology, or in establishing tests for components that incorporate the technology. The failure will appear to be ‘bad design' or ‘bad testing' or bad something-or-other. But the root cause will be not understanding an unfamiliar technology, or failing to coordinate the project members working on different technologies.

For example, consider the basic programming task of storing data in a SQL database, and presenting and editing that data via a web page. Almost every website in existence relies on these two basic technologies, but even today developers make mistakes that result in security breaches, loss of personal identity data, and database corruption. One part of the problem stems from the switch between two different languages. The web interface may be developed in Java, PHP, or Perl, but the database access is inevitably done via SQL. Developers that fail to understand SQL, or fail to understand the interface to SQL provided by their   development environment, may code their database access in a way that is vulnerable to SQL Injection Attacks. Consider a script that constructs SQL like this:

$statement = "INSERT INTO table VALUES
(‘$name', ‘$address')";

This will pass testing, but is vulnerable to an attacker that sets $address to a partial SQL statement, such as $address = "X'); DELETE FROM table
WHERE (‘x' != ‘y"
. This attack closes the initial statement (INSERT) then appends a separate statement (DELETE). As long as the second statement merges with the text at the end of the statement, both statements appear to be valid, and may be executed by the SQL engine being used by the application[1].

This is a simplistic example, and all the languages mentioned have SQL interfaces that can eliminate this vulnerability. But the news is filled with reports of attacks being discovered against popular systems. The fact that a safe method exists does not guarantee that the safe method is being used. Software CM cannot prevent bad code. But it can help reduce the risks of dealing with diverse technologies by enforcing process and by identifying risky technologies and making sure attention is focused on those components and on the interfaces between those components and others. The Codevelopment technique Formal Interfaces & Standards is one obvious way to help isolate risks. Establishing a formal interface between a risky component and the remainder of the system helps ensure design and testing are focused on the technology.

If the project

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09