ZeePedia buy college essays online

Software Engineering - II

<<< Previous Adaptation to Alternative Environments Next >>>
Chapter 7: Adaptation to Alternative Environments
Software engineering curricula do not exist in isolation. They are found in institutions; and these
institutions have differing environments, goals, and practices. Software engineering curricula
must be able to be delivered in a variety of fashions and to be part of many different types of
There are two main categories of "alternative" environments that will be discussed in this
section. The first is the alternative teaching environment. These environments use non-standard
delivery methods. The second is the alternative institutional environment. These institutions
differ in some significant fashion from the usual university.
Alternative Teaching Environments
As higher education has become more universal, the standard teaching environment has tended
toward an instructor in the front of a classroom. Although some institutions still retain limited
aspects of a tutor-student relationship, the dominant delivery method in most higher education
today is classroom type instruction. The instructor presents material to a class using lecture or
lecture/discussion presentation techniques. The lectures may be augmented by appropriate
laboratory work. Class sizes range from fewer than 10 to more than 500.
Instruction in the computing disciplines has been notable because of the large amount of
experimentation with delivery methods. This may be the result of the instructors' familiarity with
the capabilities of technology. It may also be the result of the youthfulness of the computing
disciplines. Regardless of the cause, there are numerous papers in the SIGCSE Bulletin, in the
proceedings of the CSEE&T (Conference on Software Engineering Education & Training)
conferences, in the proceeding of the FIE (Frontiers in Education) conferences, and in similar
forums, that recount significant modifications to the conventional lecture and lecture/discussion-
based classrooms. Examples include all laboratory instruction, and the use of electronic
whiteboards and tablet computers, problem based learning, role-playing, activity based learning,
and various studio approaches that integrate laboratory, lecture, and discussion. As has been
mentioned elsewhere in this report, it is imperative that experimentation and exploration be a
part of any software engineering curriculum. Necessary curriculum changes are difficult to
implement in an environment that does not support experimentation and exploration. A software
engineering curriculum will rapidly become out of date unless there is a conscious effort to
implement regular change.
Much recent curricular experimentation has focused on "distance" learning. The term is not well
defined. It applies to situations where students are in different physical locations during a
scheduled class. It also applies to situations where students are in different physical locations and
there is no scheduled class time. It is important to distinguish between these two cases. It is also
important to recognize other cases as well, for example the situation where students cannot
attend regularly scheduled classes.
SE2004 Volume ­ 8/23/2004
Students at different physical locations
Instructing students at different physical locations is a problem that has several solutions. Audio
and video links have been used for many years, and broadband Internet connections are less
costly and more accessible. Instructor-student interaction is possible after all involved have
learned how to manage the technology without confusion. Two-way video makes such
interaction almost as natural as the interaction in a self-contained classroom. On-line databases
of problems and examples can be used to further support this type of instruction. Web resources,
email, and Internet chat can provide a reasonable instructor "office hour" experience.
Assignments can be submitted by email or by using a direct Internet connection. The current
computing literature and departmental Web sites contain numerous descriptions of "distance
learning" techniques.
It should be noted that a complete solution to the problem of delivering courses to students in
different locations is not a trivial matter and any solution that is designed will require significant
planning and appropriate additional support. Some may argue that there is no need to make
special provision for added time and support costs when one merely increases the size of an
existing class by adding some "distance" students. Experience indicates that this is always a very
poor idea.
Students in software engineering programs need to have experience working in teams. Students
who are geographically isolated need to be accommodated in some fashion. It is unreasonable to
expect that a geographically separated team will be able to do all of its work using email, chat,
blogs, and newsgroups. Geographically separated teams need additional monitoring and support.
Videoconferencing and teleconferencing should be considered. Instructors may also want to
schedule some meetings with the teams, if distances make this feasible. Beginning students
require significantly more monitoring than advanced students because of their lack of experience
with geographically separated teams.
One other problem with geographically diverse students is the evaluation of student
performance. Appropriate responsible parties will need to be found to proctor examinations and
check identities of examinees. Care should be taken to insure that evaluation of student
performance is done in a variety of ways. Placing too much reliance on one method (e.g., written
examinations) may make the evaluations unreliable.
Students in class at different times
Some institutions have a history of providing instruction to "mature" students who are employed
in a full-time job. Because of their work obligations, employed students are often unable to
attend regular class meetings. Videotaped lectures, copies of class notes, and electronic copies of
class presentations are all useful tools in these situations. A course Web site, a class newsgroup,
and a class distribution list can provide further support.
There is also instruction that does not have any scheduled class meetings. Self-scheduled and
self-paced classes have been used at many institutions. Classes have also been designed to be
completely "Web-based." Commercial and open-source software has been developed to support
many aspects of self-paced and Web-based courses. Experience shows that the development of
self-paced and Web-based instructional materials is very expensive and very time consuming.
SE2004 Volume ­ 8/23/2004
Students who do not have scheduled classroom instruction will still need team activities and
experiences. Many of the comments made above about geographically diverse teams will also
apply to them. An additional problem is created when students are learning at wildly different
rates. Because different students will cover content at different times, it is not feasible to have
content instruction and projects integrated in the same unit. Self-paced project courses are
another serious problem. It will be difficult to coordinate team activities when different team
members are working at different paces.
Curricula for Alternative Institutional Environments
Articulation problems
Articulation problems arise when students have taken one set of courses at one institution or in
one program and need to apply these to meet the requirements of a different institution and/or
If software engineering curricula existed in isolation, there would be no articulation problems.
But this is rarely the case. Software engineering programs exist in universities with multiple
colleges, schools, divisions, departments, and programs. Software engineering programs exist in
universities that cooperate and compete with other universities and institutions. Some secondary
schools offer university-level instruction, and students expect to receive appropriate credit and
placement. Satisfactory completion of a curriculum must be certified when the student has taken
classes in different areas of the university as well as at other institutions. Software engineering
programs must be designed and managed so that articulation problems are minimized. This
means that the internal and external environment at the institution must be considered when
designing a curriculum.
Coordination with other university curricula
Many of the core classes in a software engineering curriculum could also be core classes in
another curriculum. An introductory computer science course could be required for the curricula
in computer science, computer engineering, and software engineering. Certain architecture
courses might be part of curricula in computer science, computer engineering, software
engineering, and electrical engineering. Mathematics courses could be required for curricula in
mathematics, computer science, software engineering, and computer engineering. A project
management course may be required by software engineering and management information
systems. Upper level software engineering courses could be taken as part of computer science or
computer engineering programs. In most universities, there will be pressure to have courses do
"double duty" whenever possible.
Courses that are a part of more than one curriculum must be carefully designed. There is great
pressure to include everything of significance to all of the relevant disciplines. This pressure
must be resisted. It is impossible to satisfy everyone's desires. Courses that serve two masters
will inevitably have to omit topics that would be present were it not for the other master.
Curriculum implementers must recognize that perfection is impossible and impractical. The
minor content loss when courses are designed to be part of several curricula is more that
SE2004 Volume ­ 8/23/2004
compensated for by the experience of interacting with students with other ideas and background.
Indeed, a case can be made that such experiences are so important in a software engineering
curriculum that special efforts should be made to create courses common to several curricula.
Cooperation with other institutions
In today's world, students complete their university education via a variety of pathways. While
many students attend just one institution, there are substantial numbers who attend more than
one. For a wide variety of reasons, many students begin their baccalaureate degree program at
one institution and complete it at another. In so doing, students may change their career goals or
declared majors; may move from a liberal arts program to an engineering or scientific program;
may satisfy interim program requirements at one institution; may engage in work-related
experiences; or may be coping with financial, geographic, or personal constraints.
Software engineering curricula must be designed so that these students are able to complete the
program without undue delay and repetition, through recognition of comparable coursework and
aligned programs. It is straightforward to grant credit for previous work (whether in another
department, school, college, or university) when the content of the courses being compared is
substantially identical. There are problems, however, when the content is not substantially
similar. While no one wants a student to receive double credit for learning the same thing twice,
by the same token no one wants a student to repeat a whole course merely because a limited
amount of content topic was not covered in the other course. Faculty do not want to see a
student's progress unduly delayed because of articulation issues; therefore, the wisest criteria to
use when determining transfer and placement credit are whether the student can reasonably be
expected to 1) address any content deficiencies in a timely fashion and 2) succeed in subsequent
To the extent that course equivalencies can be identified and addressed in advance via an
articulation agreement, student interests will best be served. Many institutions have formal
articulation agreements with those institutions from which they routinely receive transfer
students. For example, such agreements are frequently found in the United States between
baccalaureate-degree granting institutions and the associate-degree granting institutions that send
them transfer students. Other examples can be seen in the 3-2 agreements in the United States
between liberal arts and engineering institutions; these agreements allow a student to take three
years at a liberal arts institution and two years at an engineering institution, receiving a Bachelor
of Arts degree and a Bachelor of Science degree.
When formulating articulation agreements and designing curricula, it is important to consider
any accreditation requirements that may exist. An accredited program may only retain
accreditation for all its students if it can show that students entering from other institutions have
learned substantially similar material.
The European Credit Transfer System is another attempt to reduce articulation problems in that
SE2004 Volume ­ 8/23/2004
Programs for Associate-Degree Granting Institutions in the United
States and Community Colleges in Canada
In the United States, as many as one-half of baccalaureate graduates initiated their studies in
associate-degree granting institutions. For this reason, it is important to outline a software
engineering program of study that can be initiated in the two-year college setting, specifically
designed for seamless transfer into an upper-division (years 3 and 4) program. Regardless of
their skills upon entry into the two-year college, students must complete the coursework in its
entirety to well-defined competency points to ensure success in the subsequent software
engineering coursework at the baccalaureate level. For some students, this may require more
than two years of study at the associate level. But regardless of this, the goal is the same: to
provide a program of study that prepares the student for the upper level institution.
The following is a recommended software engineering program of study for implementation by
associate-degree granting institutions. Students who complete this program could reasonably
expect to transfer into the upper division program at the baccalaureate institution. Although
designed with the United States in mind, certain colleges in Canada and other countries may very
well be able to adopt a similar approach.
Proposed Software Engineering Technical Core for North American Community Colleges
For descriptions of the Computing courses and Mathematics courses listed below, see the report
titled Computing Curricula 2003: Guidelines for Associate-Degree Curricula in Computer
Science [ACM 2002].
Computing courses
The three-course sequence
CS101I ­ Programming Fundamentals
CS102I ­ The Object-Oriented Paradigm
CS103I ­ Data Structures and Algorithms
Or the three-course sequence
CS101O ­ Introduction to Object-Oriented Programming
CS102O ­ Objects and Data Abstraction
CS103O ­ Algorithms and Data Structures
SE201-int ­ Introduction to Software Engineering for Software Engineers
Institutions may also elect to create a software engineering curriculum based on the SE-
specific courses (SE101, SE102, CS103, SE200) outlined in Chapter 6 of this report
Mathematics courses
CS105 ­ Discrete Structures I
CS106 ­ Discrete Structures II
The following are to articulate with typical university requirements, and do not cover
core SEEK material
Calculus I
Calculus II
SE2004 Volume ­ 8/23/2004
See also the baccalaureate institution for requirements; some institutions may require
linear algebra or differential equations.
Laboratory Science courses
Two courses in lab science for articulation with most baccalaureate programs.
Recommended: Two physics courses, or one physics plus one chemistry course.
General Education
Students also complete first-year and second-year General Education requirements, along
with software engineering technical core.
Special programs
Because software engineering is such a new discipline, there is a significant demand for certain
types of special programs. Some people want to "retrain" in a new field. Others already have a
degree in a related field and want a "post-graduate diploma" in software engineering. The
curricula for such programs must take into account the previous education of the students as well
as their career goals.
It would be foolish to attempt to cram a whole undergraduate curriculum in software engineering
into a short retraining program or a one-year post-graduate program. Such an effort does not
serve the needs of these students. These programs are best when they have appropriate entrance
standards that require at least some practical experience. When this is the case, the students are
usually highly motivated. Such students are able to have their experience serve as a reasonable
substitute for some of the content that would normally be a part of an undergraduate curriculum.
SE2004 Volume ­ 8/23/2004