Networked vs. Non-Networked Applications

On 10.15.10, In Applications, software, By Dan Calloway

by DAN CALLOWAY
Published 15 October 2010

WEAVERVILLE, NC - Many of today’s applications used in business, academia, the medical field, and others are network-based as opposed to non-network-based, traditional systems, or even legacy systems that were prominent in the decades just prior to the onset of the Information Age and the advent of the desktop computer and networks that linked them together. In the last quarter of the 20th Century, the industrial age underwent a metamorphosis, due in large part to the societal-centered technological revolution that was taking place around information. The technological revolution, which began in the early ’70s, literally transformed the way that we think, the way we conduct business, we learn, we communicate, we live, we make war, and we die. Rouse (1999) suggests that the explosive growth in networking brought about with the onset of the Information Age in the 1980′s is primarily responsible for linking people and systems together, thus globally providing instantaneous access to information resources never seen before.

Prior to the development of the network concept and the global Inter-network, software applications that were in existence ran primarily on mainframes and mini-mainframe systems. These applications were, in essence, self-contained applications running on standalone systems such as DEC and VAX platforms, and were supported by non-network operating systems such as UNIX. Data that was processed on these system platforms were not shared with others or accessible by others but remained self-contained to the platform that processed them and were only interfaced with human operators via desktop terminals tied into the mainframe and mini-mainframe systems. With the technological revolution, spurted by the military and academia, the need to share information with one another, even across vast distances, grew exponentially. The first true network was developed by MIT in order for various departments within the University to share information with one another on networked host platforms. The Department of Defense’s need to share information for national security and other military purposes brought about the development of ARPANET, the first true Internet-based networking system that permitted collaborative sharing of data across the network with various military organizations that needed it. Thus, in the Information Age, the rapidly emerging integration of PCs and communications networks and broadcast networks is making information available to everyone at anytime on a global scale (Rouse, 1999).

What is important to realize in the modern Information Age and the development of network-based applications and systems is that this technology not only has afforded one access to the rest of the world in real-time, but gives the rest of the world access to you (Rouse, 1999, p. 118). Networks and the applications that run on them permit people to remain connected no matter where they might be globally. Examples of these applications are Skype, Microsoft Net-Meeting, and Microsoft Instant Messenger, to name a few. Other network-based applications such as Go-to-Meeting, and PC-Anywhere, allow individuals and groups of individuals to telecommute on a business level so that they can conduct business with one another without ever having to meet one another face-to-face (Rouse, 1999, p. 118). Network-based applications, such as Web browsers and the websites that they connect us to have opened up a whole new avenue of business, such as eBay, Amazon.com, manufacturer-specific websites, and many others. Advances in online business known as e-Commerce have introduced a plethora of new products and services and have provided a rich resource of opportunities and creativity not available prior to the Information Age (Rouse, 1999). As Rouse aptly points out in his article on connectivity, the Information Age and the sharing of information through networking has had dramatic impacts not only on individuals, but also on governments, on business organizations, the military, and academia as well (pp. 119-120).

An aspect of networking and connectivity, which was not discussed in Rouse (1999) or any other reading for this week’s discussion is the pervasive, ubiquitous, and sentient nature of Radio-Frequency Identification (RFID) networking. This networking paradigm has transformed and continues to transform the business world through its direct impact upon the supply chain and upon society as a whole in a very positive way because RFID networking and smart tags have allowed inanimate, static objects to be connected to each other and to humans (Calloway, 2010)⁠.

“The storing, interpreting, and use of relevant information is becoming the primary concern in the next decade [2010-2019] due to the increasing merger of analog and digital media, and context. In the next decade, RFID smart tags implanted into static objects and the development of the RFID network known as The Internet of Things will allow pervasive computing, ubiquitous computing, and sentient computing, to transform our very environment—not just our computers—such that it will become smarter because computing power and connectivity will be embedded into it” (Calloway, 2010, p. 1).

The implications that RFID networking and smart tagging have on society are many-fold. Smart tags embedded in pallets of material that are stored and shipped around the world give the receivers of these goods the ability to track their progress in the supply chain as well as provide a status of their condition along their transport routes. As a result, retail outlets can now determine when material they have ordered is shipped and can more adequately determine when the material will arrive in their stores or their remote warehouses. The cost savings that are realized from smart tags embedded in palletized material result in savings that retailers pass on to its customers, reducing the cost of goods to the consumer. Moreover, smart tags connected to the RFID network have found their ways into other industries such as the medical field, automobile industry, pharmaceutical industry, applicance and clothing manufacturing, home manufacturing, GPS tracking, and utilities metering to name a few.

References:

