Printer Friendly

A return to programming--teaching a first programming course for senior level IT students.

INTRODUCTION

Information Technology (IT) experts agree that students in IT related major(s) need to take at least one programming course as part of their curriculum (Bills &Biles, 2005; Kaplan, 2010; Malan &Halland, 2004). Different standard curriculums that are developed to suggest content for IT related programs agree with this notion and provide suggestions for teaching programming courses in all IT programs (Bills and Biles, 2005).

In most IT programs, teaching programming starts at the first or second year of the student curriculum, with most students taking what is termed as a first or beginner level programming course that works as a pre-requisite to other programming courses. It is not often that a first programming course is taught at a junior or senior level. Instead, most IT students acquire the knowledge of at least one programming course by the time they get to their junior or senior year.

An IT faculty member at a university in Western Pennsylvania faced a unique situation regarding the teaching of a programming course. This faculty member had to teach all three senior level courses in this IT program. He realized that the senior students in this IT program had not taken any programming courses by the time they had registered to take his courses. This IT program does not require their students to take any programming courses. After more research, this faculty member concluded that it would be best for the students to learn a programming language before graduation. Thus, he decided to teach a first programming course for this group of students in this IT program. The experience of this faculty member and the results of his research regarding the selection of content for first level programming for senior level students is illustrated in this paper.

The remainder of this paper is divided into the following five sections: in the first section, advantages and disadvantages of teaching programming to IT majors is explained. This explanation contributes to deciding whether or not to teach a programming course. The second section elaborates on the selection of the programming language. The third section discusses the different methodologies of programming. The fourth section explains the examples and cases that are given in such a programming course. The fifth and last section explains in detail the experience of this faculty member and what he decided based on the research he conducted on the content, methods, and coverage for this unique course. A summary and suggested future research is introduced at the end.

TO TEACH OR NOT TO TEACH PROGRAMMING

It has long been agreed in the IT industry that teaching programming is a must for all IT majors (Bills & Biles, 2005; Kaplan, 2010). However, the depth at which programming is taught to IT students is not agreed on. Advocates of teaching programming point to different advantages that students can gain from having exposure to programming fundamentals and practices. But, more recently, there have been calls from different academics to limit the teaching of programming for IT majors. This group points to different drawbacks from teaching programming courses. These drawbacks can extend to affecting the students and the department that teaches it. The newer move for IT is to consider it as a "programming less" major (Bills & Canosa, 2007). The remainder of this section elaborates on the two points of view on whether or not to teach programming to IT students.

To Teach Programming

Advocates of teaching programming in IT programs point first and foremost to the standard curriculum that has been developed to outline coverage areas and suggest courses for each of the different IT programs in general. The Association of Computing Machinery, along with other reputable technology organizations, has published different versions of these standard curriculums for IT programs. The most relevant versions of standard curriculum in this regard are the following two:

1--Computing Curricula 2005 the overview report (CC2005).

2--Information Technology 2008 Curriculum Guidelines for Undergraduate Degree Programs in Information

Technology (IT2008).

The first repot is general and suggests coverage areas for five technology programs: Computer Engineering (CE), Computer Science (CS), Information Systems (IS), Information Technology (IT), and Software Engineering (SE). IT2008, on the other hand, is specific to the Information Technology discipline and offers detailed suggestions for courses and coverage areas for the different courses in this program. Not surprisingly, both reports suggest teaching programming in the IT programs. Table 1 below contains the suggested coverage area for programming topics for the five programs listed in CC2005. The coverage areas range from zero to five with zero receiving no coverage and 5 receiving the maximum coverage.

A quick look at the table above reveals that CC2005 suggests coverage for IT majors in the programming fundamental equal to the coverage received in IS (minimum 2 and maximum 4). It suggests more coverage in the area of Integrative programming (2 to 4 for IS while 3 to five for IT).

