computing curricula in a varietyof ways. Authors have written about integrating software testing throughout their curriculum andusing software development methods such as Extreme Programming2, 3, 4. Papers have beenwritten on how some software engineering techniques, such as pair programming, can helpincrease retention, particularly of female students7, 8.This paper suggests that other software engineering practices can be used to help increase thesuccess rates in lower division courses, which should translate into increased retention rates. Inparticular, use of detailed work plans and periodically monitored time logs and version controlcheck-ins is examined. The underlying assumption is that students need to be encouraged to startprograms early
fall quarter in order to plan for their transition in to the SDL.Some of the topics that are covered in these presentations are (i) the role of the SDL in thecurriculum, (ii) the differences between SDL and the other classes they have taken so far, (iii) thetools/processes currently being used in the lab and, (iv) the current status of various projects andtheir related technologies. After these presentations, the juniors complete a survey of their skill sets and preferences.Instructors use this information to form new teams. Team assignments are based on individualpreferences, skills and attitudes in an attempt to form diverse and balanced teams. The seniorstypically prepare a plan for the new team’s first cycle. The lab processes that are
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
a 1997 task force report onengineering education assessment6. Maxim7 has provided an excellent overview of onesoftware engineering program’s plan to assess their program.Criterion 2 of ABET’s current criteria for accreditation of engineering programs4 requiresthat, “Each engineering program for which an institution seeks accreditation orreaccreditation must have in place: (a) detailed published educational objectives that are consistent with the mission of the institution and these criteria Page 11.1384.2 (b) a process based on the needs of the program’s various constituencies in which the objectives are determined and periodically
, and being able to recover missing artifacts.The Kepler project12 is studying the use of digital libraries for individuals and smallcommunities, bridging the gap to digital libraries for large organizations (universities,companies, etc.). Kepler enables users to self-archive content and provide a federated access tocontent published by a group of collaborators. The Kepler vision has influenced the eNotebookvision, and we plan to re-use some of its open-source implementation in our implementation.Early work on electonic engineering notebooks, such as the SHARE project at Stanford,13showed the value of electronic capture and sharing of information in collaborative productdevelopment. The Design Space Colonization project at Stanford is now going
able to add a review of the requirements document (generally done by a reviewer other than the requirements writer). These reviews are stored within the tool for later analysis. Page 11.61.9LimitationsThe Napkins tool is currently used by the students in Software Engineering courses at theundergraduate and at the graduate level. The requirements editor is more or less complete eventhough it has a simplified version of IEEE standard format. This is because the tool is designedprimarily for the students in Software Engineering courses. If the tool is planned to be used foractual software development, it needs to be extended to include
down theirresearch and development funding. In addition, the parents of students were moreconcern about how they support their children education, and what their best return onthe educational investment is. As a result we see the following trends;‚ Not enough interested student. Enrollments in undergraduate United States computer science and related programs have declined rapidly. According to an analysis of survey results from the Higher Education Research Institute at the University of California at Los Angeles10; in 2000, 3.7% of entering freshmen said they planned to study CS; in 2002 it was 2.2%; in 2004, 1.4%. This is a 60% decline over the four years between the Fall of 2000 and 2004. A similar trend is seen in other CS
software product. The minimum costs incurred by a failed game development projectranges between $150,000 and $750,000.13 Producing high-quality software products by largeteams requires high levels of communication, organization, and planning to avoid costly delaysand failures.Game developers are beginning to understand that it is important to treat computer game designin the same way that other software engineers approach projects involving a large number ofpeople and a significant investment of time.13 Game developers are likely to benefit from usingevolutionary software process models to mange their development risks and reduce their projectcompletion times. The process of determining the technical requirements for a game softwareproduct is
would be compatible withthe general requirements for the ABET Engineering Accreditation Commission. Once again,application domain electives were suggested. In 1997-99, the Working Group on Software Engineering Education and Training(WGSEET) developed the Guidelines for Software Engineering Education3, which subsequentlybecame the de facto source for undergraduate software engineering curriculum models for thenext several years. This was perhaps the first curriculum model to state that there should be arequired “Application Domain Component” in a software engineering curriculum. By 2002, asurvey of U.S. software engineering degree programs stated that “Many of the degree plans alsorequired the student to take three or more courses in a
SWENETproduced modules that contain both data and examples. But there is still a pressing need formore extensive case studies that can be used to provide students with a better understanding ofthe full software life cycle. It is particularly important that materials that work with a realisticsize system be developed. Page 11.1125.5Permanent home - Maintaining SWENET as a volunteer effort is probably a weak model forthe long term. Planning underway to have the site taken over by one of the computingprofessional societies is essential to maintaining the project and making it more visible. Thisconnection will also help provide career value to participation
beat this strategy. The contest committeedecided that it was too late to change the rules and forbid this strategy. This team wonthe final competition. In the future, we intend to improve the game strategies in two ways.First, we plan to change the rules so that, when there is no legal move by one player,the other player has to move within five minutes. Second, in spring 2005, the referenceplayer for qualification selected a legal move randomly. All teams successfully defeated thereference player and entered the final competition. We plan to improve the intelligence inthe qualification process. If this player is more intelligent, the students will have to improvetheir strategy in order to qualify for the competition. In Lawrence’s study,13 a
four team members. These were relatively small teams where onemight wonder if communications is an important factor as in large software projectteams. While each team developed slightly different solutions, the project problem wasthe same. In other words, they were given the same requirements. The tools and processutilized by these teams were also very similar. Each team essentially performedrequirements analysis, detailed design and code, and unit and functional testing. They allperformed three major activities related to direct software development. In addition, eachteam prepared a project plan, presented a weekly status report, and a final project report.This set is considered indirect activities.Three basic forms of communications were
potential forsome upgrades and modifications. Below is a list of items that have yet to be fully supported,but have limited functionality in its current state: ‚ GUI Validation: Basic task parameters are verified (no negative numbers or characters), but the logical correctness of these values are not validated by the system. It may be desirable to provide the user with a warning message if they select values that are logically incorrect, e.g. a period that is shorter than a task’s duration. ‚ Simulation Pause/Restart Capability: The initial design planned for this capability Page 11.1065.10 however it was not fully implemented in
efforts must define strategies forreleasing new versions of the system, how those versions will be deployed, and how runningsystems will be upgraded. As with concurrent development, component-based designs provideassistance by partitioning the system. But system engineering must formulate a plan for thesystem’s lifecycle.3 Curriculum modificationThis section defines course modification made to an existing embedded devices course offeredeach spring in the Division of Computing Studies at Arizona State University’s PolytechnicCampus. The first offering began in spring 2002 and the modifications were implemented inspring 2004 and 2005. Those modifications drove several faculty discussions involving thehardware and embedded program offerings
window.They noted that the need to establish a timeline was presented during the team training, but thatthe professors should have emphasized this point even more heavily. Additionally, the SEs werecurious about how useful their documents were to the BEs. The author passed along to thestudents that many of the BE teams had used the requirements artifacts and had given credit tothe SEs in funding proposals they had recently submitted. The other SE instructor noted that, inindustry, requirements engineers often wonder how their document is used during development,implementation, and testing; sometimes the document is not used sufficiently. Thus, the SEfaculty plan to follow up with the BE faculty and students in the coming quarters to determine
instead of providing features. The techniques for analyzing, designing,and testing functional features of software often are not effective for addressing the security levelof software. This section details adaptations and additions we made to the software development Page 11.792.3process in our software engineering courses in order to help students learn how to produce secureapplications.Secure Development ProcessThe development process begins with team organization and planning. Teams of 8-9 students areassembled. Roles and responsibilities within the team are assigned including that of InformationSystems Security Officers (ISSOs.) A team