Calloway, D. (2010). RFID Microchip Technology and the Internet of Things. Retrieved from http://www.dancalloway.com/assets/Documents/RFID_and_the_Internet_of_Things.pdf.

Rouse, W. B. (1999). Connectivity, creativity, and chaos. Information Knowledge Systems Management, 1(2), 117-131.

Dan Calloway

Wikio
Wikio
Tagged with: • • • •
 
34 Comments
Please Leave A Response

Structured English

On 06.20.10, In software, By Dan Calloway

by DAN CALLOWAY
Published 20 June 2010

WEAVERVILLE, NC - Structured English is the process used to plan, design, or document program routines, modules, or manual procedures using a very restricted subset of the English language (structured english, 2010). It resembles programming language so programmers can understand it quite easily, and, since it is based on the English language, it is easy to comprehend and follow as well. One of the disadvantages of using Structured English is that is is not a good choice for describing a high-level control structure or an algorithm that requires many decisions to be made; logic flowcharts, decision tables, and decision trees are better choices in this case (structured english, 2010).

The process or procedure that I have chosen to portray using Structured English is the process or procedure of addressing a flat tire. Using a simple set of conventional keywords, this procedure can be illustrated as follows:

IF tire is flat THEN IF spare tire in trunk is flat THEN call a garage for a tow ELSE spare tire in trunk is not flat SO jack up the carIF all the wheel lugs have been unscrewed THEN remove the wheel ELSE all the wheel lugs have not been unscrewed SO unscrew a lug REPEAT unscrewing lugs until all lugs have been unscrewed SO put on the spare

IF all the wheel lugs have been screwed on THEN jack the car down ELSE all the wheel lugs have not been screwed on SO screw on a lug REPEAT screwing on lugs until all lugs have been screwed on securely SO stop changing the tire

Reference:

“structured english” 2010. Retrieved from http://www.hit.ac.il/staff/leonidm/information-systems/ch60.html.

Wikio
Wikio
Tagged with:
 
14 Comments
Please Leave A Response

IT Project Implementation Failures

On 06.16.10, In Information Technology, software, By dancalloway

by DAN CALLOWAY
Published 16 June 2010

WEAVERVILLE, NC – Most computer-based information systems and especially those involving large system development projects in the past several decades have involved the business sector – especially for large businesses – or have been associated with the business sector in some way. These information systems have been collectively referred to as Enterprise Resource Planning (ERP) systems. Hoffer, George, and Valacich (2011) define ERP as “a system that integrates individual business functions into a series of modules so that a single transaction occurs seamlessly within a single information system rather than several separate systems” (p. 529). Umble, E. J., Haft, and Umble, M. (2003) describe the evolution of the ERP beginning in the 1960s when the focus on the manufacturing process was on inventory control, through the development of Materials Requirement Planning (MRP) in the 1970s when businesses discovered they could no longer maintain just-in-time inventories on-hand to satisfy customer requirements, and on into the 1980s when companies realized they could take advantage of the increased power and affordability of available technology and were able to combine the movement of inventory with the coincident financial activity within the business (p. 242). This latter movement spawned the development of MRP II systems, which involved the incorporation of the financial accounting system and the financial management system along with the materials management and manufacturing systems within the business sector that allowed companies to have a more integrated business. This new integrated business system derived the material and capacity requirements associated with the desired operations plan, allowed for the input of detailed activities, translated this information into a financial statement, and suggested a strategy to address those actions that were not in balance with the desired operations plan. By the early 1990s, technological advances allowed MRP II to be expanded to include all the resources and planning for those resources within the business organization. Additional areas such as product design, materials planning, information warehousing, capacity planning, communications systems, human resources, finance, and project management could be combined with MRP II to include the entire Enterprise and, thus, the term ERP was coined (E. J. Umble et al, p. 242).

E. J. Umble et al. (2003) cites a case study of a successful implementation of an ERP system by Huck International, Inc., a designer, manufacturer, and distributer of a wide range of commercial, industrial, and aerospace fastening systems, during 1998 and 1999. The E. J. Umble et al. study attributes the success of Huck International, Inc. as the degree to which they adhered to the critical success factors, system selection guidelines, and implementation procedures of the ERP system – elements of a successful ERP that are not practiced by typical business organizations worldwide and, as a consequence, result in implementation failures. E. J. Umble et al. in citing a survey by Information Week of IT managers, goes on to state that the top three reasons for failures of IT projects and information systems implementation within the business are: (1) Poor planning or poor management [cited by 77%], (2) Change in business goals during the project [cited by 75%], and (3) Lack of business management support [cited by 73%]. Furthermore, as a direct consequence, most of the Information Systems implementation projects fall short of their potential payback, and 26% are canceled before completion. In many of the completed projects, technology is implemented in a vacuum and many users resist them. E. J. Umble et al. (citing Langenwalter, 2000) claims that as many as 40% – 60% or higher of ERP systems implementations can be classified as failures.