The IT2008 standard curriculum, on the other hand, identified 13 topics in what they term as "Information Technology Body of Knowledge." This "Body of Knowledge" lists information areas that graduates of IT programs need to have. The IT body of knowledge suggests also a number of core hours for each of the 13 areas, as well as the total hours for the entire 13 areas.

Among these 13 areas suggested in the body of knowledge, two are directly related to programming: First, PF programming Fundamentals with 38 suggested core hours for coverage and the second is IPT Integrative Programming and Technologies and suggests 23 core hours for this coverage. Other items in the body of knowledge contain some programming topics like those listed in IM (Information Management) and WS web systems and technologies plus SIA (System Integration and Maintenance). The points established that in both CC2005 and IT2008 suggest the teaching programming courses to IT students at substantial coverage that extends to more than one course.

Beside what is listed in the standard curriculum, IT experts consider that learning to program goes into the identity of people working in Information Technology and the education of Information Technology. It defines their basic core of knowledge in this field. Kaplan (2006) noted that
   Today, among other challenges, teaching students how to write
   computer programs for the first time can be an important criterion
   for whether students in computing will remain in their program of
   study, i.e. Computer Science or Information Technology. Not
   learning to program a computer as a computer scientist or
   information technologist can be compared to a mathematician not
   learning algebra. (p. 163)


To Not Teach Programming

There are numerous factors that stand against teaching programming courses in general, and some of these factors may influence the teaching of programming even to IT majors. These factors stem from the difficulties that accompany learning to program and also from the perceptions about the programming profession in general and programming courses in particular. These two factors have more implications on enrollment in the related programs and the perception of the students about the program.

Learning to program is considered a difficult task for many (Ali, 2009; Baldwin & Kulijas, 2001; Carter & Jenkins, 2002; Dan, Cooper, &Pauch, 2008; Kellher & Pausch, 2005). This kind of difficulty has been attributed by many experts in the field of computing as a primary reason for the decline of enrollment in computer technology programs (Lahtinen, Ala- Mutka, & Jarvinen, 2005). The decline of enrollment extends to including lower admission rates to computer programs, but more noticeably the decline extends to attrition among existing students. In other words, computer programs accept a good number of students but most of the accepted students do not complete the program; instead they transfer to other programs or simply drop out of the program completely.

This kind of enrollment decline is more noticeable after the students take their first programming course. To verify this, a study conducted by Carter and Jenkins (2002) estimated that between 25 to 80 percent of students who drop their first computer classes do so due to the difficulties they face in learning to program . So with this kind of difficulty faced by students and with these numbers that show students dropping out of the program, there are many points that suggest not teaching programming.

As well, different old practices of teaching programming contribute to a different public perception of programming. There is a common general perception that computer programming in general and programming courses in particular contributes to a general asocial environment among students and forces students into isolation. Teague and Roe (2008) noted the following about programming:
   Programming is often perceived as a solitary occupation, one which
   is conducted in a competitive, rather than collaborative
   environment. This is often reinforced at universities where
   introductory programming subjects' assessment consist of individual
   assignments ... Programming is seen as a competitive occupation
   whose model student is the stereotypical 'geeky' young male, and
   this can lead initially to alienation, diminution of confidence and
   subsequent lack of interest for women. (p. 148)


To put it in a nutshell, there are perceptions that advocate a "programming less" environment for some IT majors (Bills & Biles, 2006). The current trend of enrollment decline among computer centric programs adds fuel to their calls. At a time of shrinking budgets, enrollment decline, and emphasis on student evaluations for assessing faculty performance, the faculty introducing such a programming course may stand at odds against others who advocate the exclusion of programming courses in an IT curriculum.

SELECTING THE PROGRAMMING LANGUAGE

During the earlier days of teaching programming, the selection of a programming language to teach was in most cases a straight forward task. At the beginning, there were only a few languages to select from and most had specific defined purposes and suggested uses. BASIC, for example, was used for beginner level programming, FORTRAN was used in science applications and thus introduced in science programs, and COBOL was used in business applications and thus was taught in MIS or business programs. There are variations of teaching other programming languages, but these three remained dominant for a number of years.

