software products (MEDEE-S/ENV, EFOM/ENV and DBA-VOID) which are in use in 26 Asian and seven Eu- ropean 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 concen- tration in knowledge discovery, both from the Asian Institute of Technology in Thailand. His teaching involvement and research interest are in the areas of Software Engineering and Development (Verification & Validation) and Enterprise Resource Planning. He also has interest in Learning Objectives based Edu- cation Material Design and Development. Acharya is a co-author of ”Discrete Mathematics Applications for Information
concept, for example, in the computer science context, it would be developing a program to run the telescope, focusing on the program development cycle, with writing (editing) the code, compiling, executing, and debugging it experiment – this activity relies on enforcing the essential concept of scientific inquiry, which in the context of computer science would be testing the software developed for a telescope, with outlining test plans, conducting actual testing, and showing the test results project – this activity is typical to a full-fledged engineering process, that is, developing software in four stages, with formal (a) requirements, (b) design, (c) implementation, and (d
previouslyseen by all of the students, start up costs are minimal since students with experience using the toolshelp their classmates to learn them. As a result, the less experienced class members increase theirproficiency over the whole term. The instructor should also help to identify the target audience at the school for the visualizationtool. This should be done in collaboration with another instructor so that the students have a readyset of students who can act as subjects for a practical user study. The decision about the intendedaudience is important because it helps the students determine an appropriate test plan and keeps the Page
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
classroom (located at the second floor of the building).When the two groups were separated, their means of communication changed. They decided to use an instantmessenger to communicate throughout the workday but often found it difficult to understand one another. Toremedy the problem, the two groups set designated times for video chat meetings before lunch and beforeeach workday ended. After encountering some difficulties with this method, a leader was elected in eachgroup and the leaders were allowed to meet in person at the end of each workday to discuss the progressmade that-day and plans for the following day. The forced separation also introduced technical difficulties.Although the requirement for the project was identified and documented
softwareengineering curricula offered at the new La Salle University in Arequipa, Peru. The University’sinauguration took place on March 2012. As part of the new SWE program’s assessment, LaSalle University proposed a special software engineering 2014 winter program: SoftwareArchitecture and Computer Gaming Design. These two classes were a good medium for averification of the knowledge in the software engineering academic community (current SWEstudents, current SWE professors, alumni, and individual software developers). Page 26.1387.3The 2014 winter program was the result of three-year planning and collaboration effortsmanaged primarily by the SPSU and La
engineering in a degree program with a specialtyin “software engineering”24. As a result of that lawsuit, an independent panel was establishedthat proposed a new Software Engineering Accreditation Board (SEAB) for accrediting softwareengineering programs. The accreditation criteria and procedures of the new board were to bedeveloped jointly by the Canadian Engineering Accreditation Board (CEAB) and the ComputerScience Accreditation Council. However, after the two accrediting bodies had jointly drafted anaccreditation plan for the SEAB, the CEAB “recommended a number of significant changes tothe structure and curriculum requirements of [SEAB] without consulting the [CSAC]. TheCCPE subsequently passed a motion supporting the [panel] recommendations
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
that the Intermediate Software Engineeringstudents did so poorly on the snow plow example (the example that motivated this work) suggeststhat traditional methods were not working well, at least at UW-Platteville. An obvious futurestudy would be to evaluate performance on similar problems in introductory courses which do notuse UMLGrader. It would also be useful to re-evaluate students in upper-divisional courses nowthat students are using the tool in the introductory course on a regular basis.Additional work is being done on the tool. It currently supports diagrams created in IBM RationalRose and IBM Rhapsody. Work is underway to provide support for Enterprise Architect. Inaddition, we plan to add support for comparing state diagrams and
Page 23.1074.6acquire in-depth knowledge in an area of concentration. GRCSE includes two exampleconcentrations: Systems Engineering Management (SEM) and Systems Design and Development(SDD).The CorBoK was developed so that it comprises approximately 50% of the curriculum. Forpurposes of planning curriculum content, GRCSE estimates 480 hours as the total number ofcontact hours needed for a SE master’s program. Consequently, using the 50% guideline,CorBoK instruction is presumed to take approximately 240 contact hours. Table 2 provides anexample:• Approximate contact hours and percentages of the 50% devoted to CorBoK are provided for each part.• Since Part 3 represents a significant portion of the 50%, distribution by knowledge area is
Page 22.1091.5 project progress, changes in 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
Software in the IEEE Computer Society DVP program.Kristen Baldwin, Office of the Under Secretary of Defense (Acquisition, Technology, Logistics) Kristen Baldwin is the Acting Director, Systems and Software Engineering in the Office of the Deputy Under Secretary of Defense for Acquisition and Technology (DUSD(A&T)). She is the DoD focal point for all policy, practice, and procedural matters relating to systems and software engineering. Ms. Baldwin was named Deputy Director for Software Engineering and System Assurance in February 2007. Prior to OSD, Ms. Baldwin served as a Science and Technology Advisor in the Army’s Office of the Deputy Chief of Staff for Operations and Plans, and at
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
language, both for identifiers and libraries. This mechanism should allow users to specify identifier syntax and library classes. • Provide a course profile mechanism to enable or disable specific checks. • Revise how feedback is given so that issues appear as notes directly on the submitted diagrams. • Incorporate natural language processing tools to provide more semantic-oriented checks such as described in our previous work.19 For example, the tool could warn against using verbs to name classes. • Using metrics such as those surveyed by Genero9 to identify common design flaws such as concentrating all processing in one or two classes.As discussed above, we are also planning a careful evaluation of the tool’s
required of softwareengineers in the United States. A recent project put up for bid in the Rent-A-Coder web site(www.rentacoder.com) came in with qualified developers willing to take on the project for Page 15.934.3$0.15/hr USD2. A similarly qualified software developer in the United States cost $25.00/hr. Apoll taken in 2006 indicated that of all polled companies located in the Unites States, 61% weremanaging active software development outsourcing projects. Of this 61%, only 7% planned todecrease future software development outsourcing activities3. The economic downturn of 2009certainly impacted the software development outsourcing market
three energy software products (MEDEE-S/ENV, EFOM/ENV and DBA-VOID) which are in use in 26 Asian and 7 European countries by both governmental and non-governmental organizations. Acharya has a M.Eng. in Com- puter 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 involve- ment and research interest are in the areas of Software Engineering and Development (Verification & Validation) and Enterprise Resource Planning. He also has interest in Learning Objectives based Educa- tion Material Design and Development. Acharya is a co-author of ”Discrete Mathematics Applications for
end, our courseallows students to gain significant experience in the use of tools, allowing the students to beadaptable to using new tools they encounter.To allow students to make meaningful experiments with tools supporting SECs in the labclasses, the lectures of our course provide the SE context within which these SECs live. In thefollowing we discuss four principles underlying these lectures.3.1 Learning SECs in the overall context of software lifecycle modelsFundamental to SE is the notion of the software lifecycle (SLC). The SLC divides softwaredevelopment into distinct phases with the intent of supporting planning, management,deployment, and maintenance of software products. The selected SECs belong to one or more
audience of CS2is underclassmen who are planning to pursue a major in Computer Science and Engineering.Other popular majors of CS2 students include Business Administration, Economics and Statistics,as well as others working towards a Computer Science Minor. The only enforced prerequisite forthe class is an introductory programming course taught in C++.CS2 focuses on core computer science concepts and covers four major topics. First, functionalabstraction, including specification, recursion, iteration, and functional generalization. Second,data abstraction, including types, type hierarchies, abstract data types, abstraction andpolymorphism. Third, dynamic resource management, including creation, deletion, andinteraction with containers. Finally
outside of the application domain sequence. Thus, for any givenoffering of one of these courses, more than half of the students may be taking that course as atechnical elective without any plan of taking the other two courses in the sequence. Thisproblem is magnified even more by the fact that students of both the software engineering andcomputer engineering programs routinely take these courses as technical electives. This makes itmore challenging to offer these courses in a neutral manner.Scheduling is also an issue with these courses. Because of the small size of the programs, thesecourses are only offered every other year, resulting in a mixture of both junior and seniorstudents taking the courses. This results in significant differences in
,Verification and software reviews and testing, user interface testing and 42Validation evaluation, problem analysis and reportingSoftware Evolution Evolution processes and activities 10Software Process Process concepts and implementation 13 Software quality concepts and culture, standards andSoftware Quality 16 processes, process and product assurance Management concepts, project planning and control,Software personnel and organization issues, software configuration 19Management
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 of ASEE and ACM. Acharya is a recipient of the ”Mahendra Vidya Bhusak” a prestigious medal awarded by the Government of Nepal for academic excellence. He is a member of the Program Committee of WMSCI, MEI, CCCT, EEET, ISAS, AG, KGMC, and IMCIC and is also a member of the Editorial Advisory Board of the Journal of Systemics, Cybernetics, and Informatics of the International Institute
.” Another studentrecommended using a medium other than sticky notes for information exchange and stated,“perhaps find a better method than sticky notes, throw balls with numbers?” We plan to re-visitthe design of our game and our choice of materials in light of these suggestions, though movingaway from sticky nodes—a medium that is useful for quickly generating representations ofcustom messages—would reduce the game’s expressiveness. The second trend is that studentswere disappointed at some of the overhead involved in the initial setup of each style-specificgame; one suggested that participants be “given specific instructions ahead of time” and anotherthat we should “decide participants before starting the activity; this would decrease down time