Based on the extensive studies conducted by E. J. Umble et al. (2003), the list of reasons for the implementation failures of ERP systems within business can be classified into the following ten categories:

  1. Strategic goals are not clearly defined whereby the organization has not clearly thought through the goals, expectations, and deliverables
  2. Top management is not committed to the system, does not see the profound changes that it engenders, and/or does not actively participate in the implementation process
  3. Implementation project management is poor wherein the organization underestimates the scope, size, and complexity of the systems implementation projects
  4. The organization is not committed to change
  5. A good implementation team is not chosen
  6. Inadequate education and training results in users of the system who are unable to run it properly
  7. Data accuracy is not ensured
  8. Performance measures are not adapted to ensure that the organization changes
  9. Multi-site issues are not properly resolved; and,
  10. Technical difficulties, such as bugs in the software, problems interfacing with existing systems, and hardware issues can lead to implementation failure.
References:

Hoffer, J., George, J., & Valacich, J. (2011). Modern Systems Analysis and Design (6 ed.). Upper Saddle River, New Jersey: Prentice Hall.

Langenwalter, G. (2000). Enterprise Resources Planning and Beyond: Integrating Your Entire Organization. Boca Raton, FL: St. Lucie Press.

Umble, E. J., Haft, R., & Umble, M. (2003). Enterprise resource planning: Implementation procedures and critical success factors. European Journal of Operational Research, 146(2), 241-257. Retrieved from http://www.sciencedirect.com.library.capella.edu/science?_ob=ArticleURL&_udi=B6VCT-47G3XP2-3&_user=4421785&_coverDate=04%2F16%2F2003&_rdoc=1&_fmt=high&_orig=search&_sort=d&_docanchor=&view=

c&_acct=C000063116&_version=1&_urlVersion=0&_userid=4421785&md5=7106269fe40a527a34ce488e5c7dea6e.

Dan Calloway

Wikio
Wikio
Tagged with: • • •
 
0 Comments
Please Leave A Response

Critique of – Global Analysis: Moving from software requirements specification to structural views of the software architecture

On 06.06.10, In software, By dancalloway

by DAN CALLOWAY
Published 6 June 2010

WEAVERVILLE, NC – In the article, Global Analysis: Moving from software requirements specification to structural views of the software architecture, Hofmeister, Nord, and Soni (2005)⁠ attempted to reexamine the use of Global Analysis activities, which is a part of the Siemens Four Views architecture design approach, and capture its results as a means of closing the gap between software requirements and architecture. The use of the Global Analysis activities, in this article, served to reduce the magnitude of this gap by guiding the architecture design process, securing the design rationale, and supporting the traceability between requirements and architecture. Hofmeister, et al. were able to show that the use of Global Analysis activities and capturing its results were of significant benefit in achieving their goal and, in some cases, the benefit went beyond what they had anticipated but, in other cases, the use of Global Analysis activities was not applied as expected.

In the process of closing the gap between software requirements and architecture, Hofmeister, et al. (2005) proposed that one solution for narrowing the gap should address the following criteria: (1) Focus attention on the architecture design requirements (ADRs), which are the requirements, quality attributes, constraints, and other factors that affect the design; (2) Relate the ADR and the software architecture structural models with a model of system solution strategies (SSS), which provides solution information rather than articulating the problem as does the ADR; (3) Guide the architect in using the SSS in developing the software architecture, by which the results of the activity should be documented, fundamentally by capturing where SSS are used in the architecture models and why; and (4) Support the remaining elements of the software development process, whereby the activities surrounding the ADR and SSS can and should have impact on further software development.

Hofmeister, et al. (2005) discovered that what was missing from the Siemens Four Views design approach, which stemmed from earlier studies of software architecture in industrial systems, was information regarding the context and rationale the decisions embodied in the diagrams that conveyed the structural information and text that described the diagrams. Thus their design approach consisted of two basic parts: (1) To design and describe the structure of the system by using the four complementary views (consisting of conceptual, module, execution and code architecture) to minimize the complexity of designing and comprehending the architecture; and (2) To use Global Analysis to describe the context and rationale for design decisions as a byproduct of its documentation artifacts. The bulk of Global Analysis was performed before the architecture view design but was revisited when new information came to light. Equally important was the fact that Global Analysis occur prior to the architecture view designs so that it could be applied iteratively between view designs.