The recent years have shown a significant increase in the number of programming languages. Kaplan (2010), for example, noted that there are between 2000-3000 known programming languages these days. So the number of programming languages to select from for teaching is not limited to a few as in the past. Added to that, all newer versions of programming languages are capable of handling any kind of applications they are used for. Hence, it hardly can be found that a particular programming language cannot handle any application. It seems all programming languages can handle all applications, whether used in business, scientific, or any other general applications.

To complicate the issue further, there is a breed of newer programming languages that has been developed. These languages are called "Beginner Programming Languages" or "Introductory Programming Languages" (Kelleher & Pausch, 2005) and are designed to make it easier to learn programming concepts and methodology. These beginner programming languages are designed to overcome the difficulties of learning to program for many students and are increasing in number and in their uses at various levels of academia (Dann, Cooper, & Pauch, 2006).

This kind of increase has created many factors that are taken into consideration when selecting a programming language to teach in the classroom. Parker et al. (2006), for example, compiled thirteen factors that influence the decisions to select a particular programming language for a first programming course. Table 1 lists the factors compiled by Parker et al.

The list shown in figure 1 below shows the extent and complexity of factors influencing the decision to select a programming language to teach. Some of these factors are directly related to the course and the institution, while others include external factors such as the related technologies and the marketability of the language for students to acquire.

In academia, there seems to be three programming languages that are taking the lead in the classrooms: Java, C++, and Visual Basic. Each has its own advantages and drawbacks. The advantages and drawbacks can extend to the selection of a language for a particular major (for example, IS vs CS or IT). Java, for example, is known to some for being difficult due to its long list of syntactical conditions and brief error messages (Blake, 2011). Visual Basic, on the other hand, is known for it simple use of structures and the division of a simple program into multiple modules.

SELECTING A PROGRAMMING MODEL

In programming, there are three approaches to learning to program. These three approaches are termed "Programming Models" and include Procedural, Object Oriented, and Event Driven programming.

In the procedural approach, a program is divided into procedures that are loosely linked and connected to a main program to complete a certain task or to solve a certain problem. In such an approach, the program specifies the sequence of procedures (modules) to be executed. That is, the program specifies the steps to be followed and the procedures to be executed for each step (Bradley & Millspaugh, 2010).
FIGURE 1

Factors Influencing the Selection of a Programming Language

Reasonable Financial Cost
Availability of Student/Academic Version
Academic Acceptance
Availability of Textbooks
Stage m Life Cycle
Industry Acceptance
Marketability (Regional and National)
System Requirements of Student/Academic/Full Version
Operating System Dependence
Proprietary-Open Source
Development Environment
Debugging Facilities
Ease of Learning Fundamental Concepts
Support for Secure Code
Advanced Features for Subsequent Programming Courses
Scripting or Full-Featured Language
Support of Web Development
Supports Target Application Domain
Teaching Approach Support
Object-Oriented Support
Availability of Support
Instructor and Staff Training
Anticipated Experience Level for Incoming Students


In the procedural approach, a program is divided into procedures that are loosely linked and connected to a main program to complete a certain task or to solve a certain problem. In such an approach, the program specifies the sequence of procedures (modules) to be executed. That is, the program specifies the steps to be followed and the procedures to be executed for each step (Bradley & Millspaugh, 2010).

Object Oriented Programming (OOP) uses classes, objects, and methods as basic program components (Dann, Cooper, & Pausch, 2008). A clear advantage of OOP is that it creates "reusable" objects that each has its own procedures, data, and methods. This simplifies using these objects for different programs, thus making it easier to develop larger and more complex programs after certain use.

Event driven means designing modules that respond to "events" within the program. The execution of a particular program is dependent on "events" that are triggered by the user or by any other internal or external events. Bruce and Danyluk (2004) advocate using this model for first programming courses because using it makes it easier to learn standard programming concepts.

