by DAN CALLOWAY
Publlished 7 March 2010

UNITED STATES – The networking needs of XYZ Corporation have changed significantly over the last five years. As the IT manager, it is imperative that the approach I recommend to management for upgrading the network—not just for the sake of improving applications that run on it, but taking into account the aspects of improving the network from a hardware and software (protocol) perspective—be taken that will ensure a reliable, scalable, and efficient network that will not only meet the requirements—now but five years from now—of the business sector and its partners (stakeholders) in the organization who will likely need to remotely connect to the network, but which will be acceptable to everyone and that can be accomplished with the least effort and most economical means.

The approach that is often taken when upgrading a corporate network, like XYZ Corporation, is to rush into the upgrade by adding network devices of differing quality from various vendors as well as software applications in the same manner because the hardware and software is the latest and greatest on the market and does exactly what the business office wants to implement and use. This is the wrong approach because the business office and management lose sight of the fact that a lot of planning goes into upgrading a network from a hardware/software and services perspective. If the former approach is taken, then most likely at some point, the network will no longer be able to support the services needed for the business factions or the network traffic generated by the users. When the network fails, then, undoubtedly, management will look to point blame on IT for not ensuring the upgrade was successful in the first place and, in all likelihood, will seek outside assistance (an ISP or managed service) in giving advice and correcting the issue, which will be costly and will adversely affect IT’s credibility in the organization.

The approach that I would recommend to management after reviewing the corporate strategic goals and current and projected mission statements of the company would be to: (1) Confer with my department on the goals the company wanted to meet and where it was heading in the next five to ten years, and elicit from them their expert recommendations for the necessary hardware and software that would be required to achieve those goals; (2) Have an onsite technician perform a site survey of the network, documenting the physical layout of the current network from a hardware standpoint, and the applications that currently run on the network as a starting point for the upgrade project; (3) Ensure the site survey collected information on the current business plans and projected growth of the company, number of users and types of equipment needed, current Internet connectivity, what applications the network needs to support, what new services will be required now and in the future, what the security and privacy requirements are now and in the future, what the wireless network requirements (wireless or a mix of wired and wireless) are, what the reliability and uptime expectations of the new network are, and what are the budget constraints; (4) Request a formal written proposal from a prospective ISP on the requirements for and the costs associated with supporting the backbone for the network; (5) Develop a SWOT (strengths, weaknesses, opportunities, and threats) analysis of the upgrade plan; and (6) Report the findings of the site survey, written proposal of the ISP, results of the SWOT analysis, and documented proposal for the network upgrade to management for their approval. Following the approval from management, I would execute the network upgrade in five phases: (1) Requirements gathering, (2) Selection, design, and purchasing of equipment and applications, (3) Implementation of the upgrade, (4) Operation in a live environment, and (5) Review and evaluate the new network (hardware/software applications) against the original design plans to see if they are a match (“The Technology Upgrade Planning Guide,” 2010).

I would not foresee any major obstacles to implementing the network upgrade if all of the steps outlined above are executed properly and there is complete and upfront communications between the IT department and the business factions/management during all phases of requirements gathering, design selection, implementation, operation, and review.

——————————

References:

The Technology Upgrade Planning Guide. (2010). The Technology Upgrade Planning Guide. Retrieved March 8, 2010, from http://www.thebrookfieldgroup.com/news_story32.php.

Tagged with:
 

by DAN CALLOWAY
Published 7 March 2010

WEAVERVILLE, NC – Dean Sanders, the Computer Science and Information Systems chair at Northwest Missouri State University in Maryville, Missouri asked the students to evaluate the use of Extreme Programming for a project that was to be conducted in the undergraduate computer science curriculum and to write opinion papers on the subject (Sanders, 2002). The majority of the students were opposed to the use of XP as the preferred life-cycle model for the project, but did support the introduction of some of the practices of XP for selected courses. Among these acceptable practices were unit testing and coding standards for introductory classes. The students, however, felt that other practices should be deferred to project-specific courses.