Through Global Analysis, a set of organizational, technological, and product factors were developed along with Issue Cards, which, along with their associated activities, assist the architect in identifying key design problems that arise from these factors, and identifying suitable solutions. Thus, Issue Cards are a means of relating design problems, their influencing factors, and their associated relevance to the problem.

What Hofmeister, et al. (2005) ultimately learned from the Global Analysis experience was that it played an integral part in architecture design. Furthermore, Global Analysis helped the architect to focus on key design problems, communicate these to the stakeholders, obtain consensus on architecture challenges, support architecture evaluation, and record the architecture rationale for use by software developers. Moreover, Global Analysis was not always used in the iterative way that it was intended, and it was sometimes used by project managers to identify technical and schedule risks to be managed, planning releases, scheduling dependencies, and the development of managerial strategies. And, finally, Hofmeister, et al. concluded that Global Analysis was a good means of capturing what good software architects are already accomplishing and provides input into better ways of doing it as well as assisting the architect in making the conceptual leap from requirements to design through the analysis of the impact of requirements on important technical and business issues that impact the design.

Hofmeister, et al. (2005) reiterates and reinforces the process of performing requirements determination in the analysis phase of the systems development life cycle (SDLC) as described by Hoffer, George, and Valacich (2011), which consists of the phases of Planning, Analysis, Design, Implementation, and Maintenance (PADIM). The description of the use of Global Analysis by Hofmeister, et al. offers a viable means of bridging the gap from the requirements determination in the Analysis phase to the Design phase of the SDLC by the design architects by minimizing its complexity. As a result of the use of Global Analysis by Hofmeister, et al., and the demonstration by them that this analysis technique offers unique benefits to bridging the gap between requirements and design, the Hofmeister, et al. article has scholarly merit and worth to current and future software designer practitioners and scholars. The Hofmeister, et al. (2005) article was chosen based on the fact that the title was intriguing to this author, and prompted further investigation into its validity and credibility in the area of software architectural design and the potential relationships the article has to software requirements and design vis´-a-vis´ our current course textbook.

References:

Hoffer, J., George, J., & Valacich, J. (2011). Modern Systems Analysis and Design (6 ed.). Upper Saddle River, New Jersey: Prentice Hall.

Hofmeister, C., Nord, R., & Soni, D. (2005). Global analysis: Moving from software requirements specifications to structural views of the software architecture. IEE Proceedings – Software, 152(4),  187-197. doi: 10.1049/ip-sen:20045052.

Wikio
Wikio
Tagged with: • •
 
1 Comments
Please Leave A Response

Offshore Outsourcing the Programming Work

On 03.04.10, In Programming, software, By dancalloway

by DAN CALLOWAY
Published 3 March 2010

THE UNITED STATES – Offshore outsourcing (or offshoring) is defined as the relocation of business functions and structures to third-parties in lower-wage countries outside of the United States for the purposes of taking advantage of cost savings that can be realized (Sauer, 2005). Although the primary motivation for outsourcing programming projects is to take advantage of cost savings realized through lower-cost labor, another motivator for doing so is the flexibility and concentration on a corporation’s core business through the employment of skilled programmers where the talent available offshore is not as readily available domestically (Sauer). Therefore, to summarize, offshore outsourcing of programming work is typically accomplished for two reasons: (1) To reduce the cost of the programming project by hiring programmers in foreign countries, such as India, who are willing to work for less money, and (2) To acquire programming skills available in bigger job markets by including those countries outside the United States for specific skills that may not be available within the boundaries of the United States (Sauer).

Two methods of programming are the agile methods of XP (Extreme Programming) and ASD (Agile Software Development) (Kobayashi, Kawabata, Sakai, & Parkinson, 2006; Lindstrom & Jeffries, 2004). Kobayashi, et al. primarily discussed the agile method of XP through two case studies they introduced involving a selection from 13 XP practices gathered from interviews with developers. The goal of these practices was to define how to select the correct practices based on the programming scenario the reader might encounter. On the other hand, Lindstrom, et al. introduced the principles of the agile manifesto and tabulated several agile methodologies, including the agile method of XP but also included in his discussion the agile method known as ASD. Lindstrom, et al. sees especially XP as a means of solving many of the problems—in larger software development projects—that seem to haunt those projects, and offers an evaluation of the approaches used in XP as well as the underlying values of XP.