Although there is some use of the procedural approach to learning to program, recent practices are moving more toward the other two approaches. But there are ways to combine both in one programming use that make a more efficient use of programming models. Bradley and Millspaugh (2010) explained this combination of OOP and Event Driven in the following statement:
   In the OOP and event-driven model, programs are no longer
   procedural. They do not follow a sequential logic. You, as the
   programmer, do not take control and determine the sequence of
   execution. Instead, the user can press keys and click various
   buttons and boxes in a window. Each user action can cause an event
   to occur, which triggers a Basic procedure that you have written.
   For example, the user clicks a button labeled Calculate, The
   clicking causes the button's Click event to occur, and the program
   automatically jumps to a procedure you have written to do the
   calculations. (p. 4)


Based on this increasing use of the Event-driven plus OOP model in teaching programming, the question that repeats itself in the programming academics is whether to teach OOP first or do OOP later. More specifically, the questions asked are whether programming educators should introduce OOP concepts first and then base all examples and practices on these concepts, or should programming practices be emphasized first and then OOP introduced later.

Advocates of OOP first note that this approach gives the students a solid foundation in learning to program and if this approach is continued in future programming courses, it will make it easier to learn other programming languages (Ehlerts & Schulte, 2010). Opponents of OOP first (or advocates of OOP later) note that a significant learning takes place at the beginning of every programming course (Ragonis, 2010). By adding these new topics of OOP, this adds more learning and delays the learning of meaningful output from the program.

In terms of programming language for upper level or senior level students, this becomes more problematic on two fronts. First, there is no second programming course in this regard, so the foundation that the OOP first gives may not be used by these students in their future course. Added to that, by not introducing OOP first, the foundation for developing programs may not be complete.

SELECTING THE EXAMPLES AND ILLUSTRATIONS

Examples are essential to the learning process of any field. Examples in Mathematics, for example, give the students the ability to understand the concepts being presented and give them the opportunity for practicing these concepts, methodology, and principles. In programming, examples represent the cornerstone of learning how to write programs. Without meaningful examples, learning to program is difficult.

Blake (2011) noted the following about selecting programming examples: "Research has shown that assignments that provide early feedback and early success (and that are compelling and visual) are important in improving not just retention, but also gender equity" (p. 126).

In most beginner level programming, examples start by simple programs listing output such as "Hello World." This policy has worked in the past, where producing such simple output took a lot of steps. More recently, these kinds of examples tend to be too simplistic and may end up driving students away from programming courses (Westfall, 2010). For senior level students, these kinds of examples are too simplistic; they do not represent any challenge to them and may lead the student to lose interest in the course or learning to program.

Since studies of enrollment decline in computer courses have pointed fingers at the examples taught in the courses, different approaches have been taken to introduce programming examples. Hassinen and Mayra (2006) explained that the best approach to learning programming is to give more programs to work on. In other words, by writing more programs, students will access different errors and will have more experience dealing with errors and so on. Lau (2003) explained that a more effective way to learn programming is by demonstration, because students can easily personalize their applications.

A different approach emphasizes using case examples that take students from one example to another. Case examples give a broader view of more than one phase of the development cycle. They give either a real situation or a hypothetical case about a company, an organization, or an individual that needs a problem solved. Case examples often give a subset of what resembles a realistic case where a situation that involves multiple steps or issues needs to be resolved. A program needs to be written to solve the problem in this hypothetical situation.

Practical application examples in programming may help show the value of learning to program in what resembles real- life programs. In practical application programs, real-life application cases are given to the class and the students are supposed to write programs for these real-life cases. A major drawback to this approach is that it may lead to giving complex programs and students assigned such applications may need to have significant experience prior to embarking on these kinds of projects.

A RETURN TO PROGRAMMING

The department of Technology Support and Training (BTST) at Eberly College of Business and Information Technology (ECOBIT) at Indiana University of Pennsylvania (IUP) offers a bachelor degree in business education (BusEd) and another bachelor degree in Business Technology Support (BTS). A previous study compared the content of this BTS program with the CC2005 standard curriculum and concluded that the BTS program is aligned more closely with the IT program, as compared to the five programs listed in CC2005, and thus listed it as an IT program (Ali & Kohun, 2008).

