be considering employer surveys for this purpose.Program Educational ObjectivesIn 2000 the faculty established a set of educational outcomes for the program. They werefirst developed by the department faculty. Near the end of that academic year wesurveyed all of our MSSE alumni and the members of our Industrial AdvisoryCommittee, asking them to comment on the appropriateness of objectives and requestingsuggestions for improvement. We received numerous responses and modified theobjectives using that input. The resulting list of objectives follows.The BSSE program alumni will, within the first three to five years after graduation, 1. Become members of organizations that develop or use software and/or enter graduate school
problem and then write the software requirements specification (SRS)document. Since the SRS serves as the basis for design, testing and maintenance of the softwareproduct, the students are expected to follow some standard such as IEEE 830-19981 whiledeveloping the SRS. A sample functional requirement in IEEE standard format is shown inFigure 1. Index: ATM.2 Name: Deposit Purpose: To deposit an amount into an account Priority: High Input parameters: account number, amount Output parameter: None Action: Ensure that account number exists. Ensure that amount is greater than zero
presentations. All necessary clarifications orreclassifications of data were resolved during these weekly status presentations.Each software project team was graded on the basis of the following criteria. - meeting the functional requirements - meeting the schedule (both intermediate and final) - monitoring the project effectivelyThe teams may earn similar letter grade such as B, but they were also given numericalgrades to retain a finer level of granularity. Project team success is defined in terms of theproject team grade, and the numerical grade served as the measuring scale for success.The following are the specific questions that we will address in this paper. 1. Does the amount of communications affect
! Thesubsequent semesters’ results were less gratifying, but were still an improvement over the resultsfrom previous semesters.The percentages of students in CSSE2-II earning each grade from the past nine semesters areshown in Table 1. Figure 1 shows the same data as a stacked bar chart. The last five semestersincorporated the new techniques. It should be pointed out that the instructors varied fromsemester to semester, but all have a history of similar grading styles for the different courses thatthey teach. # Term A B C D F W C or Better Students F01 12.2% 12.2% 24.5% 4.1% 22.5
philosophy. This paper is meant to start a debate in the SE education community on whether the issue is the philosophy itself, its implementation or how we are measuring (or not measuring) “success”. This paper most likely raises more questions than it answers.1. Introduction When the term “Software Engineering” was coined in 1969[10], the software developmentcommunity recognized the fact that production of software is a complex undertaking. SoftwareEngineering (SE) educators have been struggling since then to provide opportunities in anacademic setting where the students can apply SE practice and process to realistic developmentefforts[13]. According to Humphrey[4] the concept of software process is not so much concernedwith particular
by the students outsidethe classrooms. (c) The students were encouraged to apply and integrate their knowledgefrom other subjects. PBL has been adopted in teaching software engineering,1, 3 first-yearCS courses,9 and programming.12 This paper presents our findings in using both competition and collaboration. Eachstudent filed a weekly report about the amount of time spent on the project, overall satis-faction with the project, the evaluations of the other team members, and suggestions aboutthe course. To encourage the students to report accurate amounts of effort, the reportednumbers were not used for grading. We learned the following issues in this course. (a)Competition is a strong motivator; hence, collaboration within each team is
levelization. If a file is welltested and believed working, it is labeled as level zero. Standard C header or library filesare examples of level-0 files. A file is level n if the file needs files of level n − 1 or smaller forcompilation or linking. Cyclic coupling is considered as a sign of inferior design. Arisholmet al.1 point out that static analysis of codes coupling cannot be directly applied to object-oriented software due to polymorphism and run-time binding. Thus, they analyze dynamiccoupling of object-oriented software. They discover that dynamic export coupling can be aneffective indicator of change proneness. Basili et al.2 classify errors into several types such as incorrect requirements and misun-derstanding of the environment. The
why SEs must be able to developthem, are not covered in the current work; readers interested in these topics are encouraged to seeprevious papers by the author and his colleagues1, 2.The purpose of this paper is to present and discuss the process used. To that end, all the keymethods applied are presented: (1) introducing the BE client teams to requirements, (2) clientteam project presentations to the requirements teams, (3) team training, (4) the four assignments,(5) interim general meetings for process review, (6) informal reviews of work in progress, (7) agroup presentation rubric, (8) a final report rubric, (9) student self-assessment of courseoutcomes, and (10) student feedback on the course
similar to that used to specify any other type of software product. However, unlikemost software products, games have an entertainment dimension. People play computer gamesbecause games are fun.8The International Game Developers Association (IGDA) proposed a curriculum framework foruniversity level training in game development.5 The core topic areas from the IGDArecommendations appear in Table 1. Many of these topics involve the application of skills taughtin software engineering courses. Page 11.660.2 Table 1: IGDA Curriculum Framework Core Topic Key Elements Critical Game Studies game
a requirement of graduates ofbaccalaureate software engineering degree programs. This paper will examine how the ABET-accredited software engineering degree programs have implemented these application domaintracks.1. Introduction Every software product is intrinsically tied to a particular application area. Over the years, asboth the quantity and processing power of computers increased while their relative cost hasdecreased, the number of domain areas for which software is developed has continuously grown.The advent of undergraduate software engineering (SE) degree programs in the United States –all but one of them having started since 19995 - has caused the stakeholders in the SE educationcommunity to consider how to ensure that
toorganize, add to, and manage the learning content, promises to significantly improve the Page 11.1261.3collaborative learning experience. It promises to allow students and teachers to “gather aroundgreat things in a complex and interactive community of truth.”1 However, this ability may comeat a cost: the added level of cognitive engagement and workload to describe, organize, andmanage the information, and the potential information overload of having too much informationavailable at once. The eNotebook system will provide features that enable it to be used as atestbed in which to conduct experiments to assess the benefit and cost of the tool in
Systems, Man and Cybernetics, Part C, and has served as a program committee member for many international conferences. Dr. Wang is a senior member of the IEEE. Page 11.1065.1© American Society for Engineering Education, 2006 Real-Time Systems Scheduling Tool DevelopmentAbstractThis paper presents a real-time system (RTS) scheduling tool which implements some of themost popular scheduling algorithms. It allows users to specify real-time tasks in a RTS, thenevaluates task scheduleability and plots the simulated schedules. It can be used by bothinstructors and students of RTS classes.1. IntroductionReal-time systems are
integrate knowledge gained from the required core courses offered in afour-year period. According to CC2001 1, this course is supposed to cover software systemdesign, software processes, key activities in software development lifecycle, and software projectmanagement. The traditional approach to teaching a Software Engineering course, as reflected inclassical textbooks 11, 10, usually starts with an introduction to software process models, which isthen followed with discussions on highlevel activities in various phases of a generic softwarelifecycle template that can accommodate all possible programming paradigms. Although updatedmany times since their original editions, those texts are not well adapted to the latest paradigmchanges (such as object
the Software Engineering Body ofKnowledge project (SWEBOK) 1 was released, so SWEBOK provided the initial framework forthe project. The module categories in the prototype web site – design, process, quality, andrequirements – corresponded directly to major focus areas of SWEBOK. Page 11.1125.2More recently, the Computing Curriculum in Software Engineering (SE 2004) 2 became availableand influenced the development of the SWENET project. SE 2004 gave rise to a more detailedbody of knowledge for education. This software engineering education body of knowledge (orSEEK) had the advantages of (a) relating directly to the mission of SWENET, and (b
, accreditation is a stamp of approval that says your department is successful atmeeting its goals and has an established process for continual improvement. To be able to showthis you must use assessment to collect the data, evaluation to analyze it, and incorporate theresults to improve your program.The importance of the role of process in software engineering, and of continual processimprovement as we teach in CMM and now CMMI, is a deep thread running through ourcoursework. Yet when trying to apply those very same concepts to software engineeringeducation, which is what accreditation is really doing, we realized we had been operating atCMM Level 1, with a set of undefined processes. We did not have stated program goals and wewere not assessing how our
systemsengineering activity, understanding those activities and their role in systems engineering are vitalfor software engineering education.The addition of systems engineering activities in and embedded software course has led to manysuccessful outcomes. Students understand the approach for solving complex systems. They alsoobserved first hand the benefits of modeling a solution before committing to an implementation.In fact, student remark that once their model is correct, building for the target platform isrelatively simple. Finally, the value of showing UML notation and the various diagrams in thecontext of systems development is vital for students, as these activities are becoming common inthe systems engineering community.1 IntroductionSystems
better appreciation of the need for software security and a basic understanding of how todevelop secure software. However, finding the time required to cover software security effectivelyremains a considerable challenge, especially as both institutions only offer a single semester ofsoftware engineering.IntroductionApplication software has become highly interconnected as the Internet and wireless networkinghave grown in importance. While security flaws were previously exposed only to users sittingin front of the computer, the Internet allows attackers from around the world to exploit securityvulnerabilities in networked applications. Even embedded systems like cell phones are vulnerableto remote attacks.1 This increased exposure to attack has
thisknowledge. A typical conversation an interviewer might have with a graduating student mightbe “well, yes I did a few use cases in my Software Requirements class, but no I have not doneone of that size nor do I understand how to use that model to drive analysis and test planning.”This paper presents an alternative approach underway at Arizona State University’s Polytechniccampus. In this approach, students are accelerated through the knowledge, comprehension,application levels through a hybrid teaching and learning model that combines multiplepedagogical approaches with a process-guided exposure to software engineering.1. The Software Enterprise: An OverviewIn the Division of Computing Studies (DCST) at Arizona State University’s Polytechnic Campus
Date{}sig BirthdayBook { known : set Person, // those persons known in this book dates : Person -> Date // the birth day for each known person}Here we have defined three signatures, Person, Date, and BirthdayBook, along with two Page 11.616.2relations, known and dates. The signature declarations implicitly state that the three underlyingsets of atoms partition the universe of all atoms (that is, the three sets are pair-wise disjoint andtheir union is the universe). At the modeling level, however, all that exists are relations – Person,Date, and BirthdayBook are really unary relations, containing a 1-tuple for each of the