Using the agile practices of XP and of ASD constitute a means, especially with XP, to solve many of the software development issues encountered in offshoring because agile practices avoid upfront design, emphasize flexibility, a concentration on rules and documentation, and developing voluminous documentation found in other software development methods (Sauer, 2005). If offshoring, in this instance, could be accomplished, then it would be able to take advantage of cost savings (outsourcing) and the advantage of flexibility (agility) found in a larger market outside of the U.S. However, some issues with offshoring are found in the very principles of agile practices, which rely heavily on communication and feedback, and which requires a team of programmers who are collocated with one another and who have the ability to collaborate with the customer (Sauer).

Sauer (2005) has taken the initiative to analyze published experiences of AO – agile offshoring (agile practices applied to offshore projects), AGSD – agile global software development (agile practices used in globally dispersed software development), and DEP – distributed extreme programming (XP is used as the core agile process model). AO emphasizes the relationship and communication between unequally ranked teams and remote customers, AGSD emphasizes the geographical aspects of cultural and ideological differences, and DEP emphasizes the dispersement of teams, which have a direct effect on communications and coordination (Sauer).

Organizations should expect offshore firms to have competencies in ASD. However, the challenges that Sauer (2005) determined in their analysis of software offshoring that might adversely impact the effective use of ASD can be classified into four categories: (1) Individuals and interactions, (2) Working software, (3) Customer collaboration, and (4) Responding to change. Within the first category, communication is the main issue with offshoring since offshoring does not allow team members to sit together, collaborate with other team members, and resolve issues on a timely basis when they arise. Hindrances in communication often lead to the spreading of informal news, the lowering of team spirit, lack of common knowledge, and a departure from the shared vision of the team. As for the second category, offshoring has increased demands in the infrastructure and invariably this offshoring will lead to integration issues, issues with the testing of software, problems in quality assurance conformity, and issues with software configuration where something that works on one platform in the US may not work on another platform outside of the US. Customer collaboration is a necessity in agile software development where the programming team interacts with the customer quite frequently on requirements engineering and iterations of software development. Offshoring makes this next to impossible since the customer is often geographically distant from the team and the customer is unwilling or unable to send representatives to the offshore location. And, finally, a distributed team, as would be found when offshoring, can lead to problems with a host of project management issues. Among these are: (1) Progress estimation, where the project status is less visible and controllable; (2) Estimating efforts, where the developers not managers should be making these decisions but often the developers are not able to attend planning meetings, or on-site and offshore developers create diverging opinions about the amount of time and effort needed; and (3) Division of work is hampered in a geographically dispersed setting since offshore developers are typically less experienced in the application domain, especially in the beginning of the project, and must be constantly updated to continually involve them in the project so more and more tasks can be transferred offshore where cost savings can be realized.

Therefore, the agile practices of pair-programming, customer on-site, and planning game for extreme programming are directly impacted by offshoring (Sauer, 2005). Although these agile practices are adversely affected, Sauer suggests that if properly adapted and enhanced, they will continue to work in offshoring environments. The main issue with offshoring is the restricted communication between on-site and offshore teams and between offshore developers and the customer, and this is extremely important since communication and regular feedback form the basis for agility. The solutions to these issues are found in the substitution of communication through the technical means of video conferencing, telephone calls, and instant messaging, further supplemented by an occasional exchange of team members. Sauer has performed a case study which they believe will show that although technical substitution may be a solution at a higher cost, and, thus, may indicate that it is only affordable in larger projects, smaller teams can take advantage of offshoring in agile ways by avoiding the initial and running costs, and overhead by employing established practices and tools of software engineering to formalize and structure agile offshoring without losing the flexibility of agile practices.

References:

Kobayashi, O., Kawabata, M., Sakai, M., & Parkinson, E. (2006). Analysis of the interaction between practices for introducing XP effectively. In Proceedings of the 28th international conference on software engineering (pp. 544-550). Presented at the Far east experience papers: development technique, Shanghai, China: ACM. Retrieved March 3, 2010, from http://portal.acm.org.library.capella.edu/citation.cfm?doid=1134285.1134361.

Lindstrom, L., & Jeffries, R. (2004). Extreme Programming and Agile Software Development Methodologies. Information Systems Management, 21(3), 41-60.

Sauer, J. (2005). Agile Practices in Offshore Outsourcing – An Analysis of Published Experiences. ECSCW 2005 Instructions. Retrieved March 3, 2010, from http://74.125.155.132/scholar?q=cache:_lkLfiz5n7cJ:scholar.google.com/+offshore+outsourcing+of+programming+and+agile+practices&hl=en&as_sdt=40000000001.

Wikio
Wikio
Tagged with: • • • • •
 
4 Comments
Please Leave A Response

« Previous Entries
Go To Top »
Get Adobe Flash playerPlugin by wpburn.com wordpress themes

SEO Powered by Platinum SEO from Techblissonline