Although the BTS program is considered an IT program, it does not require their students to take any programming courses. Most faculty members at the department are not very familiar with programming and thus discourage students from taking any elective programming courses. A faculty member in the department was assigned lately to teach three senior level IT courses to the BTS students. This faculty member noticed the following about the syllabi of the three senior level courses that he had been assigned to teach:

--The syllabi for the three courses were outdated and in some cases did not reflect the current technological realties.

--There was much overlap among the courses in this program; these overlaps extended especially among the three courses that this faculty member was assigned to teach.

--The initial syllabi and design of the courses did not have enough materials to cover an entire semester. Instead, the planned materials for two of the courses could be combined into one. This opens the room for adding additional topics for a course that potentially help the students.

To Teach or Not to Teach Programming

The faculty member decided to teach a programming course for a group of senior level BTS students. In the opinion of this faculty member, the benefits outweighed the drawbacks of teaching programming. The simple reality is that to graduate with an IT degree, students need to have certain knowledge of programming. To have zero programming knowledge is not acceptable in the IT discipline. The faculty member in this case has extensive knowledge in programming; he has taught a lot of courses in the past and was successful in teaching them. The conclusion made by this faculty member is that it would be best for the students if they took at least one programming course and thus he decided to teach programming in one of the three senior level courses assigned to him.

Selecting the Programming Language

Upon further research and investigation into the programming courses offered at this university, the faculty member has decided to teach Visual Basic language using Visual Studio (VB .NET) 2010 platform. VB .NET will be primarily used for windows application. This course will also include teaching Active Server Page (ASP .NET) is another tool to learn for the purpose of developing web applications. The faculty member decided to include both platforms in this course because the senior level students are capable of learning more in a course than what is taught in a typical first programming course. Besides, learning both platforms will give ample materials to the senior student to put on their resume.

Selecting a VB .NET platform as the main language to teach was based on a review of the criteria listed by Parker et al. (2006) which is displayed in figure 1 of this paper. In particular, among the thirteen factors listed, the faculty felt that the Marketability factor and the Debugging Availability factor are more pertinent for senior students. Senior level students need items to add to their resume and improve their marketability. Visual Basic .Net, ASP .Net and the latest in visual studio platform (Visual Studio 2010) should give them enough marketability to add to their resumes. Additionally, the debugging feature of Visual Studio makes it much easier to code, debug, and troubleshoot large programs.

Beside all of the above, the GUI environment and the Event driven approach that characterizes Visual Basic .Net seems to be more consistent with business college courses than other programming languages (Jiang, Maniotes, &Kamali, 2004). This course that is being talked about in this paper is taught at a business college and it seems logical to include a programming language more suitable for business students.

Selecting the Model

A mix of event driven and object orientation has been selected for this course. In other words, the teaching of Object Oriented Programming concepts is put off until later in favor of teaching solid programming concepts and practices at the beginning. Having this course taught to senior level students makes it easier to apply the "OOP later" model for this course. Senior level students need to have more practical applications at the beginning in order to convince them of the usefulness of such a programming course. The same students should have less trouble learning the OOP and applying them to the programs once they have enough experience and once they become more interested in the practicality of the program.

Selecting the Examples

One of the guiding principles for selecting examples for this course is going to be the relative performance capabilities that are outlined in CC2005. Table 2 below extracts these performance capabilities for the five disciplines listed in CC2005. The table excludes the zero coverage suggested for the IT discipline. In other words, there are other performances capabilities listed in the CC2005, but since the emphasis of this paper is only on IT majors, it will be appropriate to exclude those coverage areas that are not suggested for IT discipline. The IT column is shaded in gray color to distinguish it from the other areas.

