integrated manner than currentpractice, and (b) to introduce team- and project-based software engineering activities in a lowrisk, high student involvement setting in order to create a smoother learning curve for students.This paper contributes: • A discussion of the learning theory foundations for our approach, based on experiential learning targeted at increasing student motivation; • A minimally disruptive framework for better integrating software engineering education within a computer science curriculum by elaborating our course design plan, and providing a description of areas that required particular care; and, • A presentation of quantitative and qualitative evaluation results, based on student surveys, evaluation based
andpractice for software development and covers software requirements, analysis, softwarearchitecture and detailed design.CS 5374 Software Verification and Validation. This course introduces how to implementeffective test and measurement programs as well as how to apply this knowledge to theproduction of low-defect software.IE 5329 Project Management. This course covers technical, organizational, andpersonnel project management examination including planning, estimating, budgeting,scheduling, resources management, and control. It also includes risk analysis andmanagement using software for project performance evaluation.IE 5320 Systems Theory. This course examines theoretical foundations of general systemstheory applied to engineering and
feature.Students find it easier to start on this assignment, since it builds on the previous assignment.Project planning is more difficult, although they have some WBS experience from earlier codingassignments and from the concept proposals in the non-technical sequence.3.2.3. DevelopmentSome of the proposed features turn out to be quite simple, while others prove to be quitechallenging; separating the analysis helps to identify features that present appropriate challengesbased on student background, ability, and other activities in the course. Ideally, students wouldadd one simple feature and then build something more complex; thus far, most students havedone one or the other. Recent examples include: ≠ minor changes to the phpBB bulletin board
Engineering (3) G * ‘C’ denotes Integrated lab component; & U – Undergraduate, G – Graduate; ** under development;3. Methods (Courseware) The overall goal of the EECE 6032 – Software Testing and Quality Assurance course was foreach student to understand the basic principles of software testing and quality, and their role incontemporary software engineering. An additional goal for graduate students was to examineresearch areas of interest, and be prepared to conduct research in software engineering in general.The ABET student learning outcomes of the course were:• To understand how to develop a test plan for a set of software requirements
was driven by the need to provide quasi-real timefeedback for students in project-based courses. In the Software Enterprise8,9 at Arizona StateUniversity, a project-based curriculum is offered to undergraduate and graduate softwareengineering students. In a typical project experience, students are grouped into teams, eachworking on building a software project by incorporating the principles of Agile. A course projectis typically divided into 4-5 sprints spanning 3 weeks each. The requirements for this projectedare accumulated into a product backlog created through a planning process. During each sprint,the team identifies a set of user stories from the product backlog and adds them to the currentsprint backlog. Teams then identify tasks to do
takes into consideration the cognitive knowledgeand skills needed at each stage of the process. The integrated model, called the Dual CommonModel (DCM), identifies for each problem solving/program development task, the specificcognitive techniques required to accomplish that task. A brief overview of the problem solvingtasks is as follows:1. Formulating the problem: This stage leads to an organized representation of all relevantproblem information: the goal, givens, unknowns, conditions and problem constraints.2. Planning the solution: During this stage, the user identifies and evaluates or assessesalternative possible solutions, and also partitions the problem by refining the overall problemgoal into sub-goals.3. Designing the solution: This
scope, changes in design, and defects.5. Assess risk, probability of the risk, triggers and formulate contingency plans.6. Construct a statement of work with appropriate acceptance criteria.7. Describe the relationship between Testing and Quality Assurance.8. Describe the Quality assurance practices appropriate for each part of the development life cycle.9. Create user based requirements and engineering requirements.10. Describe traceability and be able to map a requirement through all project artifacts.11. Describe different modeling techniques and where they apply.12. Describe the different architectural views and assign them to parts of the life-cycle.13. Asses risk and develop risk management plans
individualteam member. There exist at the personal level core software engineering competencies that needto be cultivated to allow an individual to fulfill their potential as an effective team contributor.Students in a course introducing team based software engineering typically possess adequateintroductory programming skills, but often lack other competencies required to execute asoftware project successfully. Students have rarely been introduced to concepts beyondprogramming, such as estimation and planning, continuous integration, detailed design,debugging and unit testing. Part of being a software engineer is the knowledge of multipleprogramming languages and tools; without such knowledge it is impossible to make intelligentengineering
engineering portion of the survey. SE1 I can list the high-level phases that comprise a software project in a real-world environment. SE2 I am comfortable that I could participate in the planning and development of a real-world software project. SE3 I can list the steps in the software process we used in HFOSS project. SE4 I can use a software process to develop an HFOSS project. SE5 I am sure that I can actively participate in an HFOSS community to develop a software project. SE6 I have gained some confidence in collaborating with professionals from a variety of locations and cultures. SE7 I can describe the impact of project complexity on the approaches used to develop software. SE8 I can describe the impact of
both governmental and non-governmental organizations. Acharya has a M.Eng. in computer technology and a D.Eng. in computer science and information management with a concentration in knowledge dis- covery, both from the Asian Institute of Technology in Thailand. His teaching involvement and research interests are in the areas of software engineering and development (verification and validation) and enter- prise resource planning. He also has interest in learning objectives-based education material design and development. Acharya is a co-author of ”Discrete Mathematics Applications for Information Systems Professionals,” 2nd Ed., Prentice Hall. He is a life member of Nepal Engineering Association and is also a member
(based on a web-questionnaire) was that about a half of the students were planning to use the wiki to preparefor the exam and also planned to use the material produced for the wiki later for their stud-ies. On the down side, they admitted that plagiarism and cheating is always a concern whencontent is shared. Their work also differs from our in that their personal learning diaries arepublic, whereas ours are private.Gillet et al. 4 describes a collaborative web-based experimentation environment introduced atthe Ecole Polytechnique Fédérale de Lausanne. A key component of this environment is theeJournal, a Web service that enables the collection and sharing of preparatory notes and ex-perimental results with both peers and teaching assistants. It
(0.75), Good (1.0), or Excellent (1.25). Therefore, if theyperform above and beyond the call of duty, they are rewarded. However, if their contribution ismoderate or lower, they will not receive full credit for the team project grade. For example, if astudent is evaluated as having a effort=Good, support=Moderate, attitude=Good, their PCF=(1 +0.75 +1)/3=0.9167. Table 1: Team grade point distribution. Team Grade 75 Quality 13 Team organization 10 Test/quality plan 3 Chemistry 5 Process document 2 Dynamic 5 Inspection
(specific tasks and deliverables are discussedin the next paragraphs). Therefore, teams carry out design, implementation, and testing in a muchsmaller scale than requirements analysis, as design, implementation, and testing are the focus ofother courses.The team project deliverables are shown in Table 2. Student teams receive fewer points forcompleting early deliverables such as finding a client and submitting their proposal (3%), andmore points for advance deliverables such as SRS and Test Plan (9%). A large part of the projectgrade (60%) comes from the final deliverables and presentation at the end of the semester.Table 2. Project Deliverables and timeline Deliverable Timeline
), the process (the activities and work done to create the product), and softwareengineering management (“planning, coordinating, measuring, monitoring, controlling, and reportingactivities to ensure that software products and software engineering services are delivered efficiently,effectively, and to the benefit of stakeholders”, SWEBOKv3, 7-1). Performance assessment falls withinthe area of software engineering management (SWEBOKv3, 7-9). To relate the idea that softwareengineering includes assessment of the product, process, and performance to education, we consider thelearning objectives for a course to be the product, the teaching techniques employed as the process, andthe individual student’s learning to be performance.In both disciplines
StructureThe CEN4072 course topics as stated in the catalog description are: test plan creation, test case Page 24.1115.5generation, program inspections, black-box testing, white-box testing, GUI testing, and the useof testing tools. The prerequisite for CEN4072 is data structures. The students in the course areevaluated based on three exams, a team-based project, and class participation. Details on the courseproject are provided in the next subsection.The material presented to students during the course is centered around black-box and white-boxtesting techniques.3, 18 The black-box testing techniques presented include: random, equivalencepartition
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
are hoping for better results in spring 2008, we will not know until then whether ornot other changes will be necessary.Besides changes to the curriculum, the assessment reports also recommend changes to theAssessment Plan itself. The Assessment Plan is modified almost every semester. As is typicalfor many software engineering process documents, revision changes are listed within thedocument itself.The ShoestringFaculty at other institutions have expressed a concern that outcomes-based assessment asmandated by ABET could require an inordinate amount of work. One colleague compared it tomonitoring the minutiae of every plant in a back-yard tomato patch: stem lengths, waterconsumption, tomato sizes, etc.1 So the question is not whether outcomes
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
Participate in team meetings– includingFind bugs in specifications making a technical argument in themRead someone else’s code Participate in a scrumRead training manuals Structure a plan for a small groupRead with a purpose (different purposes Collaborate with team members (rather than appropriate for different situations) competing as can happen in academe)Foraging for information Make the team’s goals your goalsRead e-mails Communicate across cultures— work with team members from cultures that doWriting
European countries by both governmental and non-governmental organizations. Acharya has a M.Eng. in Computer Technology and a D.Eng. in Computer Science and Information Management with a concentration in knowledge discovery, both from the Asian Institute of Technology in Thailand. His teaching involvement and research interest are in the area of Software Engineering and Development (Verification & Validation), Data Mining, Data Warehousing, Neural Networks and Enterprise Resource Planning. He also has interest in Learning Objectives based Education Material Design and Development. Acharya is a co-author of “Discrete Mathematics Applications for Information Systems Professionals- 2nd Ed
(take bold character) TB JM TB TB + N + TM (take bold character) TB N TB TB + TM (take bold character) TB TM TD A1 = TD (answer for topic A1 which is stated on the last column in Appendix) Page 14.112.8Page 14.112.9Page 14.112.10Page 14.112.11Page 14.112.12Page 14.112.134.2. Challenges to the validity of the studyThe survey conducted here faces possible challenges that may arise when it is compared to otherexperiments and case studies [25], even if it was planned with an adequate consciousness of suchchallenges
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
the international and globalnature of the Scratch project.The Scratch competition complements the Teaching Materials/Curriculum. In module ten, entitled“Scratch Project”, students create a concrete piece of work at the end of their in-class course. Inthis module, students must plan and design their project and, if working in teams, they must assignindividual tasks. Students are encouraged to submit this final project for the Scratch competition.According to teachers we work with, many students spend time working on their Scratch projectsfor the competition outside school hours. This encourages an independent interest in computingand “I’m doing it because I want to” rather than “I’m doing it because the teacher says I must”attitude. By the
beginning to critically analyze the problem scope. The team members thenshare their ideas for use cases. A vote commences to determine the direction that will befollowed. Now that the team has agreed upon direction, the scope of this direction is refinedwhere detail is added to use cases for phase 2 and a design class diagram is the output of phase 3. Page 25.106.4In the remaining four stages of the CCM the team would be translating the plan into a detaileddesign, implementing the design, testing, and finally delivering the solution. Working throughthe first two stages of the CCM, the team is able to conceptualize the problem resulting in a
, why are SCRUM and Agile methods not connected? RiskManagement is more than just a Process Component based on contingency planning. SoftwareMaintenance does not “ensure correct functionality” for Testing, and so on. One could look atthe sub-graphs here and like the structure, but would need to evaluate semantically to see if thosestructures made sense.4 Assessment Protocol and ResultsOur assessment protocol was as follows: Page 25.213.7Figure 3. Software Process and Project Management concept map1. Expert evaluators were recruited from the software engineering faculty.2. The evaluators were given a short pre-briefing that included reviewing the
II: Code Maintenance1.5. Explain code maintenance practices of your team (give details about version control and associated tools)? How often did you update, commit and/or merge, and build?1.6. Explain the release cycle of your team. How were releases made to customers? How often did customers receive releases?1.7. When did you first learn about version control? After learning to do version control, how did it change your views on maintaining code?Examination:2.3. Share the kinds/levels of tests you wrote as a part of this course. Give specific examples, if any, of how tests found bugs in your code?2.4. What did you learn from writing test cases and test plans?2.5. What are your thoughts on code maintenance and release cycle
, describes the project, and connects these concepts to studentlearning and a summary of the outcomes.2 Software engineering foundationSoftware engineering is a vast collection of theory and practice with the goal of producing thehighest-quality software at the lowest cost. It shares many characteristics with traditionalengineering design processes, but for the purposes of this work, the following elements are theemphasis. In particular, this course promotes the Agile methodology, which is supposed toachieve the same results without imposing onerous, administration-heavy overhead.1 Agile is nota substitute for proper planning and execution, however, so this freedom demands discipline,which is generally lacking in students at this stage of their
the series accounts for the fact that in some offerings we did not use anadditional text and/or targeted handouts.Other problematic areas are quality assurance and testing, build processes, and documentation.Table 1 shows the class-average ratings for those over the 8 terms. Page 12.198.8Table 1. Class-average ratings of problematic areas over all 8 terms. “n/a” in a given cellindicates that we did not ask about the corresponding aspect in that term’s questionnaire. Term 1 Term 2 Term 3 Term 4 Term 5 Term 6 Term 7 Term 8Test plan n/a n/a n/a n/a 0.46 -0.14 n/a 1.14Test