As a means of corroborating the opinions of the students, Sanders (2002) conducted two pilot studies: one on pair programming and one on Extreme Programming. The reasons for these pilot studies were to develop substantiative experience to support the opinions of the students and to evaluate the literature on pair programming and agile methods to see where they fit into a typical undergraduate computer science curriculum.

The Pair Programming pilot study (Sanders, 2002) was conducted in the Summer semester of 2001. The course selected for the study was a Data and File Structures course consisting of a small group of individuals with mixed ethnicity and diversity among family obligations, gender, age, job schedules, and grade point averages who were felt to be ideal for the study. In general, the results of this pilot study revealed that most of the students were enthusiastic about the concept of pair programming and felt that they had learned quite a bit about working in pairs, communicating with one another on the project, and felt that this experience had been a rewarding one. One surprising result of the study, however, was that early on in the course, the majority of the students felt that the introduction of pair programming in the Data and File Structures course was very useful, but by the end of the course, most students had changed their minds as a result of the stronger students constantly having to explain concepts to the weaker ones, and felt that this practice should be delayed to a later course rather than being an introductory one.

The Extreme Programming pilot study (Sanders, 2002) was conducted in the Fall semester of 2001 where one project was selected as an XP pilot project to develop a teaching/learning environment for students in an introductory programming course. This particular project was selected for three reasons: (1) the instructor would be playing the role of the client, (2) the project was large enough to instill interest among students, and (3) the project could tolerate a lack of progress. The project, codenamed Jeroo, when completed, would allow students to control the movements of an animated character by writing programs in a Java-like language. The completed project would include a GUI, an animation plane, a source-code editor, a graphical environment editor, a lexical analyzer, a parser, a compiler, an interpretor, and a run-time module. A team consisting of six students all of whom had a demonstrated history of producing excellent work, were asked to conduct further research into XP practices and were asked how they would adapt those practices to the Jeroo project. Releases of the software client were developed about every three weeks. The team reported they attempted to follow the principles of simple design but time constraints made refactoring extremely difficult. Testing during the project did occur, but did not follow the prescribed practice of Extreme Programming. Students reported the most successful aspects regarding the use of pair programming and XP were the stand-up meetings, the variation on pair programming, and the use of CVS. The majority of the students felt that XP kept their morale high, but they did not deem XP suitable for all teams or projects, recommending that a subset of XP be used in future projects.

As a result of the student evaluations and pilot studies, Sanders (2002) made six recommendations for the use of pair programming and XP in an undergraduate curriculum: (1) ensure the introduction of XP does not conflict with broader educational objectives; (2) teach XP or agile methods in an introductory computer science course but be cautious about using either in introductory course projects; (3) an appropriately modified version of XP practices can be used on some projects and some teams; (4) a topics course is the most appropriate place to practice agile methods; (5) some of the practices of XP can be distributed among selected courses as enhancements or revisions of current practices; and (6) pair programming is most effective when students have developed individual skills, when members of team pairs have equitable skill levels, and the course includes regularly scheduled lab sessions.

The results of Sanders (2002) are consistent with the findings of (Kobayashi, Kawabata, Sakai, & Parkinson, 2006) in the use of the whole team concept in which all the players involved in XP projects are gathered together to work as a team, the planning game and short releases concept in which developers and customers make plans for short releases and iterations of software development, clearly identifying the role each plays, and the pair programming concept where teams work in pairs at a single computer when developing the software. Kobayashi, et al., recommends the introduction of selected practices of XP in projects, which is also consistent with the findings and recommendations of Sanders (2002) in the XP pilot study.

—————–

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 eas experience papers: development technique, Shanghai, China: ACM. Retrieved March 3, 2010, from http://portal.acm.org.library.capella.edu/citation.cfm?doid=1134285.1134361.

Sanders, D. (2002). Extreme Programming: The student view. Computer Science Education, 12(3), 235-250.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes

SEO Powered by Platinum SEO from Techblissonline