It is obvious from Table 2 above that CC2005 suggests the least of programming coverage for IT majors among the five majors in general. CC2005 suggests doing more small scale programming, some large scale programming, and less systems programming. This course that is being discussed in this paper will follow these suggestions to a large extent. However, given that this is a senior level course and also that this is the only programming course that the students will take before graduation, more emphasis will be placed on large scale programming and systems programming.

The course will start by giving examples of small scale programming to introduce the students to the concepts and principles of programming. The senior students in this course are expected to pick up small scale programming quickly, thus enabling them to move to large scale programming. Case examples will be illustrated to practice large scale programming. The end of the semester will culminate in designing a major project for an organization (fictitious or real) in which system programming and the development of a new software system is emphasized. In this later stage of the course, giving practical application examples is going to be emphasized. In the last project, a complete follow up of the different stages of development is going to be emphasized, thus making it possible for the students to develop a product of their own which they can include on their resumes and take with them to their interviews to show their mastery of the programming language.

SUMMARY AND SUGGESTED FUTURE RESEARCH

This paper is about teaching a first programming course for senior level information technology (IT) students. The paper started by giving background information on how unique teaching a first programming course in the last year of IT students' coursework is. It then discussed teaching programming in general and elaborated on the factors that stand in favor of teaching programming and the factors that stand against teaching programming. It then covered the different factors that influence the teaching of programming courses. This included the selection of programming languages for the course, selecting a model of the language, selecting the example, and so on. The paper then elaborated on the experience of one faculty member at a university located in western Pennsylvania who is facing this atypical situation of teaching a first programming course for senior level students enrolled in an IT program. He explained what he has decided to include in this course in this unique situation based on the literature he reviewed in this paper and based on his personal experience.

While working on this paper and conducting research on this atypical situation of teaching a first programming course to senior level IT students, the author noticed that it will be useful to conduct a study after completing this course to assess the experience of this atypical situation. Having laid the ground-work for this course, the author will attempt to assess the work he researched to see how helpful the research he has conducted about the teaching of a first programming course for senior level IT students has been.

REFERENCES

Ali, A., & Kohun, F. (2008). Comparing two program contents with IT2005 body of knowledge. Journal of Issues in Informing Science and Information Technology, 5, 62-71.

Ali, A. (2009). A conceptual model for learning to program in introductory programming courses. Issues in Informing Science and Information Technology, 6 (1), 517-529.

Baldwin, L.P., & Kuljis, J. (2001). Learning programming using program visualization techniques. Proceedings of the 34th Hawaii International Conference on System Sciences-2001. Retrieved April 17, 2008, from http://www.computer.org/portal/.

Bills, D. P. & Biles, J. A. (2005).The role of programming in IT. Proceedings of the 6th Conference on Information Technology Education, 43-49. Retrieved December 8th, 2010, from http://www.acm.org/dl.

Bills, D. P., & Canosa, R. L. (2007). Sharing introductory programming curriculum across disciplines Proceedings of the 8th ACM SIGITE conference on Information Technology Education, 99-106.

Blake, J. D. (2011). Language considerations in the first year CS curriculum. Journal of Computing Sciences in Colleges, 26 (6), 124-129.

Bradley, C. J., & Millspaugh, A. C. (2010). Programming in visual basic. New York: McGraw Hill Publishing.

Bruce, K. B., & Danyluk, A. (2004). Event-driven programming facilitates learning standard programming concepts. Proceeding of OOPSLA '04 Companion to the 19th annual ACM SIGPLAN Conference on Object-oriented Programming Systems, Languages, and Applications, 96-100. Retrieved July 3, 2011, from http://www.acm.org/dl.

Computing curricula 2005 the overview report. (2005). Retrieved October 2, 2006, from http: //www .acm.org/dl.

Carter, J., & Jenkins, T. (2002). Gender differences in programming? Proceedings of the 7th Annual Conference on Innovation and Technology in Computer Science Education. Retrieved April 15, 2008, from http://www.acm.org/dl.

Dann, W., Copper, S., & Pausch, R. (2008). Learning to program with Alice. Upper Saddle River, NJ: Prentice Hall.

