References: (Annotated Bibliography)
Adams, E. Biggest Information Security Mistakes that Organizations Make: and How to Avoid Making Them, ISSA. Retrieved June 12, 2008 from: http://www.issa.org/Downloads/Whitepapers/Biggest-Information-Security-Mistakes_Security-Innovation.pdf
This article discusses the importance of working to improve software development to prevent some of the application based weakness. The author states that by using commonly used techniques used in many other professions, software developers could ensure their products are fail proof as possible. He also states that IT professionals place too much faith in networks, new software, people, get their attention diverted to the latest problem and they believe that ‘good’ software is too expensive.
Bose, I. (2006). Jharna software: the move to agile methods, Asia Case Research Center. Retrieved from Harvard Business School, HKU613P2.
This case study describes the advent of software development in India. It specifically follows Jharna (translated ‘Waterfall’) Software from inception to where they were forced to make a decision about what method of project management they would use to develop their software. They began with the ‘Waterfall’ method and felt customer pressure to change to a more Agile approach. There were many reasons to support the change as well as rational how it may be detrimental to make the change. Some of these reasons include having to change the culture and loosing documentation and formalization of the design process, all of which were seen as a foundation in the success of Jharna Software.
Danube (2004). An introduction to agile software development. Danube Technologies, Inc. Retrieved July 4, 2008 from: http://www.danube.com/docs/Intro_to_Agile.pdf
This case was a marketing document written to extol the benefits of agile software development as opposed to the traditional ‘waterfall’ method. Danube presented a very one sided approach to software development but failed to answer some critical questions from ‘Agile’ critics. How do they document software? Where is development happening? How does Danube ensure they are communicating clearly the changes needed and the processes for recording changes and modifications to the requirement planning stages?
de la Brassinne, P (2002). Web Application Security for managers. SANS Institute retrieved June 14, 2008 from: http://www.sans.org/reading_room/whitepapers/application/27.php
This article talks about the possible ways web based applications may be put in jeopardy while staying within the allowances of the Firewall and SSL. In addition to showing how some programs (or parts of programs) may be exploited, he gives ways to mitigate possible attacks with simple solutions. This paper points out the importance of having quality software from development through testing and implementation. Software is the most common area of weakness for security.
DeLone, W.H., and McLean, E.R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9-30.
This paper is an update from their previous paper in which they tried to find common ground between all the different studies that had been done prior to 1983. They tried to look at all the works and find commonalities that could be used to compare the results. This work was a milestone in effectiveness measuring for IS. DeLone and McLean were pioneers in the field of making research usable as means to understanding IS and its impact of success of organizations and the people who use them.
Dowlatshahi, S. (2005). Strategic success factors in enterprise resource-planning design and implementation: a case study approach. International Journal of Production Research, 43(18), 3745-3771.
This paper is focused on the implementation and strategy needed to design or select an ERP system. Dowlatshahi did extensive research on other research that had been published and saw a gap in content. An effort was made to clearly point out the important aspects of the implementation process that are most affective in creating a successful product. He based his study on other research papers and two case studies that demonstrate his points well. One of the case studies was focused on a service based governmental agency and the other was a new manufacturing facility. The author makes four ‘factors’ and breaks them into further detail with the ‘subfactors’.
Feurer, R., Chaharbaghi, K., Weber, M., & Wargin, J. (2000). Aligning strategies, processes, and IT: A case study. Information Systems Management, 17(1), 23-34.
This article discusses the use of process implementation at HP on a “greenfield” operation for another company. They were able to utilize the differences in perspective from many different cross-functional groups within the organization. By using the overall strategy of the company and evaluating all the needs, they were able to save money by utilizing existing technology for most of the operations but developing new software in situations where the strategic gains would be worth the expense. They were also able to evaluate where integration could happen using outside consultants and contractors to do non “core” activities.
FreeBSD.com, Firewall Concepts. Retrieved June 18, 2008 from: http://www.freebsd.org/doc/en/books/handbook/firewalls-concepts.html
This short article gives the general operating procedure for firewalls. It compares and contrasts the different types of firewall rulesets: exclusive and inclusive. Exclusive rules allow all traffic through as long as it does not meet the criteria. Inclusive only allows traffic through that matches the criteria. The third kind mentioned is stateful rulesets, which has some potential errors of Denial of Service. It is possible to use a smattering of each type of ruleset to get the desired security.
Frye, C. (2008). Agile practitioners face challenges but see process improvements. Software Quality News. Retrieved July 5, 2008 from: http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1318820,00.html#
This is a news article talking about a survey of improvements in the face of challenges that plague ‘Agile’ software development. This article did a great job of showing how improvements were classified and where the drawbacks were still lurking. Many articles only show one side of the story so it is important to gather the facts from all sides. One of the points that could have been included is how each customer classified the feedback. For example one of the questions referred to meeting expectations with the ‘Agile’ method versus traditional methodologies. Did the customer give an off the cuff answer or did they actually compare data? Sometimes, if data is not used, “the grass is always greener” syndrome prevails.
Johnson, S. J. (2002). ERP: payoffs and pitfalls, Harvard Business School: working knowledge for business leaders. Retrieved July 6, 2008 from: http://hbswk.hbs.edu/archive/3141.html
This interview with post graduate student Mark Cotteleer, describes the research that he has been working on that finds the best ways to implement ERP systems. System integration is never easy or painless but can be successful if done properly. He pointed to many companies that look at their implementation as successful despite the failures of some high profile failures at companies such as Nike, Hersey’s and others. He gives some suggestions on how to ensure success with step by step simplicity.
Kemp, S. (2004). Project management demystified. New York: McGraw Hill.
This book is an excellent overview of Project Management. It is very self explanatory and has many useful templates and strategies. It is not meant to be an all inclusive step by step guide, but more of a general understanding of what project management does and its’ generally accepted rules. It is a great first look at Project Management with many great side notes for a quick understanding.
Mcaffe, A. F. (2006a). Pharmacy Service Improvement at CVS (A) Harvard Business School. 9-606-015.
This paper describes how one group of executives set out to fix some of the process problems that were facing CVS Pharmacy. Customers were unhappy and many ways to improve the process of filling prescriptions were identified. The order was changed to a more logical one in which customers would be able to provide feedback while still in the pharmacy. Pharmacists were very concerned about safety and quality so those were place on the forefront of each person’s mind. Although many processes were rearranged the IS did not get modified to a point that was worth mentioning.
Mcaffe, A. F. (2006b). Pharmacy service improvement at CVS (B). Harvard Business School. 9-606-029.
This article is a follow-up on the previous article by the same name. All processes were improved and set up to provide superior customer service. Reduced wait times and better communication about problems with prescriptions before customers were ready to pick up were two of the focus areas. Implementation was brought out slowly to reduce down time and get specialists at implementing the system.
Nickols, F. (2006). Change management: a primer. Distance Consulting. Retrieved June 24, 2008 from: http://home.att.net/~nickols/change.htm
This article gives the basics for change management. It gives definitions for what is understood as “change management” from many perspectives. The purpose of this paper was to provide a broad overview of the concept of “change management.” It was written primarily for people who are coming to grips with change management problems for the first time and for more experienced people who wish to reflect upon their experience in a structured way.
Realsoftwaredevelopment.com (2007). One minute software development manager. Real World Software Development. Retrieved July 1, 2008 form: http://www.realsoftwaredevelopment.com/2007/08/the-one-minute-.html
This article gives a great overview of how to be a good software development manager. It gives practical ideas on how to act, what to say, what to do, when to do it and what not to do in a concise format. This would be a great source for anyone who is considering leading any kind of team. Some of the best insight is to provide clear vision for all team members so that everyone can be successful and be working to the same goals.
Rehman and Paul (2003) The Linux Development Platform: Configuring, Using, and Maintaining a Complete Programming Environment. Pearson Education Retrieved June 30, 2008 from http://www.faqs.org/docs/ldev/0130091154_4.htm
The first chapter of this online book describes the high level view of software development. It starts out with collecting the requirements and establishing if it is an acceptable business model. Then it moves into defining all the attributes from how different parts will communicate to rights and proprieties. Once these are established coding and minor testing are started. People other than the coders do the testing to show any weakness and if there are any identified they are fixed. The last phase is product support which can include adding features or fixing bugs that were found by customers.
Rettig, C. (2007). The trouble with enterprise software, MIT Sloan Management Review. 49 (1) SMR259.
This article takes a fairly negative approach to the success of ERP systems. The author points out many of the negative aspects of ERP and where most problems come from. It is interesting to note that all the problems do not stem from the software but from customizations and data problems as they travel through the system. Some future advantages include Service Oriented Architecture (SOA) which the author has very little expectation that it will make improvements significant enough to solve the problems associated with ERP.
Robey, D., Ross, J.W., & Boudreau, M. (2002). Learning to implement enterprise systems: An exploratory study of the dialectics of change. Journal of Management Information Systems, 19(1), 17-46.
This paper is a comparison of the experience of implementing an enterprise resource management (ERP) system in 13 companies. It discusses some of the difficulties had and how they were overcome by some of the companies that experienced success in those areas. It also showed what was accomplished without much trouble where divers training methods were used to ensure smooth integration. All companies showed positive and negative effects after the implementations but were still trying to understand what the long term effects would be and how long it would take to become fully integrated.
Serena (2007). An introduction to agile software development. Serena Software, Inc. Retrieved July 4, 2008 form: http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf
This paper was a marketing document produced by Serena to show the advantages of ‘Agile’ methods they use. It is a one sided document that aims to prove why the ‘Agile’ methods are superior to any others. Serena touts improvements in time and accuracy as the main benefits of their development process. Some of the topics that were not discussed are how they document the software to ensure good post release support to their customers and how Serena can communicate clearly with customers to ensure proper requirements are transmitted.
Straw, E (2008). Measuring Information System’s Effectiveness. Retrieved July 11, 2008 from http://converge.corban.edu/file.php/1764/Measuring_IS_Effectivness.pdf
This paper looks at the problem associated with Information System Effectiveness measurement. Straw effectively uses user satisfaction as the metric to identify effectiveness. The tool being used is called UPISE (User Perceived Information System Effectiveness) which is based on the McLean and DeLeone model. The UPISE model looks at Net Benefits, System Quality, Information Quality and Service Quality from the perspective of the users and uses their responses to determine IS’s effectiveness.
Wailgum, T. (2008). ABC: an introduction to ERP; getting started with enterprise resource planning, CIO. Retrieved July 6, 2008 from: http://www.cio.com/article/40323/ABC_An_Introduction_to_ERP/1#erp
This article answers many questions about ERP systems that range from “what is ERP?” to “why do so many implementations fail?” It seems to give a fair approach to both sides of the argument including the ERP developer and the end users. Some of the problems associated with ERP stem from individualization of off the shelf products. Other problems mentioned are associated with people having to do work that they are not prepared for; suddenly the sales rep must answer all the questions for customers and trust the ‘system’.
Young PhD, R (2002). Recommended requirements gathering practices. Crosstalk: journal of defense software engineering. Retrieved July 1, 2008 from: http://www.stsc.hill.af.mil/crosstalk/2002/04/young.html
This article was written by a IT professional at Northrop Grumman Information Technology and give insight into how to collect information to create good specifications for what a software application should provide to its customers. There are many examples of how to gather the requirements including some emotion based questioning and other non-traditional approaches. It also provides good technical knowledge on what to include and exclude while developing requirements.
Posts
