Software Engineering

Risks associated with B2B e-commerce include the technical problems of creating an Internet-facing business system that enables you and your partners to save money and react quickly by doing all transactions electronically. Additionally, I found there is some concern about the antitrust risks of business-to-business exchanges. I initially started searching for technical risks, and came across this document about the business risks of competitors working closely in collaboration to negotiate prices. http://mipr.umn.edu/archive/v2n2/gotfredson.pdf Certain models of B2B exchanges would have the competitors in an open auction against each other to win the bid for some product or service. “In spite of the promises inherent in this new business model, B2B exchanges necessarily involve collaboration between competitors in a market, and thus raise potential antitrust concerns.” There is actually nothing new here about types of antitrust activities a company might undertake with B2B. I think the point of the paper tells us that the Internet potentially makes this easier to take place. Connectivity between competitors and collaborators over the Internet and the growing sophistication of software provides an atmosphere where antitrust activities can occur without immediate notice. “A second antitrust risk associated with B2B exchanges stems from the fact that the Internet allows for the aggregation and analysis of copious information concerning the exchange’s participants.” I was not able to determine if any company has had legal action taken against them for B2B-related antitrust activities. The technical risks involved with B2B are typical for Internet-facing servers of e-commerce applications. For instance, Amazon uses a web front end to interface with their customers. The front-end of an application is one place vulnerabilities can be exploited to someone’s gain. Even though B2B exchanges may use a different kind of communication protocol, like a web-service or EDI communication, if there are weaknesses in the protocol, there is a possibility someone could use it to their advantage without immediate notice. An act that is as simple as transmitting illegal values for valid operations could allow unauthorized access because of a lack of sufficient defensive programming on the server-side. I found a PowerPoint presentation (link below) that listed some areas of potential loss from poorly designed e-commerce systems. Theft of Intellectual Property Theft of Proprietary Information Sabotage of Data Networks System Penetration Insider Abuse Financial Fraud Denial of Service Virus http://www.business.duq.edu/BusinessSecurity/docs/mootcourt.ppt ...

No limit to bandwidth means that it would be possible to send any amount of information across a network with no latency. Such an achievement would change more things than just the web. For instance, with the capability of limitless bandwidth, data storage and processing power would no doubt have made equivalent leaps as well. These are components of networking infrastructure as well as general purpose computers. So, networking equipment that provided limitless bandwidth would also include processing power to handle the load - processing power with no limits. Moving any amount of information with no latency also means you need some place to put it - data storage with no limits. With these limits removed, there might be no need for a web at all. The ability to move any amount of information instantly might mean we keep a copy for ourselves of everything we interact with, continually accumulating and indexing data at a constant rate from other information providers for the rest of our lives. From this I can imagine having my own reference database of accumulated information that becomes our private web, or life encyclopedia. ...

I believe one of the reasons many businesses do not use the Software Development Life Cycle is due to lack of awareness that such a process exists. I have experienced this first hand from my own attempts at running projects early in my career. My first positions were in smaller companies where less formality was necessary. Those experiences with planning and running projects were for small tasks. I would do development for the solution, and I would work with at most three other people. The other technical people working on the task would test or help out in other aspects. Most decisions were made at the office kitchen table and little needed to be recorded in documents. Once an awareness of the Software Development Life Cycle exists, the next problem is how to go about producing the artifacts that are necessary to project success. We have been given a very wide and shallow introduction to the System Development Life Cycle. This is good if you never have seen this before in your life. I have specific questions now about what is needed to be documented in each project phase. For instance, what do good requirements look like? Seeing templates or samples of existing project documents would speed an immature team’s understanding of where formality can stabilize a project and how much overhead formal process will add to the project time line. The final possibility that may contribute to lack formal processes for development is that business management does not believe it brings as many benefits compared to the existing system of project management. The SDLC affects not only the Information Technology team, but the departments receiving and affected by the creation of an automated solution to a business problem. I found an article on the web, talking about formal methods of engineering. I think this paragraph brings some insight into the business decision of bringing formality to an existing business infrastructure: “The decision to use a new methodology is driven by economics: Do the benefits of the new method exceed the costs of converting to it and using it by a sufficient margin to justify the risks of doing so?” [1] [1] An Overview of Systems Design and Development Methodologies with Regard to the Involvement of Users and Other Stakeholders, SHAWREN SINGH AND PAULA KOTZ, University of South Africa ...

In my experience developing software, I find the most important phase is the Elaboration phase. The reason I feel it is the most important is because it is the join point between the definition of the business problem and the construction of the solution. During the Inception phase, you baseline your vision and solution to a problem and you make the business case for building it. At the end of the Inception phase you should have support and funding from the business to move forward. Everyone involved with the project should be in agreement about what the team is trying to build. If there is any misinterpretation, especially from your funding source, you need deal with it here. The Elaboration phase is when the technical solution is determined - not actually built. This phase is the clarification phase. There is modeling, risk analysis, prototyping and refining of the requirements. This phase is when you find out if the solution can actually be built. You leave the elaboration phase with an architecture on paper (or in a modeling tool) and something that runs just enough that can prove the system can be completed successfully. I believe this is the point where funding really needs to kick in. During Construction and Transition, headcount is being adding in the form of developers, testers, documentation writers, test engineering, release engineering, legal, etc. You are beginning to train the trainers, the sales staff, and the consultants. If the project is not going to succeed, it is in your best interest to kill it off before you begin construction phase. ...