Ehlert, A., & Schulte, C. (2010). Comparison of OOP first and OOP later: First results regarding the role of comfort level. Proceeding ITiCSE '10 Proceedings of the Fifteenth Annual Conference on Innovation and Technology in Computer Science Education. Retrieved July 9, 2011, from http://www.acm.org/dl.

Information Technology 2008 Curriculum Guidelines for Undergraduate Degree Programs in Information Technology. (2008). Retrieved July 10, 2011, from http://www.sigite.org/ .

Jiang, K., Maniotes, J., & Kamali, R. (2004). A different approach of teaching introductory visual basic course. Proceedings of the 5th Conference on Information Technology Education, 219-225. Retrieved July 11, 2010, from http://www.acm.org/dl.

Kaplan, R. M. (2010). Choosing a first programming language. Proceedings of the 2010 ACM Conference on Information Technology Education. Retrieved July 9, 2011, from http://www.acm.org/dl.

Kelleher, C., & Pausch, R. (2005). Lowering the barriers to programming: A taxonomy of programming environment and languages for novice programmers. ACM Computing Surveys, 37(2), 83-137. Retrieved March 28, 2008, from http://www.acm.org/dl.

Hassinen, M., & Mayra, H. (2006). Learning programming by programming: A case study. Proceedings of the 6th Baltic Sea Conference on Computing Education Research, 117-120. Retrieved July 1, 2011, from http://www.acm.org/dl.

Lahtinen, E., Ala-Mutka, K., & Jarvinen, H. (2005). A study of the difficulties of novice programmers. Proceedings of the 10th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education, 14-18.

Lau, T., Wolfman, S A., Domingos, P., & Weld, D. S. (2003). Programming by demonstration using version space algebra. Machine Learning, 53, 1-2 (111-156). Retrieved November 2, 2010, from http://www.acm.org/dl.

Malan, K., & Halland, K. (2004). Examples that can do harm in learning programming. Proceeding of the Conference on Object Oriented Programming Systems Languages and Applications, 83 -87. Retrieved November 2, 2010, from http://www.acm.org/dl.

Parker K. R., Chao, J.T., Otttaway, T., A., & Chang, J. (2006). A formal language selection process for introductory programming courses. Journal of Information Technology Education, 133-152.

Ragonis, N. (2010). A pedagogical approach to discussing fundamental object-oriented programming principles using the ADT SET. ACM Inroads, 1(2), 42-52. Retrieved December 8, 2010, from http://www.acm.org/dl.

Teague, D., & R. R. (2008). Collaborative learning - towards a solution for novice programmers. Proceedings of the Tenth Conference on Australian Computing Education, 78, 147-153.

Westfall, Ralph. (2001). Technical opinion: Hello, world considered harmful. Communications of the ACM, 44 (10), 129-130.

Azad I. Ali, Indiana University of Pennsylvania
TABLE 1
Illustration of Knowledge are Suggested By CC2005

Knowledge Area      CE          CS          IS

                 Min   Max   Min   Max   Min   Max

Programming       4     4     4     5     2     4
Fundamentals

Integrative       0     2     1     3     2     4
Programming

Knowledge Area      IT          SE

                 Min   Max   Min   Max

Programming       2     4     5     5
Fundamentals

Integrative       3     5     1     3
Programming

Table 2
Relative Performance Capabilities of Computer Programming

Area           Performance         CE    CS    IS    IT    SE
               Capability

Application    Do small-scale       5     5     3     3     5
Programs       programming

               Do large-scale       3     4     2     2     5
               programming

               Do systems           4     4     1     1     4
               programming

               Develop new          3     4     3     1     5
               software systems
COPYRIGHT 2011 American Society for Competitiveness
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2011 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Ali, Azad I.
Publication:Competition Forum
Article Type:Report
Date:Jun 1, 2011
Words:5539
Previous Article:Interdisciplinary education for global strategy.
Next Article:Universal sustainability: the next form of competitiveness.
Topics:

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters