Software Engineering, an established Accreditable Engineering Discipline
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Software Engineering, an established Accreditable Engineering Discipline By B.Szabados, P.Eng, McMaster University, Hamilton, Ont. (member of CEAB) Note: The content of this paper has been presented at a workshop of the Canadian Engineering Accreditation Board (CEAB), as well as at a workshop at the NCDEAS meeting in September 1997. 1. INTRODUCTION In the late seventies, the discipline of Computer Engineering has evolved from Electrical Engineering. The main emphasis was on the hardware aspects of logic design and computers, principally microprocessors. The natural evolution of a discipline following the needs of industry led some University programs to the introduction of an option “Computer Engineering”, in the last year of an accredited Electrical Engineering program. The next natural evolution was a stand alone Computer Engineering CEAB accredited program (first in 1983 at McMaster University). It has to be noted that the “definition” of Computer Engineering was at most fuzzy at the time, and even today it is difficult to give a narrow definition of it. Software Engineering is a term that has been with us as far back as the sixties. We will not enter the debate on definition. However one fact remains that the discipline of software engineering is an industrial reality, dictated by the practice and needs in today’s society. The main problem dealing with the Software Engineering concept is that the need, practice and evolution in multiple branches has taken place without the participation of the University curricula or professional regulatory bodies. To make things even more complex, other professionals such as technologists and computer scientists, have put forth claims towards practising “Software Engineering”. Again the aim of this presentation is not to enter the legal debate.It is proposed here to illustrate that “Software Engineering” is clearly a strong discipline of Engineering, on its own merits and that a program is accreditable.
p.2 2- MISSION Instead of dwelling with definitions related to “Software Engineering”, let us postulate the mission of a Software Engineer as perceived in today’s society: “The software engineer specializes in designing, building, upgrading, operating and maintaining software systems. He must ensure the security, safety, reliability, user friendliness and cost effectiveness (quality attributes) of these software systems, that are important for the economy and well being of the public.” This mission statement implies that the expectations of a Professional Engineer fully apply, namely: a role of mentorship is expected; and a certain philosophy pertains to the education of an engineer. The software engineer is first and above all an engineer. Similarly to other engineers, he has a specialization defined above in general terms, but always pertains to his professional responsibility with respect to society. It must be understood that there are many secondary specialization areas in a discipline. Diversities will be expected within the discipline of Software Engineering. The common root of an engineering education is composed of a careful selection of relevant content of Mathematics, Basic Sciences, Complementary studies, Engineering Design and Engineering Sciences. The engineering education in the topics of sciences, is the application of the knowledge generated by those sciences, and not generally the derivation of this knowledge. Therefore the discipline of Computer Sciences will play a key role in the education of the software engineer. But this role will not be different from the role of Basic Sciences for example. It may only mean that more material will be derived from the knowledge generated by the science of computer sciences. This is similar to Chemistry which will play a larger part in the background of a Chemical Engineer than an Electrical Engineer for example. The program specific criteria of software engineers could be defined in the methodologies for analysis, test, monitoring, validation and interfacing software products. The software engineer is expected to assume responsibility accountability and liability for the product developed. 3- GOALS Within the above mission statement, the software engineer will be asked to develop software as a product. This may de designed to control electromechanical devices, coordinate safe start or shut down sequences, operate computerized communication systems, manage information infrastructures, produce computer systems used to design other engineering products or services, and many other applications. This typical list is only quoted to illustrate the diversity of secondary specialization that exists in the discipline today, similarly to other engineering disciplines requiring a very large scope of knowledge. However a common requirement for all software engineers is the need to learn a disciplined methodology to specify, design, document, develop, produce, test, integrate, assess, analyze, monitor, upgrade and market software systems which are able to perform their assigned tasks. This is certainly not a mere programming exercise.
p.3 It would be worth at this point to illustrate the place of the software engineer within the general technology requirements of the “computer world”. There are typically 3 spheres of activities. The application development of non technical programs (word processors), or general use tools (graphical aids) do not need the constraints of the engineering responsibility. Non engineers, either programmers with a “good idea” or more educated computer science personnel could attend to those applications, since programming is only a “packaging” exercise. A second area addresses applications where the computers, or its elements, or system components are interfaced to the user. In these applications, the art becomes an engineering exercise, with professional responsibility culminating. This is definitely the realm of the Computer Engineer, who needs the appropriate skills in general engineering, electrical engineering and some elements of software development, to arrive at an appropriate design. This area involves Engineering Design, which is the identity of the engineering education. The third area addresses a complex multidisciplinary area of computer systems, team development, maintenance and management activities. Because of the applications which are multidisciplinary, the software engineer is not expected to be a specialist in all areas touching the development. He becomes the common denominator in the multidiciplinary team, not because he knows the details, but because he knows the design methodology. In his team he will coordinate experts (mathematicians, computer scientists, material scientists etc...) who construct the algorithmic requirements, but he will direct the design of the overall project from a technical point of view. He should be responsible to assure that documentation is properly done (specification and operating conditions, code, testing, maintenable). He should have an overall assessement that the hardware configuration proposed is appropriate to the task. He must ensure that programs terminate when and how intended, and that the system meets the real time constraints and other performance requirements such as reliability, fault tolerance and redundancies. In summary a typical skill profile of the software engineer should include the following: - Analysis of the application to derive technical requirements of a computer system - Recording of those requirements in a precise, organized document that can be reviewed by specialist engineers and become the basis for specification design, review and testing. - Design of the computer system configuration with function implementation in hardware/ software, selection of hardware/software components. - Performance analysis using analitical tools or simulation to assure that the proposed equipment or system meets the requirements. - Design the structure of the software in modules, interfaces and hierarchical structures. - Document the software component interfaces - Analyze the software structures for completeness, consistency and suitability. - Implement the software with in-line documentation. - Systematic and statistical testing of the system and software. Armed with the mission statement, the goals and the skill expectations, we can now proceed with the identification of an appropriate curriculum.
p.4 4- TABULAR ANALYSIS OF CURRICULUM TOPICS Instead of taking an existing engieering curriculum, for example a computer engineer program, and add a solid software component, like most Universities do at the moment, we decided to design a stand alone Software Engineering curriculum based on the real needs as defined above. A list of major topics was drawn up without any premeditated order or outcome (Table I). Each subject was entered in a table, and a rating was applied for each of the four disciplines: Electrical Engineering (EE), Computer Engineering (CE), Software Engineering (SE) and Computer Science (CS). The rating was quantized as follows: (F)=fundamental for the discipline; (C)=core; (EL)= elective; ()= not an outstanding requirement. “Fundamental” means that no program can be conceived without these topics. “Core” means that it is strongly expected to cover these topics, however, some specialization in the general discipline may chose not to include it. “Elective” means that it is desirable to have a knowledge of, or have a specialization if so chosen. It is also to be noted that the qualifiers relate only to the topic as being applied to the discipline, and not to the “engineering education”. It is imperative at that stage to understand that the judgement applied was essentially subjective of what was understood by the titles. No attempt was made to define the quality nor the depth of the topic. But also it is imperative to understand that no differentiation was made in the flavor and emphasis in the topics. For instance in the topic “Operating Systems”, both SE and CS are rated (F). However it is obvious that a course called Operating Systems will be very different when tailored to SE or CS. Computer Systems students will be interested in conceiving operating system principles, and dwell on theoretical models of implementations. Software Engineering students will require to use operating systems, therefore they have to know how they work, how they perform, and most of all how they compare to each other. But in this first stage of planning no such differentiation was made. Using a specially designed algorithm, the matrix was sorted to show groups of topics illustrated by similar ratings. It is interesting to observe that classes appear as shown by Table II. The first class, ‘EE/CE major’ constitutes a basis common to both EE and CE. It is interesting to observe that SE will also have these topics either as (F) or (C) rating, while CS has only (C) or (EL) or (none) ratings. It is clear to the designer that these topics are clearly a common engineering basis to the curriculum. The second class ‘SE majors’ having essentially (F)’s and (C)’s, and shows their neigbours with a decreased emphasis. Again some topics show, for instance “Computer Architecture”, to be a topic that is fundamental to CE as well, but at a different level of emphasis much more hadware oriented. The ‘CS majors’ stands out in the fields of mathematics and operating systems, which are knowledge generated by computer science, and is used as major tools by the software engineer. The ‘EE/CE flavour’ shows clearly that CE has been derived from EE, and that some of that knowledge is also used by software engineers, but mainly on a specialization level, rather than a deep underlying basics level. The next two classes are less distinct, and are labelled ‘SE flavour’ and ‘CS flavour’ where
p.5 the topics are essentially reserved for these two disciplines. Here the topics differ in delivery and emphasis and depth of the subject between the disciplines. An extra class, Engineering topics, highlight the general culture that is common to EE, CE and SE, and is definitely not present in CS. The list shown in Table I is by no means exhaustive. We have dropped topics which were “regional”, that is pertinent to some existing programs of specialization (for example VLSI), because we did not feel that it enters a class of “universal measure”. 5- DERIVATION OF A CURRICULUM TEMPLATE Based upon the analysis of Table II, we have derived constraints for a template curriculum. All courses in this template are based on a 3 credit basis which represents on average 40 accreditation units as defined by the CEAB. Six courses in Mathematics clearly are identified in the tables. Namely: Calculus; Linear Algebra; Differential Equations; Logic; Mathematical Foundations and Discrete Mathematics; Probabilities and Statistics. It is to be noted here that this differs somewhat from the “standard EE” curriculum requirements in Mathematics. Usually neither Logic nor Discrete Mathematics are covered in conventional EE programs. This already points out that SE students have somewhat different requirements from EE/CE students (2 out of 6 courses different). In Basic Sciences, we have identified 5 courses: Chemistry; Mechanics and Stress Analysis; Electromagnetic Waves; Thermodynamics and Heat Exchange; Structures and Properties of Materials. Because each software engineering program will have an “institution flavour” reflected by the philosophy, resources available and regional needs we have allocated one extra Basic Sciences course as an ELECTIVE SCIENCES topic in the spirit of the CEAB classification (Biology Astronomy, etc...). The reasoning behind these 6 courses comes from the mission statement of the software engineer. He will have to lead a multidisciplinary team, therefore he should have a solid basic science background to at least be able to communicate with the experts in each of the fields. Three courses in complementary studies must cover: Technology and Society; Communications Skills and Professionalism (including law and ethics as well as Health and Safety issues); Economics for engineers. These are basic requirements for all engineers, reflecting their professional responsabilities to society. Three other complementary studies courses should be scheduled to acquire the humanities and social sciences and thought processes of humanities that are advocated by the CEAB requirements. A major design experience consisting in a formal design project must be included. This design experience should stress the team environment and foster leadership development. It is imperative that such project does not mearly produce a software program, but englobes all of the steps of the software design experience, namely - Specification - Implementation, - Documentation - Testing - Interpersonal skills and interface activites should be encouraged In order to evaluate the accreditation criteria of the engineering courses, accreditation units are associated according to the CEAB classifications of Engineering Sciences (ES=%) and Engineering Design (ED=%) expressed in pecentages and are done based on a conservative
p.6 measure. For several courses the estimated coefficient ratings are based not just on possible content, but also on the ability to use resources on who can teach engineering design. For instance the course “Theory of Programming languages and Language selection” might very well contain some engineering design, but since it is assumed that a non registered professional will teach it most likely, a 100% Engineering Science component is assumed. In this table we do assume that the CEAB requirements of registered professionals should teach all engineering design and engineering sciences will be somewhat relaxed, at least until accredited software engineers become available, and permit some of the engineering science to be tought by non engineers. We do however strictly enforce the engineering design component to be taught be registered engineers. From the EE classes, we propose to introduce courses that reflect the needs for software engineers to understand the basics of the hardware and the concepts of control and electrical signals they will be expected to deal with. Namely the 4 courses proposed are: Circuits and Instrumentation, [ES=100%]; Introduction to Electronics, [ES=80% ED=20%]; Introduction to Control Theories, [ES=80% ED=20%]; Elements of Telecommunications, [ES=80% ED=20%]. Finally from the CE class we have extracted 6 basic courses. Two of them would be common requirements to the CE and SE students, essential basic tools: Numerical Methods [ES=100%]; Data Structures, [ES=100%]. Three courses essentially belonging to CE are: Digital System Design (providing the fundamentals of microprocessors), [ES=50% ED=50%]; Computer Architecture (advanced systems with multiprocessor and parallel processors), [ES=40% ED=60%]; Computer Communication Networks (related to physical media, routing, protocols, [ES=56% ED=40%]; and Simulation and Modeling [ES=60% ED=40%], left in the CE category rather than the EE common core, because for a software engineer the emphasis would be on discrete modelling and simulation, while EE would lean towards continous models. Table II shows also ‘CS flavour’ required courses as follows: Fundamentals of Computer sciences, [ES=100%]; Theory of Programming languages and Language selection [ES=100%]; Compilers, [ES=100%]; Automata, [ES=100%]; Data Base, [ES=100%]. Based on Table II, there are 6 more courses which reflect needs in an SE core program. These could be: Introduction to low level programming (year 1) [no CEAB weighting]; Design of Software Systems [ES=40% ED=60%]; Advanced Design of Software Systems, [ES=20% ED=80%]; Design of Concurrent and Real Time Software, [ES=30% ED=70%]; Operating Systems, [ES=80% ED=20%]; Data Management techniques, [ES=20% ED=80%]. Based upon a 4 year (8 term program) with 6 courses per term this leaves 8 more courses that can be used towards a secondary specialization (options), or special regional flavours (program enhancements). Some topics could include the following topics: Performance analysis of computer systems [ES=20% ED=80%]; Optimization methods [ES=20% ED=80%]; Design and Evaluation of Operating Systems [ES=20% ED=80%]; Design of Human Interfaces [ES=40% ED=60%]; Evaluation and Selection and Design of CAD tools [ES=40% ED=60%]; Intelligent Manufacturing Systems and Process control [ES=40% ED=60%]; Image processing [ES=40% ED=60%]; Geographic Information Systems [ES=40% ED=60%]; Computer security [ES=40% ED=60%]; DSP [ES=40% ED=60%]; Business Applications of Computers [ES=40% ED=60%]; Information retreival [ES=40% ED=60%]; Computational geometry [ES=40% ED=60%]; interdisciplinary topics in Civil, Mechanical, Chemical etc..
p.7 The program template is summarized here: - 6 Mathematics courses - 6 Basic Sciences courses - 3 complementary (communication; Technology and Society; Health and Safety; Economy) - 3 Humanities and Social Sciences - 1 Capstone Engineering Design - 4 Electrical Engineering - 6 Computer Engineering - 5 Computer Sciences (service courses) - 6 software engineering courses - 6 compulsory SE courses from a list similar to that given above - 2 technical electives from EE, CE, CS or other Engineering disciplines According to the distribution of AU’s in the SE compulsory/elective list, we could assume conservatively that the 6 compulsory courses would have at least 2 courses with the [20-80] distribution, and 4 courses with [40-60] distributions. The remainder of the 2 technical electives would register no AU’s according to a pessimistic scenario of minimum path rule. A preliminary very pessimistic CEAB evaluation would show the following scores: Total of 48 courses at 40 AU/c (not counting labs and tutorials) 1920 AU (*1800) Maths: 6 courses 240 AU (*195) Basic Sciences: 6 courses 240 AU (*225) Complementary Studies: 6 courses 240 AU (*225) ES ED ES+ED Core: 580 AU 264 AU 844 AU Compulsory: 2 courses with [20-80] 16 AU 64 AU 80 AU 4 courses with [40-60] 64 AU 96 AU 160 AU _______ _______ ______ Totals: 660 AU 424 AU 1084 AU (*225) (*225) (*900) All of these coefficients are well within the CEAB minimum requirements as shown in bracket with a star. They are pessimistic numbers since no laboratory nor tutorial has been counted. It is to be noticed that at least 12 courses are specifically Software Engineering discipline courses, or 1 year out of the 4 year curriculum. This confirms that the program is very distinct from any of the other engineering disciplines. 6- DISCUSSION ON SCHEDULING AND RESOURCES Generally engineering programs are structured to introduce material in early levels in order to feed the more specialized courses in the disciplines. With software engineering, it is important to recognize that, although programming is not the main goal of the program, it is a very important tool. Furthermore, similarily to Mathematics as a tool, students have been introduced to
p.8 the process of thought of mathematics, and through high schools have already acquired some working knowledge and practice through exercises. The problem with software is, that students arrive from high schools with a false impression of knowledge. “Computer courses” covered how to use word perfect, or how to surf the net, and most students are computer game aces. It takes considerable effort to make them understand what software development really is. The program should therefore be scheduled in such a way that students not only receive introduction to programming (generally common to all engineering students) and fundamentals of computer sciences, but also as soon as feasible, start the systematic software development process, and provide them with practical ways to write examples. Wheras courses such as Electric Circuits, which is the basic tools for electrical engineering, is now a “complement” to the knowledge of the software engineer, and therefore can be given later as scheduling permits. The streaming of the material attempts to put it in a 6 course per term sequenced package. It can be a frustrating experience because the engineers planning the material delivery do not yet have the experience of the best “acceptable” way to sequence software education. The design method suggested here, is to write up clear objectives for each course, as a stand alone exercise, not worrying about its scheduling. It is helpful though to derive progressive objectives in a sequence of courses, for instance in the software development area. This would ensure that all the important material is covered. As an example (and this is by no means to be taken as necessarily the right way!) a sequence of 3 courses after the introduction to programming can include the following objectives: Course 1: “Given the problem specifications, students will be able to design, implement and document the modular layout of the program.” Course 2: “The students will be able to derive the program specifications from a set of engineering description, and should be able to design, implement and document the program.” Course 3: “The students should be able to design, implement, document a given physical problem, and be able to test for comformity, completeness, and performance, as well as plan for maintenance and upgrade documentation”. From the objectives above, one can see that many techniques, analysis tools and basic computer sciences derived knowledge have to be covered before a student can achieve these. In a second phase, the curriculum design should proceed with a detailed outline of material on a course by course basis, in order to achieve the objectives. At this level it is important to conduct a parallel exercise. While listing the topics in the course, a list of associated topics which are assumed to be known is drawn up. This will constitute the criteria of co or pre requisits for the streaming. Based on the course content as well as pre requisit knowledge, a first streaming of courses is attempted. Careful examination of the layout will always cause a few loops in the design. Material which is prerequisit may have to be lumped in the course and some material shifted out. Care should be taken that all co or pre-requisit topics will be covered, and not simply left to the whim of the instructor to cover when he discovers that students have no idea of what he talks about... This is by far the most time consuming exercise of the curriculum development, and it is suggested that all future faculty teaching the courses be involved and give a solid feedback to the
p.9 development committee. It is the experience of the author, that invariably this exercise leads to “too much material” to be crammed in a 4 year curriculum. The third phase of the development addresses now the loading of the student, as well as the evaluation of material assimilated which goes in line with the level of maturity of students at time of delivery. Certain concepts cannot be covered unless students become mature and have acquired a solid working skill background, say in data structures. This phase attempts to put contact hours, student work loading or other numerical weighting to each topic in the course content. This usually will result in shifting emphasis or depth within a course. It may also dictate to redistribute the topic in increasing levels of difficulties in subscequent courses. It is necessary at that point to define tutorials and laboratory content associated in great detail. It is not sufficient to state that 3 hours of laboratory will be taking place every second week. The objectives and detailed content of the laboratories must be defined and integrated either to illustrate the lecture, or introduce new concepts not covered in the lecture. This should lead to a layout which satisfies the curriculum content and delivery sequence. For new programs, and software engineering certainly qualifies, a problem of teaching resources immediately come to mind. Identification of the potential knowledge base within existing faculty members in Electrical, Computer Engineering and Computer Sciences units is usually fairly simple. It is advised to survey also the other disciplines. For instance Chemical engineers who do process control, or manufacturing engineers, usually have a pool of knowledge well within the software engineering program needs. These individuals may need to rework some of their knowledge and shift emphasis in the methods of presentation of material. They have to be willing to “recycle”. Computer Science faculty members may also be asked to focus on different topics when teaching engineers, and this means a concerted effort to prepare for this new way of thinking software development. Nevertheless, the pool of knowledge usually reveals that most faculties have already the knowledge base to cover most of the topics in software engineering. Some existing courses in engineering may differ in emphasis to the ideal presentations to software engineers. But for start up programs, there might be a compromise reached, which permits implementation of a “decent” program without unduly creating a flock of new courses, and drive the administration out of their mind when a faculty requests 12 new faculty members at once! However it has to be recognized that the introduction of at least 12 courses proper to software engineering, will require at least 6 new faculty positions. It is important to notice that, because of the competition with industry in this area, it would be a dream to hire 6 software engineers. But bear in mind that if the existing faculty complement in the University has the knowledge base, then new faculty could be hired in the conventional areas to offload faculty who will participate now in the new software program. It is also to be noted that these 6 positions are not needed at once. The 12 new courses are usually distributed over at least 3 years. The exercise now is to convince the administartion to have an expansion plan covering 3 years, with probably 3 new faculty in the first year, and then 3 more in the next 2 years. This sounds less scary to today’s administrators tackling difficult budgets. 7- CONCLUSIONS Software Engineering, unlike other engineering disciplines, has developed in the past 15
p.10 years directly in user groups. Because it was commonly associated as an “add on tool” to other established disciplines, the Educational institutions have failed to adapt to the needs of industry, by providing distinct educational curricula. We are facing a fairly mature discipline without the infrastructure of an adequate educational process. In this presentation, a mission statement and clear goals are proposed, leading to the expectations of a professional engineer as applied to Software Engineers. It is shown that these expectations are exactly the same as for any established discipline: responsibility, accountability and liability. The Software Engineer must learn a disciplined methodology based on engineering design, which is proper to the discipline. The Software Engineer is a Professional Engineer with all the strings and advantages attached. A set of typical skills profile was attempted, followed by a systematic analysis of scientific, mathematics and engineering topics that are presently taught in various institutions in programs such as Electrical or Computer Engineering and Computer Sciences. An original matrix analysis shows clearly that although aside from the attributes with other accredited programs, there are courses required to convey the knowledge base from conventional disciplines: Mathematics, Basic Sciences and Computer Sciences. Some course content can be taken from introductory Electrical curricula, and obviously some overlap will exist with Computer Engineering curricula especially for the hardware parts. But it has been shown that at least 12 courses, which represents one full year over a total of 4 years, are specialized software courses. This should make it clear that Software Engineering is a distinct discipline, clearly different from Computer Engineering as well as Computer Sciences. Finally a template curriculum is proposed, showing that such a program meets all the requirements of the Canadian Engineering Accreditation Board criteria. The template illustrates that there is plenty of room to satisfy the various course content requirements of the CEAB, and still have manouvering space to accomodate various options, specializations, and electives. This is very important since every University will have to carve out an identity for its program, based on current knowledge expertise, regional demands, and institutional goals. 8- ACKNOWLEDGEMENTS Acknowledgements are due to the McMaster University team of curriculum development, the software curriculum development group, and the special task force. A special mention is made to Dr David Parnas, P.Eng, Bell Chair in Software Engineering at McMaster University, for the many brain storming sessions and original ideas he brought into the project. Mention is due to Dr Mohan Mathur for his constructive assistance in the presentation of the key problems.
p.11 Comparisons of EE / CE / SE / CS curricula contents F=Fundamental > C= CORE > EL=elective subject EE CE SE CS 1 Design experience F F F 2 Math: Calculus F F C C 3 Math: D.I.F. F F C EL 4 Math: Linear Algebra F F C EL 5 Circuits F F C 6 Control Systems F C C 7 EM fields F C EL 8 Electronics (analog) F C EL 9 Computer architecture C F F C 10 Electronics (digital) C F EL 11 Numerical Methods/computing C C F F 12 Computer Programming C C F C 13 Simulation & Modeling C C F C 14 Math: Stats C C C EL 15 Optimization methods C C C EL 16 Chemistry (intro) C C C 17 Stress Analysis Concepts C C C 18 Structure & Properties of Materials C C C 19 Thermodynamics concepts C C C 20 Heat Exchange concepts C C C 21 Mechanics concepts C C C 22 Signal Processing C C EL 23 A&D Communication C EL 24 Math: Discrete EL F F F 25 Data Structures EL C F F 26 O.S. EL C F F 27 Software Design EL C F C 28 Specification, Quality & Testing Software EL C F EL 29 Protocols (nets) EL C C EL 30 Computers in Communication Systems EL EL C 31 Theory of programming languages C F F 32 Concurrency & Assynchronous Comm. EL F C 33 Compilers EL C F 34 Automata EL C F 35 Languages EL C F 36 Data Base EL C C 37 Information Retreival EL C EL 38 Computer Security EL C EL 39 Embedded Systems EL C EL 40 Design of Human Interfaces EL C EL 41 Design and Evaluation of Software Systems EL C EL 42 Data Management techniques EL C 43 Math: Abstract F F 44 Business Mathematics EL TABLE I: Raw Data Analysis
p.12 Comparisons of EE / CE / SE / CS curricula contents (F=Fundamental > C= CORE > EL=elective) subject EE CE SE CS EE,CE majors Design experience F F F Math: Calculus F F C C Math: Linear Algebra F F C EL Math: D.I.F. F F C EL Circuits F F C SE majors Computer architecture C F F C Simulation & Modeling C C F C Computer Programming C C F C Specification, Quality & Testing Software EL C F EL Software Design EL C F C Concurrency & Assynchronous Comm. EL F C Design of Human Interfaces EL C EL Design and Evaluation of Software Systems EL C EL Embedded Systems EL C EL Data Management techniques EL C CS major Math: Discrete EL F F F Theory of programming languages C F F Math: Abstract F F Automata EL C F Languages EL C F Compilers EL C F EE/CE flavor Control Systems F C C EM fields F C EL Electronics (digital) C F EL Math: Stats C C C EL Signal Processing C C EL A&D Communication C EL SE flavor Protocols (nets) EL C C EL Computers in Communication Systems EL EL C Information Retreival EL C EL Computer Security EL C EL Performance Analysis of Computer Systems EL C CS flavor Data Base EL C C Eng. topics Optimization methods C C C EL Thermodynamics concepts C C C Heat Exchange concepts C C C Mechanics concepts C C C Chemistry (intro) C C C Stress Analysis Concepts C C C Structure & Properties of Materials C C C TABLE II: Analysis of Data
You can also read