Curriculum Management System

Curriculum Management System Page 1
Project Charter
Project Name: Curriculum Management System

Date: September 07, 2014
Version: 1.2

Author: Taon, Katyalyn S.
Guimayen, Deryl Joe
Tolentino, John Paul
Borbe, Kenneth
Morales, Jemarie



Document Control
Change Record
Date Author Version Change
Reference
07/03/14 Guimayen,
Deryl Joe
1.0 Started
09/04/14 Guimayen,
Deryl Joe
1.1 Update some
information
09/05/14 Taon,
Katyalyn S.
1.2 Finalize

Reviewers
Sign Off
Date
Reviewer Position Sign Off
09/06/14 Project Charter Project
Manager
09/07/14
09/06/14 Project Charter Document
Specialist
09/07/14

Distribution
Copy
Number
Name



1 Project Background
1.0 Background of the study

1.1 Problem/Opportunity Description
As from my research most of the school right now uses paper-
based on curriculum planning and isolated within individual departments.
Lack of a centralized system for curriculum planning has limited the ability
of the Curriculum Committee to assess existing coverage of certain topics
within the curriculum. This is one of the reasons of the difficulties on
developing and managing curriculum.

1.2 Benefits
Computerization of the system
Simplified transaction
A centralized curriculum
Enabling remote access to curricular materials.
Community-based faculty would be able to easily access learning
objectives in order to be able to assess the level of instruction which may
be required by students under their supervision.
1.3 The Goals
The main goal of the system is to help the curriculum management system
aiding their main function in giving systemizing transaction for easily

provide information on the subject descriptions, subject codes, requisites
and prerequisites of a school. . Aid faculty in course design, maintenance,
and planning.

1.4 Stakeholders and Clients
Faculty Proposer (a faculty member who prepares proposal)
Departmental Curriculum Coordinator (DCC) ( a staff member who
prepares proposals)
Department Chair ( Curriculum Chair for a Department)
Dean ( The department that will be affected)
Project team (Project manager, System analyst, Developer)


2 Project Scope
2.1 Objectives
Provide a centralized, easily accessible source of information about
curriculum content. Provide reliable and easily accessible
centralized storage of curricular content. Provide a single source of
information and a simplified process for providing data.
create a system that is easy and user friendly to the end user to
manipulate transaction faster and effective.
To develop and manage any number of courses and course events.
To establish a process through which curriculum is implemented,
reviewed, evaluated, and revised on a regular cycle.
Assign competency domains and disciplines to courses and
associate them with learning objectives to allow full curricular
mappings.
Course replication and rollover from one academic year to the next.
Share curricular information via xml / web services with other
standards-compliant systems.
Create robust reports from controlled curricular data.
2.2 Deliverables
A deliverable is any tangible, measurable outcome of a project. An
objective may consist of a single deliverable, or it may contain a
series of deliverables.

Objective 1 name of objective from Section 2.1

Project Deliverable Work Products/Description



2.3 Out of Scope
List items that may be related, but will not be managed as part of
this project. Consider listing items here that are:
Track distinct teaching hours by course part, category, and
objective.
Teaching hours tracking and management by instructor,
department, educational method.

Create and manage groups and sub-groups of learners for
the curriculum.
Assign default instructors and locations to groups and
sub-groups within any cohort of learners.
Create and manage groups of instructors.
Create and manage any number of unique programs within
your authorized institution.


3 Project Plan
3.1 Approach and Methodology
In order to develop a curriculum management system, it is
necessary to be based on the practice of a current system as well
as identifying the needs and requirements of the future working
environment.
It began with planning then analyzing the current process of the
system and the possible changes in the future. After analyzing, the
curriculum coordinator must assigned a school-based administrator
to recommend policies and rules that relate to curriculum
development; Identify system-wide curriculum development goals
and priorities related to student achievement; Provide leadership in
the development and monitoring of the Curriculum Frameworks.
Design:
Implementation:
Maintenance:
3.2 Project Timeline
I
D
Task Name Start Finish Durati
on
1 Interviews 2week
s
2 Project proposal and project
teams
1week
3 Formulate scope, objective and
project plans
1week

4 User, software and hardware
requirements identification
2week
s
5 System design 3mont
hs
6 System testing 2week
s
7 System testing revisions 1mont
h
8 System proposal to the
user/company
1week
9 System deployment
w/debugging
1mont
h
1
0
Project closeout

3.3 Success Criteria
3.4 Issues and Policy Implications
3.5 Risk Management Plan
Identify any factors that can affect the outcome of the project
including major dependencies on other events or actions. These
factors can affect deliverables, success, and completion of the
project. Record anything that can go wrong.
Define how risks will be identified and the process for escalation.
Identify the expected risks to which the project will be exposed.
Assess the likelihood of each risk occurring (probability) and its
impact on the project. Outline a plan for managing the risks; include
risk-minimization measures and contingency plans for recovery and

damage limitation. Rate each risk probability and impact as H(igh),
M(edium) or (L)ow.

Risk Factor Probabil
ity
(H-M-L)
Impact
(H-M-L)
Risk Management
Action
Consignors
agreement

Product loss


4 Technical Features
Provide a broad description of the features of the proposed application,
database, or technology. If specific products are being considered or have
been selected, please indicate. Also indicate whether you technical
direction is consistent with our PS standards.

5 Project Organization and Staffing
Using the template provided, an organization chart, or both, list the roles,
names, and responsibilities of individuals that will be involved in the
project. If appropriate, include percentage of time and start/end dates.
Include as appropriate, the project governance. To whom does the project
manager report? What group or individuals make recommendation? Who
makes the final decisions for the project?
Define a decision escalation process.
ROLE NAMES & CONTACT
INFORMATION
RESPONSIBILITIE
S
TIME
Executive
Sponsor
Serve as
ultimate authority
/ responsibility
for the project
Provide
strategic
direction and
guidance
Approve
changes to
scope
Identify and
secure funding

Project
Sponsor
Make
business /
approach


decisions for the
project
Participate in
key activities
Make
resources
available
Approve
work products,
address issues,
and approve
change requests
Project
Manager
Report to
and receive
direction from
sponsors
Manage,
review, and
prioritize project
work plans
Provide
status reports
Manage
project team
Recommend
changes,


escalate issues,
and mitigate risks
Project Team
and Members
Participate in
project activities,
including planning,
implementation of
deliverables, and
quality control

Advisors and
Resources


6 Project Budget
Using the separate MS Excel Project Budget template, estimate the
project costs. Include one time and permanent costs for personnel,
consulting, hardware, software, and other costs (training, consultants etc.)
as applicable.

Budget Item Description Budgeted Cost
One-Time Costs
One-time item 1 Description
Total One-Time Costs
Ongoing Costs
Ongoing item 1 Description
Total Ongoing Costs

7 Appendix A- Additional Information
Additional relevant information may also be included in this request. This
information will be used to decide if 1) the project request is approved to
move forward to the project charter phase and 2) the project charter
receives approval as an approved IT project.


CHAPTER 2 RELATED STUDIES AND SYSTEMS
2.1 Foreign Studies
2.1.1 Kansas State University
Background of the study
Information Systems is the study of applying Information Technology to
managing information and enabling communication and commerce. Under
this curriculum, IS majors will learn to build and administer computer
networks, web servers, and enterprise information systems.
Programming skills, as employed by system developers and
administrators, are included in the program. Students participate in an
internship-and-coursework program that provides background and
project work in an application domain where information systems are
applied professionally.
Internet-based information retrieval, communication, and
commerce, via courses on web page development, web-interface
design, and enterprise information systems
Systems administration, through courses on computer engineering,
computer architecture, telecommunications, and systems
administration
Software development, via courses on scripting, object-oriented
programming, data structures, and software architecture
Communication with clients and colleagues, through a
communications course sequence and the internship-and-
coursework program
The IS degree qualifies a graduate for positions in firms that require
database administrators, enterprise-information-system developers and
administrators, web-server developers, and software programmers/

engineers. This curriculum is consistent with the ABET criteria for
Information Systems.
Curriculum Requirements (124 hours)
Core Courses (19 hours)
CIS 115 Introduction to Computing Science (3 hours)
CIS 125 Web Page Development (3 hours)
CIS 200 Fundamentals of Software Design and Implementation (4
hours)
CIS 225 Personal Computer Systems Administration (3 hours)
ECE 241 Introduction to Computer Engineering (3 hours)
CIS 300 Data and Program Structures (3 hours)
Advanced Courses (14 hours)
CIS 308 C/C++ Programming Laboratory (1 hour)
CIS 415 Computers and Society (1 hour)
CIS 501 Software Architecture and Design (3 hours)
CIS 525 Telecommunications and Data Communications Systems
(3 hours)
CIS 551 Computer Security (3 hours)
CIS 562 Enterprise Information Systems (3 hours)
Specialization Courses (6 hours)
Two courses (6 hours) from
CIS 450 Computer Architecture and Operations (3 hours)
CIS 526 Web Interface Design (3 hours)
CIS 527 Enterprise Systems Administration (3 hours)

Information Systems Environment Courses (16 hours)
CIS 595 IS Cooperative Internship (4 hours)
CIS 597 Information Systems Project (3 hours)
9 additional hours of courses in an application domain where
Information Systems are employed (9 hours)
Quantitative Courses (6 hours)
MATH 205 General Calculus and Linear Algebra (3 hours)
STAT 325 Introduction to Statistics (3 hours)
Communications Courses (11-12 hours)
COMM 105 Public Speaking IA (2 hours)
COMM 106 Public Speaking I (3 hours)
Three courses (9 hours) from
COMM 322 - Interpersonal Communication (3 hours)
COMM 326 - Small Group Discussion Methods (3 hours)
LEAD 212 - Introduction to Leadership Concepts (3 hours)
MANGT 420 - Management Concepts (3 hours)
MKTG 400 - Introduction to Marketing (3 hours)
THTRE 261 - Fundamentals of Acting (3 hours)
THTRE 265 - Fundamentals of Improvisation I, II (3 hours)
Writing Courses (9 hours)
ENGL 100 Expository Writing I (3 hours)
ENGL 200 Expository Writing II (3 hours)
ENGL 417 Written Communication for the Workplace (3 hours)
Humanities and Social Sciences (18 hours)
ECON 110 Principles of Macroeconomics (3 hours)
15 hours taken from the list approved by the College of
Engineering. These courses must be chosen so that the K-State 8

requirements are satisfied. (15 hours)
Natural Sciences (3 hours)
Must satisfy the K-State 8 Natural and Physical Sciences requirement.
Unrestricted Electives (21-22 hours)
21-22 hours of additional coursework. A total of 124 hours are required for
the BS degree.
Changes from Previous Curricula
The following courses are no longer required:
-CIS 015 Undergraduate Seminar (0 hours)
-CIS 362 Introduction to Business Programming (3 hours)
-MATH 312 Finite Applications of Mathematics (3 hours)
-CMST 135 Web Page Development I (3 hours)
-CIS 301 Logical Foundations of Programming (3 hours)
-CIS 540 Software Engineering Project I (3 hours)
-CIS 543 Software Engineering Design Project (3 hours)
-CIS 450 Computer Architecture and Operations (3 hours)
-CIS 526 Web Interface Design (3 hours)
-ACCTG 231 Accounting for Business Operations (3 hours)
-ENGL 516 Written Communication for the Sciences (3 hours)
-Natural Science elective (3 hours)
-Technical electives (6 hours)
-Humanities/Social Science elective (3 hours)
-Natural sicence electives with laboratory (8 hours)
The following courses have been added to this curriculum:

+CIS 125 Web Page Development (3 hours)
+CIS 225 Personal Computer Systems Administration (3 hours)
+CIS 551 Introduction to Computer and Information Security (3
hours)
+CIS 595 IS Cooperative Internship (1-4 hours)
+ENGL 417 Written Communication for the Workplace
+Communication electives (6 hours)
+Unrestricted electives (1 hour)
+IS Specialization electives (6 hours)
+IS Environment electives (9 hours)
Notes:
[New] IS specialization electives. Any 2 of the following:
CIS 450 Computer Architecture and Operations (3 hours)
CIS 526 Web Interface Design (3 hours)
CIS 527 Enterprise Systems Administration (3 hours)
[New] Information Systems Environment electives. An approved
sequence of 9 hours in an application domain where information systems
are employed.
[Modified] Communication Electives. 9 hours chosen from the
following:
COMM 322 - Interpersonal Communication (3 hours)
COMM 326 - Small Group Discussion Methods (3 hours)
LEAD 212 - Introduction to Leadership Concepts (3 hours)
MANGT 420 - Management Concepts (3 hours)
MKTG 400 - Introduction to Marketing (3 hours)
THTRE 261 - Fundamentals of Acting (3 hours)

THTRE 265 - Fundamentals of Improvisation I, II (3 hours)
https://www.cis.ksu.edu/programs/undergrad/is
2.1.2 Ilios curriculum management from UCFS
The Ilios Curriculum Management System addresses the needs of the
Health Professions educational community by providing a user-friendly,
flexible, and robust web application to collect, manage, analyze and
deliver curricular information. Built by and for the health professions, Ilios
supports the sharing of curriculum outcomes and materials among
programs, departments, schools and institutions, while maintaining the
flexibility to accommodate the unique practices within our diverse health
professions community. ROBUST: Ilios provides a flexible yet structured
model for mapping your curriculum across all years of training.
MULTI-SCHOOL: A single Ilios deployment provides for any number of
locations or campuses, regardless of distinction in curricula.
MULTI-DISCIPLINARY: Ilios allows for the creation and development of
curricular material structured across any number of disciplines and
programs.
INTER-PROFESSIONAL: Ilios is designed explicitly to provide IPE
support across the health professions.
STANDARDS COMPLIANT: Ilios is built to meet the MedBiquitous and
AAMC specifications for Health Professions Curriculum standards.

Ilios creates a longitudinal and historical view of curricula by tracking
events, learning content and activities over time. The system facilitates
day-to-day administration and delivery of program, course information and
materials to learners, curricular development, review and innovation, while
greatly reducing overhead for internal and accreditation reporting. The end
result is a unique and powerful tool to create complete and accurate
pictures of complex, integrated, multi-year curricula.
Ilios manages and tracks both learners and instructors and their
relationships to curricular materials and activities, which enables the
tracking of educational hours, roles and role transitions for curriculum
participants both internal and external to an institution. Ilios also provides
a robust, scalable delivery mechanism for calendar and scheduling
information, with direct access via fully-featured user-centric calendars to
critical course information, materials, and other educational systems and
services, such as online course environments and digital asset archives.
Ilios leverages the power of existing online learning technologies
supported at most health professions institutions. Built on open-source,
loosely coupled components, Ilios is a modular system meant to integrate
with external data sources and systems. For schools already using (or
considering the implementation of) online learning systems such as
Moodle, Blackboard or Sakai, Ilios provides a backbone of curricular

information to make that deployment more robust and to complement the
rich online tools, activities and materials already in use.
Features
Ilios allows for the control and development of complex curricula
organized by individual departments, programs schools or institutions.
Courses may be shared across these organizations, while still maintaining
data integrity, security and intellectual property controls.
Program Management
Create and manage any number of unique programs within your
authorized institution(s)
Longitudinal tracking: control the attributes and requirements of each
unique program year by year, allowing growth and modification to each
individual matriculation group.
Competencies: Assign competency domains to programs year by year,
which will then link to the underlying courses and activities
Disciplines: Assign primary focus disciplines to each program year.
Streamlined workflow management for content review prior to public
dissemination.
Full historic audit abilities for tracking record changes and updates


Group Management
Create and manage groups and sub-groups of learners for your
curriculum
Add any person in the system to an instructor group and designate
their role or classification
Automatically generate groups for a cohort of students, equally
proportioned from existing enrollment
Assign default instructors and locations to groups and sub-groups
within any cohort of learners
Copy existing groups and associating them freely within the curriculum
Capture learner information from external feeds (e.g. .csv upload) or
individual form entry
Assign groups to curricular activity and provide direct, secure access to
group members via the calendar
Modify groups assigned to curriculum objects and activities for each
unique instance, without altering the group in other curricular
assignments
Create and manage groups of instructors

Course Management
Create and manage any number of courses and course events for your
curriculum
Associate discrete learning objectives to courses and learning activities

Assign competency domains and disciplines to courses and
associate them with learning objectives to allow full curricular
mappings
Control access and assignment via groups
Track distinct teaching hours by course part, category, and
objective
Associate learning materials with courses and learning objectives
Create robust reports from controlled curricular data
Course replication and rollover from one academic year to the next
Share curricular information via xml / web services with other
standards-compliant systems

Calendar Management
User-centric calendar access to all registered users
Multi-modal calendar search
Mobile views, synchronization and download of calendar
information
Direct access to online learning environments and materials via
calendar interface
Real-time alerts of schedule, location and content changes

User & ID Management
Import external feeds for enrollment and identity control

Export internal data for enrollment to 3rd party applications
Assignment of user roles by group, or individually
Public access for non-affiliated users, and temporary or guest
access for non-permanent or casual affiliations

Workflow Management
Easy control of materials for editing, review, and
publishing/propagation
User control over who may move any piece of work from one state
to the next, ie. draft to published
Full audit capability

Data Tracking and Reporting
Full relational data reporting capacity via SQL
Teaching hours tracking and management by instructor,
department, educational method
Content hours tracking and management
Curriculum mapping
Trend reporting
Full archiving
AAMC Curriculum Inventory Export Tool suite included


Technical Specifications
Current Recommended Minimum System Requirements:
Standard production-grade Linux or Windows server with at least 500GB
of storage available (for learning materials storage):
Apache: at least 2.2.13 (or IIS 6+)
MySQL: at least 5.0.77 with both the InnoDB and MyISAM
backing engines
PHP: at least 5.3.x must have support for mysqli (note mysqli, as
opposed to mysql)

Ilios has been successfully implemented as a WIMP (Windows 7/2008R2,
IIS, MySQL, PHP) and WAMP (Windows 7/2008R2, Apache, MySQL,
PHP) stack for those running in a Windows environment. Documentation
will be forthcoming for interested parties.
The current deployment of Ilios deploys with its own native authentication
system as the default, but may be switched via the configuration file to use
shibboleth 2.4 for authentication if so desired. For further information,
please refer to the most recent read me and release notes available with
the code at our Ilios GitHub page.
https://www.iliosproject.org/features


2.1.3 Carleton University
Computer Science is about more than computers: it is the systematic
study of processes for solving problems. The computer science program
at Carleton focuses on understanding how to think about these processes,
how to program computers to carry out important tasks efficiently, and
how to apply computer science ideas to important applications.
The computer science major has a core of eight courses -- Introduction to
Computer Science, Data Structures, Mathematics of Computer Science,
Software Design, Computer Organization and Architecture, Programming
Language Design & Implementation, Algorithms, and Complexity &
Computability. Majors take these eight courses plus two electives from
advanced computer science offerings. The major concludes with a
capstone experience, known as comps, consisting of an in-depth project
undertaken by a team of students.
Since computer science plays such a key role in the physical, biological,
and social sciences, Introduction to Computer Science and Data
Structures are useful and recommended to all Carleton students who plan
careers in these areas, not just those majoring in computer science.
Finally, A & I seminars are offered on a regular basis. Recent topics have
included Cryptography, Digital Storytelling, and Arts, Interactivity, and

Robotics. A & I seminars are independent of the introductory computer
science sequence.
Supplementing the regularly offered courses is a colloquium series at
which students, staff and visitors discuss topics of current interest. Over
the past years the speakers have included a variety of distinguished
visitors, including Turing award winners Fred Brooks and Ron Rivest.
The department is especially proud of the quality and diversity of its
computer equipment available for student use. It maintains a number of
modern computer facilities including an introductory computer science lab,
a research lab, and a student lounge. The department also owns a
number of multi-processor servers for student work. Computers in our
public labs boot both Mac and Windows, and offer a wide variety of tools
including support for dozens of programming languages, 3D graphics,
video capture, parallel processing, data mining, networks, database
programming, and Web development. All of the computing equipment
allows access to the Internet via Carletons extremely fast Internet2
connection.
There are many opportunities for the study of computer science in addition
to the regular course offerings. The department supports a strong and
active undergraduate research program. Students typically work in groups
alongside a faculty mentor during the summer, and occasionally during the
school year as well. Carleton has participated for over 20 years in the

ACM intercollegiate programming competition, three times sending teams
to the international finals. Employment with the department is
encouraged: the department employs students as tutors, lab assistants,
and paper graders; in computer system administration and software
development; and as research assistants.
Students may plan a major in computer science in preparation for work or
further study in any of a variety of fields. In addition to graduate programs
in computer science, Carleton students pursue studies in interdisciplinary
areas such as bio informatics, linguistics, and cognitive science. Students
pursuing employment have gone to large companies such as IBM,
Microsoft, Google and Apple, as well as smaller companies such as Epic
Systems and Secure Computing.
Majors in the department develop close relationships with departmental
faculty, which is one of the important benefits that Carletons size offers. In
addition to personalized attention in academic work, students and faculty
attend social events such as picnics and bowling expeditions.
Course Information of Carleton University

CS 099: Summer Computer Science Institute
Computer science is a rich academic field that seeks to systematically
study the processes for solving problems and untangle the complexities in
the concrete physical world and the abstract mathematical world. The

Summer Computer Science Institute (SCSI) at Carleton focuses on
understanding how to think about these processes, how to program
computers to implement them, and how to apply computer science ideas
to real problems of interest. Students at SCSI will learn how to
systematically approach problems like a computer scientist as they
engage in classroom learning, hands-on lab activities, and collaborative
guided research.6 credit; S/CR/NC; offered Staff
CS 100: Human Centered Computing
Technology permeates every aspect of our lives: how we work, play, and
communicate; our finances and health; etc. Technology can facilitate
these, or make it difficult to perform simple tasks or express what we want
to accomplish. We'll take a critical look at the interfaces between
technology and people, examining what makes these user interfaces
effective, practicing key design principles through case studies and design
projects, and discussing legal, ethical, and social issues in interface
design, particularly the accessibility, privacy, and environmental impacts.
No computer science experience is necessary.6 credit; Argument and
Inquiry Seminar, Writing Requirement, Quantitative Reasoning Encounter;
offered Fall 2014 A. Csizmar Dalal
CS 108: Life in the Age of Networks
This course investigates how the social, technological, and natural worlds
are connected, and how the study of networks sheds light on these

connections. A network is a collection of entities linked by some
relationship: people connected by friendships (e.g., Facebook); web pages
connected by hyperlinks; species connected by the who-preys-on-whom
relationship. We will explore mathematical properties of networks while
emphasizing the efficient processing and analysis of network data drawn
from a variety of fields. Topics include: how Google works; "six degrees of
separation"; the spread of fads through society. No background in
computer science or programming is required or expected.Prerequisites:
No prerequisites. Students may not simultaneously enroll in Computer
Science 108 and Computer Science 111 in the same term, and students
who have received credit for Computer Science 111 or above are not
eligible to enroll in Computer Science 108.6 credit; Formal or Statistical
Reasoning, Quantitative Reasoning Encounter; not offered 20142015
CS 111: Introduction to Computer Science
This course will introduce you to computer programming and the design of
algorithms. By writing programs to solve problems in areas such as image
processing, text processing, and simple games, you will learn about
recursive and iterative algorithms, complexity analysis, graphics, data
representation, software engineering, and object-oriented design. No
previous programming experience is necessary. Students who have
received credit for Computer Science 201 or above are not eligible to
enroll in Computer Science 111. Students may not simultaneously enroll
for CS 108 and CS 111 in the same term.6 credit; Formal or Statistical

Reasoning, Quantitative Reasoning Encounter; offered Fall 2014, Winter
2015, Spring 2015 Staff
CS 201: Data Structures
Think back to your favorite assignment from Introduction to Computer
Science. Did you ever get the feeling that "there has to be a better/smarter
way to do this problem?" The Data Structures course is all about how to
store information intelligently and access it efficiently. How can Google
take your query, compare it to billions of web pages, and return the
answer in less than one second? How can one store information so as to
balance the competing needs for fast data retrieval and fast data
modification? To help us answer questions like these, we will analyze and
implement stacks, queues, trees, linked lists, graphs and hash tables.
Students who have received credit for a course for which Computer
Science 201 is a prerequisite are not eligible to enroll in Computer
Science 201.Prerequisites: Computer Science 111 or consent of the
instructor.6 credit; Formal or Statistical Reasoning, Quantitative
Reasoning Encounter; offered Fall 2014, Winter 2015, Spring 2015 Staff
CS 202: Mathematics of Computer Science
This course introduces some of the formal tools of computer science,
using a variety of applications as a vehicle. You'll learn how to encode
data so that when you scratch the back of a DVD, it still plays just fine;
how to distribute "shares" of your floor's PIN so that any five of you can

withdraw money from the floor bank account (but no four of you can); how
to play chess; and more. Topics that we'll explore along the way include:
logic and proofs, number theory, elementary complexity theory and
recurrence relations, basic probability, counting techniques, and
graphs.Prerequisites: Computer Science 111 and Mathematics 111; or
permission of instructor.6 credit; Formal or Statistical Reasoning; offered
Fall 2014, Spring 2015 J. Miles
CS 208: Computer Organization and Architecture
Computer processors are extraordinarily complex systems. The fact that
they work at all, let alone as reliably as they do, is a monumental
achievement of human collaboration. In this course, we will study the
structure of computer processors, with attention to digital logic, assembly
language, performance evaluation, computer arithmetic, data paths and
control, pipelining, and memory hierarchies.Prerequisites: Computer
Science 111 or consent of the instructor.6 credit; Formal or Statistical
Reasoning; offered Winter 2015 J. Ondich
CS 231: Computer Security
Hackers, phishers, and spammers--at best they annoy us, at worst they
disrupt communication systems, steal identities, bring down corporations,
and compromise sensitive systems. In this course, we'll study various
aspects of computer and network security, focusing mainly on the
technical aspects as well as the social and cultural costs of providing (or

not providing) security. Topics include cryptography, authentication and
identification schemes, intrusion detection, viruses and worms, spam
prevention, firewalls, denial of service, electronic commerce, privacy, and
usability.Prerequisites: Computer Science 201 or 202 or 2086 credit;
Formal or Statistical Reasoning; offered Fall 2014 J. Ondich
CS 251: Programming Languages: Design and Implementation
What makes a programming language like "Python" or like "Java?" This
course will look past superficial properties (like indentation) and into the
soul of programming languages. We will explore a variety of topics in
programming language construction and design: syntax and semantics,
mechanisms for parameter passing, typing, scoping, and control
structures. Students will expand their programming experience to include
other programming paradigms, including functional languages like
Scheme and ML.Prerequisites: Computer Science 201 or permission of
instructor.6 credit; Formal or Statistical Reasoning; offered Fall 2014,
Spring 2015 D. Musicant
CS 252: Algorithms
A course on techniques used in the design and analysis of efficient
algorithms. We will cover several major algorithmic design paradigms
(greedy algorithms, dynamic programming, divide and conquer, and
network flow). Along the way, we will explore the application of these
techniques to a variety of domains (natural language processing,

economics, computational biology, and data mining, for example). As time
permits, we will include supplementary topics like randomized algorithms,
advanced data structures, and amortized analysis.Prerequisites:
Computer Science 201 and either Computer Science 202 or Mathematics
236.6 credit; Formal or Statistical Reasoning; offered Fall 2014, Winter
2015 J. Miles, D. Liben-Nowell
CS 254: Computability and Complexity
An introduction to the theory of computation. What problems can and
cannot be solved efficiently by computers? What problems cannot be
solved by computers, period? Topics include formal models of
computation, including finite-state automata, pushdown automata, and
Turing machines; formal languages, including regular expressions and
context-free grammars; computability and uncomputability; and
computational complexity, particularly NP-completeness.Prerequisites:
Computer Science 111 and either Computer Science 202 or Mathematics
236.6 credit; Formal or Statistical Reasoning; offered Winter 2015, Spring
2015 D. Liben-Nowell, A. Rafferty
CS 257: Software Design
It's easy to write a mediocre computer program, and lots of people do it.
Good programs are quite a bit harder to write, and are correspondingly
less common. In this course, we will study techniques, tools, and habits
that will improve your chances of writing good software. While working on

several medium-sized programming projects, we will investigate code
construction techniques, debugging and profiling tools, testing
methodologies, UML, principles of object-oriented design, design patterns,
and user interface design.Prerequisites: Computer Science 201 or
consent of the instructor.6 credit; Formal or Statistical Reasoning; offered
Fall 2014, Spring 2015 J. Ondich, J. Miles
CS 321: Artificial Intelligence
How can we design computer systems with behavior that seems
"intelligent?" This course will examine a number of different approaches to
this question, including intelligent search computer game playing,
automated logic, machine learning (including neural networks), and
reasoning with uncertainty. The coursework is a mix of problem solving
and computer programming based on the ideas that we
discuss.Prerequisites: Computer Science 201, additionally Computer
Science 202 or Mathematics 236 are strongly recommended.6 credit;
Formal or Statistical Reasoning; offered Winter 2015 A. Rafferty
CS 322: Natural Language Processing
Computers are poor conversationalists, despite decades of attempts to
change that fact. This course will provide an overview of the computational
techniques developed in the attempt to enable computers to interpret and
respond appropriately to ideas expressed using natural languages (such
as English or French) as opposed to formal languages (such as C++ or

Lisp). Topics in this course will include parsing, semantic analysis,
machine translation, dialogue systems, and statistical methods in speech
recognition.Prerequisites: Computer Science 201 and 202 or permission
of the instructor.6 credit; Formal or Statistical Reasoning; not offered
20142015.
CS 324: Data Mining
How does Google always understand what it is you're looking for? How
does Amazon.com figure out what items you might be interested in
buying? How can categories of similar politicians be identified, based on
their voting patterns? These questions can be answered via data mining, a
field of study at the crossroads of artificial intelligence, database systems,
and statistics. Data mining concerns itself with the goal of getting a
computer to learn or discover patterns, especially those found within large
datasets. We'll focus on techniques such as classification, clustering,
association rules, web mining, collaborative filtering, and
others.Prerequisites: Computer Science 201. Additionally, Computer
Science 202 or Mathematics 236 strongly recommended.6 credit; Formal
or Statistical Reasoning, Quantitative Reasoning Encounter; offeredWinter
2015 D. Musicant
CS 331: Computer Networks
The Internet is composed of a large number of heterogeneous,
independently-operating computer networks that work together to

transport all sorts of data to points all over the world. The fact that it does
this so well given its complexity is a minor miracle. In this class, we'll study
the structure of these individual networks and of the Internet, and figure
out how this "magic" takes place. Topics include TCP/IP, protocols and
their implementations, routing, security, network architecture, DNS, and
emerging applications and technologies such as peer-to-peer networking,
WiFi, and WiMax.Prerequisites: Computer Science 201 or consent of
instructor6 credit; Formal or Statistical Reasoning; not offered 20142015
CS 332: Operating Systems
The thing that we call a computer is actually a complex collection of
interacting devices. To ensure that these devices work together effectively
without excessive human intervention, people have developed operating
systems software that coordinates the behavior of the devices and gives
programmers ways to control those devices. This course will address the
fundamental problems that operating systems need to solve, including
those concerned with process management, file organization, memory
management, and input/output control. We will also study the structure of
the Linux operating system.Prerequisites: Computer Science 208 or
consent of the instructor.6 credit; Formal or Statistical Reasoning; not
offered 20142015


Extended departmental description for CS 332
If you're working in the lab, you might be editing a file while waiting for a
program to compile. Meanwhile, the on-screen clock ticks, a program
keeps watch for incoming e-mail, and other users can log onto your
machine from elsewhere in the network. Not only that, but if you write a
program that reads from a file on the hard drive, you are not expected to
concern yourself with turning on the drive's motor or moving the read/write
arms to the proper location over the disk's surface. Coordinating all this
hardware and software is the job of the operating system.
In this course we will study the fundamental problems faced by operating
system designers. We will look at inter-process communication, memory
management, file systems, and input/output in general and in the context
of particular operating systems. We will also study some parts of the Linux
source code.
CS 334: Database Systems
Database systems are used in almost every aspect of computing, from
storing data for websites to maintaining financial information for large
corporations. Intrinsically, what is a database system and how does it
work? This course takes a two-pronged approach to studying database
systems. From a systems perspective, we will look at the low-level details
of how a database system works internally, studying such topics as file
organization, indexing, sorting techniques, and query optimization. From a

theory perspective, we will examine the fundamental ideas behind
database systems, such as normal forms and relational
algebra.Prerequisites: Computer Science 201 or consent of the
instructor.6 credit; Formal or Statistical Reasoning; offered Fall 2014 D.
Musicant
CS 338: Digital Electronics
Fun fact: Computers can be built up entirely from a collection of
transistors. This course will begin the process of doing just that. From
transistors we'll build logic gates. From logic gates, we'll build RAM and
adders. With adders, we'll build arithmetic logic units, and so on, up to
microprocessors. Corequisite: Computer Science 338L.Prerequisites:
Computer Science 208.6 credit; Formal or Statistical Reasoning; offered
Winter 2015 A. Exley
CS 342: Mobile Application Development
Software used to stay on the desktop where you put it. Now, we carry
multi-purpose computational devices in our pockets. Mobile computers
raise a host of software design challenges, with constrained visual spaces,
touch screens, GPS sensors, accelerometers, cellular access, and
cameras all in one device. More challenges come from the idea of an "app
store," a five-year-old experiment that has changed the way developers
and computer users think about software. In the context of a few app
development projects, this course will focus on mobile computing's design

patterns, user interface principles, software development methodologies,
development tools, and cultural impact.Prerequisites: Computer Science
204 or 2576 credit; Formal or Statistical Reasoning; offered Spring 2015
J. Ondich
CS 344: Human-Computer Interaction
The field of human-computer interaction addresses two fundamental
questions: how do people interact with technology, and how can
technology enhance the human experience? In this course, we will explore
technology through the lens of the end user: how can we design effective,
aesthetically pleasing technology, particularly user interfaces, to satisfy
user needs and improve the human condition? How do people react to
technology and learn to use technology? What are the social, societal,
health, and ethical implications of technology? The course will focus on
design methodologies, techniques, and processes for developing, testing,
and deploying user interfaces.Prerequisites: Computer Science 201 or
consent of instructor.6 credit; Formal or Statistical Reasoning, Quantitative
Reasoning Encounter; offeredSpring 2015 A. Csizmar Dalal
CS 348: Parallel and Distributed Computing
As multi-core machines become more prevalent, different programming
paradigms have emerged for harnessing extra processors for better
performance. This course explores parallel computation (programs that
run on more than one core) as well as the related problem of distributed

computation (programs that run on more than one machine). In particular,
we will explore the two major paradigms for parallel programming, shared-
memory multi-threading and message-passing, and the advantages and
disadvantages of each. Other possible topics include synchronization
mechanisms, debugging concurrent programs, fork/join parallelism, the
theory of parallelism and concurrency, parallel algorithms, cloud
computing, Map/Reduce, GPU programming, transactional memory, and
memory models.Prerequisites: Computer Science 2016 credit; Formal or
Statistical Reasoning; not offered 20142015
CS 352: Advanced Algorithms
A second course on designing and analyzing efficient algorithms to solve
computational problems. We will survey some algorithmic design
techniques that apply broadly throughout computer science, including
discussion of wide-ranging applications. A sampling of potential topics:
approximation algorithms (can we efficiently compute near-optimal
solutions even when finding exact solutions is computationally
intractable?); randomized algorithms (does flipping coins help in designing
faster/simpler algorithms?); online algorithms (how do we analyze an
algorithm that needs to make decisions before the entire input arrives?);
advanced data structures; complexity theory. As time and interest permit,
we will mix recently published algorithmic papers with classical
results.Prerequisites: Computer Science 252 or permission of instructor.6
credit; Formal or Statistical Reasoning; not offered 20142015

CS 361: Evolutionary Computing and Artificial Life
An introduction to evolutionary computation and artificial life, with a special
emphasis on the two way flow of ideas between evolutionary biology and
computer science. Topics will include the basic principles of biological
evolution, experimental evolution techniques, and the application of
evolutionary computation principles to solve real problems. All students
will be expected to complete and present a term project exploring an open
question in evolutionary computation.Prerequisites: Computer Science
2016 credit; Formal or Statistical Reasoning; offered Spring 2015 S.
Goings
Extended departmental description for CS 361
Have you ever wished that instead of spending 2 hours writing a program
to solve a difficult problem you could instead just tell the computer to do
the work and go play Ultimate Frisbee for 2 hours knowing the solution will
be waiting for you when you return? One of the goals of artificial
intelligence is to be able to view the computer as a black box, you simply
give it the problem you want to solve, and it gives you the answer, without
you needed to understand all of the internal workings. Evolutionary
computation seeks to create this black box by harnessing the power of
Darwinian evolution to solve computational problems. Instead of
programming a solution, the user simply initializes a population of very
simple (and probably very bad) solutions, and then sits back while the

population evolves until a good solution appears. Evolutionary
Computation (EC) has shown promise in evolving novel solutions to real-
world problems, such as antennas actually deployed on Nasa satellites,
neural controllers for legged robots, and programs that choose sound
investments, however EC is a current active field of research with many
open questions to be answered. In this course students will develop a
broad understanding of developing and analyzing current evolutionary
computation systems, and develop a deeper understanding of at least one
specific evolutionary computation topic through a research project.
CS 399: Senior Seminar
As part of their senior capstone experience, majors will work together in
teams (typically four to seven students per team) on faculty-specified
topics to design and implement the first stage of a project. Required of all
senior majors.Prerequisites: Senior standing. Students are strongly
encouraged to complete Computer Science 252 and either Computer
Science 204 or 257 before starting Computer Science 399.3 credit;
S/CR/NC; Does not fulfill a curricular exploration requirement; offered Fall
2014 Staff
CS 400: Integrative Exercise
Beginning with the prototypes developed in the Senior Seminar, project
teams will complete their project and present it to the department.
Required of all senior majors.Prerequisites: Computer Science 399.3

credit; S/NC; Does not fulfill a curricular exploration requirement; offered
Winter 2015 Staff
https://apps.carleton.edu/curricular/cs/courses/
2.1.4 Aarhus School of Business, Denmark
Project Management increasingly shapes workplace communication,
especially when technical communicators participate in cross-disciplinary
development teams. This paper looks at the future of project management
in technical communication and argues for a communicative approach to
project management for technical communication students. The Project
Management course in the International Bachelor Program of Marketing
and Management Communication at the Aarhus School of Business is
described, and the implications for technical communication curricula are
discussed. Keywords: Project Management, genre, technical
communication. Introduction As corporate structures shift to include an
increasing number of cross-functional projects, the demand for project
management knowledge which prepares undergraduate students to
function effectively in this environment increases as well. To address the
issue of preparing students to function in a project-based environment, a
communications approach to project management is defined as an
approach focused on both genres for documentation used to manage
projects and the situatedness of project management documents in
organizational structures, cultures, and knowledge management
processes. This paper will describe the project management course used

in the International Marketing and Management BA program at the Aarhus
School of Business based on this communications approach, give
examples of student responses to the curriculum, and recommend ways of
integrating project management processes and documents into technical
communication curricula. The communications approach to project
management is framed by an understanding of the rhetorical situations
found in project-based environments. Bakhtin points out the connection
between speech genres and spheres of human activity, and Miller
describes genres as social action. These links between genre and action
at the theoretical level provide an entry point into Project Management
practices and documentation genres as responses to both the content and
situation involved in any given project. As project management documents
emerge from the activity inherent in getting projects done, helping
students see beyond the document structures to include the connections
between formats in documents and organizational contexts offers a view
of project management as a rhetorical process, which, in turn, gives
students a robust set of tools to understand project management from
multiple perspectives. In addition to genre, the connections between
project management and knowledge management are explored in order
to allow students to consider organizational issues regarding the
sustainability and continuity of knowledge within organizations in a project-
based environment. The communications approach to project
management offers not only a means for incorporating rhetoric into the

way in which project management is taught, but also an argument for
incorporating project management documentation into the technical
communication curriculum because the rhetorical foundation helps make a
connection between project management documents The Future of
Project Management in Technical Communication: Incorporating a
Communications Approach Constance E. Kampf Aarhus School of
Business, Denmarkcka@asb.dk and the proposals from which they
emerge. As project management races the organizations in which our
students will work into the future, we have the opportunity to give technical
communication students a head start by including project management
genres and helping our students make the connection to basic concepts in
technical communication. This paper defines the communications
approach to Project Management, describes the course, and offers
implications for the technical communication curriculum. Defining the
Communications Approach to PM The communications approach to
project management shifts the emphasis from project management
documents as planning and accountability tools to project management
documents as genres for action situated in a rhetorical context. This
emphasis comes from an approach to understanding projects as rhetorical
constructssolutions to problems agreed upon by the people working on
them, and as such projects can be understood as rhetorical situations.
Miller defines situation as social constructs that are the result of
definition. The relevant definitions for project management documents

include not only the generic set of project management documents, but
also the definition of the project itself within the organizational and social
contexts around it. Project Management documents can be understood as
a set of genres used for organization and accountability in a project.
Standard project management documents include: Project charter, Work
breakdown structure, Network Diagram with Critical Path and Gantt Chart
These documents function as tools for collective action in a project. Their
effectiveness depends on the context in which they were created, the buy-
in to the project plan by the people doing the work and the way in which
they are used and maintained to reflect progress on the project. As
Bakhtin argues for the connection between spheres of activity and
genres, we can use his perspective to link the activity of managing a
project to the genres of project management documents. Relevant theory
which can help us make this link includes Wengers concept of
Communities of Practice, Seely Browns Social Life of Information, and
Storytelling in Organizations as well as Knowledge Management theory.
As students work with these theoretical constructs, they are asked to
make the link between the rhetorical situation and the content choices,
structure and distribution for project management documents. Course
Description and Results The Project Management Course at the Aarhus
School of Business is a required course for the International Bachelor in
Marketing and Management Communication. The course covers the
project management document structures, explains how they are situated

in organizations, and offers readings to help students reflect on the
rhetorical situation. The course plan is included in Appendix A. The course
was offered over 8 weeks to a group of 60 students, meeting twice a week
for 2 hours. The students were graduating seniors (semester students in
the Danish system) as well as some exchange students. The first class in
each week gave students the project management concepts, and included
reflective exercises for discussing and incorporating communication theory
into the concepts. The subsequent class gave the students case studies to
analyze and discuss. We also used a course management system to give
students a place to post their reflections on the readings and answers to
questions asking them to incorporate their communication course work
into the project management structures and concepts presented in class.
Each week the best reflection was chosen by the instructor, and the
students who wrote it were asked to share their work and rewarded in
class. The course activities included using the project management
document structure to organize their senior papers, and presenting a
practice case study as a mock final exam. The final exam was the only
place where students could receive a grade for the course, as per the
Danish Higher Education system. The final exam consisted of a half hour
oral defense, during which each student presented their solution to 0-
7803-9778-9/06/$20.00 2006 IEEE. the case by using the project
management genres and incorporating knowledge management
recommendations into their project description. This exam was graded by

both the instructor and an external rater, and the grade was given to the
student along with feedback during the last five minutes of the exam time.
The students did an excellent job of challenging the project management
concepts, and the brightest of them were able to explain in their final exam
how communication practices and knowledge management concepts were
part of their decisions to organize the work, and define the problem. For
example, several students used Wengers concept of Communities of
Practice to define the work as not only accomplishing the project but also
putting measures in place to support communities of practice which would
provide ongoing support after the project was complete. Curricular
Implications for Technical Communication Technical communications
students, through their strong background in the rhetorical situation, are
capable and in some ways uniquely qualified to be able to synthesize their
communication knowledge with the genres in project management
processes. Technical communicators can benefit from being exposed to
Project Management practices in a classroom where they are encouraged
to synthesize their knowledge of communication and rhetorical theories
with concrete practices from the business world. This can be done in a
separate course, or it could be incorporated into a grant seeking or
proposal writing course. Project Management is not only an emerging field
it is also part of organizational structures in which most technical
communicators will work after graduation. Learning about Project
Management processes and structures will give them the tools to

understand the rhetorical situations into which they are going more
effectively, so that they can participate in projects with more awareness of
the genres and situatedness of project management documents.
http://www.rose-hulman.edu/Users/faculty/williams/Public/PDF%20Files/16.pdf


CHAPTER 3 RISK MITIGATION, MONITORING AND MANAGEMENT PLAN
1.0 Introduction
The goal of the risk mitigation, monitoring and management plan is to identify as
many potential risks as possible. The development team will create a plan to
avoid this risk. To determine what the potential risks are, Curriculum
Management System must be evaluated. After it has been evaluated the project
will then be analyzed to determine any project-specific risks.

1.1 Scope and intent of RMMM activities
When all risks have been identified, the system will then be evaluated to
determine their probability of occurrence and how Curriculum Management
System (CMS) will be affected if they do occur. The development team plan will
then be made to avoid each risk, to track each risk, to determine if it is more or
less likely to occur and to plan for those risks they should occur.

1.2 Risk management organization role
Software development will monitor their progress and project status
consistently to identify present and future risks as quickly and accurately
as possible.
Customer will keep their eyes on the system for additional risks that the
developer did not recognize.
Software development must be well-informed in the equipment they will be
using and others that is accessible to them.
Client must informed the development in all the details of the system

2.0 Risk Description
2.1 Risk Table
2.1.1 Description of Risk m

Product Size:
Inadequate estimation of project time, cost, scope and other
resources. If project manager exceed in estimation of time and
available budget. If it finds difficult on determining scopes of the
project if available resources are not enough to complete the
project.
Business Impact Risks:
Businesses today are facing an unprecedented rate of change. This
business change has a direct impact on our software development.
Every request of the business to improve quality requires developer
to make software changes. These changes introduce defects that
can seriously damage softwares portfolio sharing the same codes.
Customer Risks:
If the customer agrees to spend time in formal requirements
gathering meetings to identify project scope but didnt attend
regularly. If the customer fails to establish rapid communication
links with the developer.
Process Risks:
If developers were not involved in the requirements analysis and
definition phase, then the requirements document may be not
understandable by them. Hence, they will be unable to start their
design on a solid knowledge of the system requirements, and thus
they may develop a design for a system other than the intended
one.


Technology Risks:
The project may involve the use of new technologies that has not
been use before. If developers may find it difficult to deal with these
technologies the project will fail.
Development Risks:
If the tools are not enough to complete the system, the system
cannot be implemented using the current available technology
where the project involves the use of new technology. If these alike
projects were posed it may threaten the project from being
implemented successfully, wherein the developers may suffer from
the technology change risks.
Employee Risks:
Inexperienced developers in the selected programming language. If
the selected programming language was very sensitive and has
bad-quality compilers and debuggers, then the programmers may
occur many syntax errors , the resultant code might be complex
and ambiguous, wrong functions, properties and user interfaces
might be developed.
2.1.2 Probability and Impact for Risk
Category Risks Probability Impact
Product Size Mis-estimation of product size 40% 1
Business Impact Business fast changes 20% 3
Customer Risks Customer fails to participate 30% 2
Process Risks
Developer failed to understand
the whole process
40% 1
Technology Risks Technology changes 20% 3
Development Insufficient resources 30% 2

Risks
Employees Risks Inexperienced developers 40% 1
Table Risks Table (sorted)
Impact Values
Description
1 Catastrophic
2 Critical
3 Marginal
4 Negligible
3.0 Risk Mitigation, Monitoring and Management
3.1 Risk Mitigation for risk m
Identifying the various activities, or steps, to reduce the probability and/or
impact of an adverse risk. Taking early steps to reduce the probability of
an adverse risk occurring may be more effective and less costly than
repairing the damage after a risk has occurred. However, some risk
mitigation options may simply be too costly in time or money to consider.
3.1.1 Product Size
In order to avoid mis-estimations of systems specifications, the
team would discuss more often with the costumer or research more
things about the systems scopes and limitations.
3.1.2 Business Impact
Development team would always be aware of the fast changing
business. Like the requirements its looking. Development needs to
uphold the customers satisfaction levels and must give uniqueness
to put the system on competency.
3.1.3 Customer (User) Risk

Customer is obliged to work with the development team at all times
to avoid future problems especially on the systems scopes and
limitations.
3.1.4 Process Risk
Development team must have formal technical reviews on the
requirement specifications, systems scopes, designs and used
codes regularly to prevent problems with the designs and the
process intended in the system.
3.1.5 Technology Risks
Development team must be aware on the fast changing of
technologies and continues to study it to apply it in the system for
the requirements specifications.
3.1.6 Development Risks
Stakeholders must have their 100% support on the project specially
on the technologies the development team has to be used to avoid
unnecessary problems on the development process.
3.1.7 Employee Risks(Team members)
Project managers choose team members that are well experienced
in their prospected fields, familiar in the tools that the development
will be using to avoid having problem during development. And
team members must report regularly on their works to identify their
weak spots.
3.2 Risk Monitoring For Risk m
3.2.1 Product Size
Project manager would monitor the progress of the system
regularly to identify the estimation through the work breakdown
structure. Evaluation of the product size will be conducted through
the entire development cycle.
3.2.3 Customer (User) Risks

3.2.4 Process Risks
3.2.7 Employee Risk(Team mates)
3.3 Risk Management for Risk m
3.3.1 Product Size
3.3.3 Customer (User) Risks
3.3.4 Process Risks
3.3.7 Employee Risks(Team members)
4.0 Special Conditions


SOFTWARE CONFIGURATION MANAGEMENT PLAN
1.0 INTRODUCTION
Software configuration management encompasses the disciplines and
techniques of initiating, evaluating and controlling changes to software products
during and after the software engineering process.
In this phase the purpose of the development was to create guidelines and rules
on the storage, layouts and identification conventions on all the document that
will be created in the curriculum.

1.1 SCOPE AND INTENT OF SCM ACTIVITIES
SCM manages evolving software systems and controls the costs involved in
making changes to a system. More than one version of the software has to be
supported:
1.) The released system;
2.) Custom configured systems and their different functionality;
3.) System under development.
Software must run on different machines and operating systems.

SCM ACTIVITIES
Configuration item identification
Modeling of the system as a set of evolving components
Promotion Management
The creation of versions for other developers
Release management
The creation of versions for the clients and users
Change management
The handling, approval and tracking of change requests
Branch management
The management of concurrent development
Variant management
The management of versions intended to coexist

1.2 SCM ORGANIZATIONALE ROLE

Configuration Manager / Project Manager
He is responsible for identifying configuration items. The configuration
manager can also be responsible for defining the procedures for creating
the promotions and releases.
Change Control Board Member / Project Programmer

He is responsible for approving or rejecting change requests.
Developer / Project Analysts
They are responsible in creating promotions triggered by change requests or the
normal activities of development. The developers check in changes and resolve
conflicts.
Auditor / Business Analysts
He is responsible for the selection and evaluation of promotions for
release and for ensuring the consistency and completeness of this
release.

2.0 SCM TASKS
2.1 IDENTIFICATION
Large entities that are produce from curriculum management system must
be uniquely identified. Any entity managed in the software engineering
process can potentially be brought under configuration management
control but not every entity needs to be under configuration management
control all the time.

2.1.1 Description
General
All source files of the documents are kept in Subversion in which
the different documents have their own directory. The main file for a
document should be called: [document name].docs.

Document Names
Document names are required to abide by the following naming
scheme. When other files are included by the main document, they
should be called: [name].docs for WORD files; [name].[file type
extension] for images.

Name should be a short and clear name for the file. Documents
generated from the source which are intended for review are
named: [document name]-[version tag].[file type extension].

Document ID
All product and management documents carry a document ID,
which consists of three parts concatenated by slashes (/): 1. the
project name identifier; 2. the (relative) file path to the documents
directory in the archive library without the extension; 3. the version
of the document.

Baselines
Baselines are documents that have been internally reviewed and
approved. They will be stored in the master library.

2.1.2 Work products and Documentation
Identify Change
Once the changed is identified a change request form will be produced
and will be sent to all the members of the SCM Team.
Control Change
After the CM got the change request form, change report form will be
generated.
Ensure that change is being properly implemented.
Document the Change
Once the change is approved, CM will document the change in the library.
And will change the software version number as required.

2.2 CONFIGURATION CONTROL
2.2.1 Description
All CIs are stored in one of three libraries: the development library,
the master library and the archive library.

The development library contains CIs that are under construction and CIs
that are not official product documents. Every category has its own SVN
repository, in which the different documents have their own directory. Two
directories that may require a little explanation are tags and branches. The
tags directory is used when tagging (a part of) the repository and the
branches directory is used if a branch of the repository has to be created.
The CM creates the initial module and group for each CI. Because of the
nature of SVN, none of the users can overwrite or delete any of the files.
The CM is allowed to correct naming and placing of documents if their
location or name doesnt conform to the conventions described herein.
When a document is ready for a review the authors can tag the SVN
snapshot them. When a document has passed an internal or external
review the authors must request the CM to tag the current SVN snapshot
and to generate the document. In effect this means that authors are
allowed to change the informal revision number by themselves, but the
CM is responsible for tagging the external and internal revisions. In the

development library the change control system which SVN provides is
used.

The master library contains CIs that have been internally approved. Only
the CM can put CIs in the master library. CIs in the master library will
never be deleted during the project. A copy of every document in the
master library will also be kept on paper in the group project room. Once a
CI is internally approved, the CM can put it in the master library. If authors
want to make changes to a document inside the library, then that author
has to contact the QAM. The QAM will call for a review meeting in which
the changes are approved or rejected. When the changes are accepted a
new version of the CI will be put in the master library. The addition of
appendices to a document does not require an additional review meeting,
but can be done directly. The revision number should still be changed by
the CM, however.

The archive library contains CIs that have been externally released and
approved. Only the CM can put CIs in the archive library. CIs may only be
added after they have been externally reviewed and approved, as
described in the SQAP documents. CIs in this library cannot be modified
under any condition. New versions may only be added after they have
been externally reviewed and approved. As the CM is the only one
allowed to create new documents in the archive library, there is no need
for change control.

All documents are stored centrally on the server.

2.3 VERSION CONTROL
2.3.1 Description
The version tags follow the format x.y.z, where x denotes the external
version number, y denotes the internal version number and z denotes the
informal version number.

2.3.2 Increasing Version Number
A documents first version tag should be 1.0. The informal version number
z of a document will be incremented whenever a new version of a
document is created in order to let people give some informal feedback.
The internal version y of a document will be incremented when a version
of the document is internally approved. When this happens the informal
version number z will be reset to zero. The external version x of a

document will be incremented when a version of the document is
externally approved. When this happen both internal versions y and
informal version z are reset to zero.

2.3.3 Work Products and Documentation
All the changes will be documented from the oldest version to the newest
version revisions.

2.4 CONFIGURATION STATUS ACCOUNTING (CSA)
Configuration status accounting is the process that provides for traceability of
changes to the software and hardware.

2.4.1 Description
CM will ensure that status is recorded, monitored, and reported on both
pending and completed actions affecting the CIs. In this section CM will
define the configuration data which is to be tracked. They will specify how
the data is to be stored and what access controls will be applied to the
data. In this section CM also identifies the required configuration status
accounting reports and outlines their contents. Project CMPs can expand
the list of data to be collected or the types of reports generated.

All configuration data will be stored electronically in either the CR or CI
databases. Much of this data can be obtained by our project developers
and users through automated interaction with the SCM software. The
version control and CR tracking software will be customized to generate or
prompt for critical data. Despite the level of automation possible, some
data must be manually entered into the system. The CM is responsible for
ensuring that all necessary data is collected. This entire plan has been
written to avoid the recording or transfer of data on paper. Centralized
electronic storage prevents loss of data and can easily be backed-up.

Part of the project charter defines the information of the version control
software that is recorded such as:
a.) For each file changed or created,
i) The person who made the change.
ii) The date the change was made.
iii) The reason for the change. This is a meaningful
comment supplied by the person identified in (a).
iv) The number of the Changed Request for which this
change was made.

b) For each version label created,
i) The person who created the label.
ii) The date the label was created.
iii) The reason for the labels creation. This is a meaningful
comment supplied by the person identified in (a).
iv) The file versions to which the label was attached.

2.4.2 Work Products and Documentation
Defines the configuration data which will be tracked
Identifies the required configuration status accounting reports and
outlines their contents
All configuration data will be stored electronically
Ensuring that all necessary data is collected

3.0 SOFTWARE QUALITY ASSURANCE OVERVIEW
SCOPE AND INTENT OF SQA ACTIVITIES
REVIEWS AND AUDITS
3.1 GENERIR REVIEW GUIDELINES
3.2 FORMAL TECHNICAL REVIEWS
3.3 SQA AUDITS
3.4 PROBLEM REPORTING AND CORRECTIVE ACTION/FOLLOW-UP
3.4.1 Reporting Mechanisms
3.4.2 Responsibilities
3.4.3 Data Collection and Valuation


SOFTWARE QUALITY ASSURANCE PLAN
1.0 INTRODUCTION
1.1 SCOPE AND INTENT OF SQA ACTIVITIES
1.2 SQA ORGANIZATIONALE ROLE
2.0 SQA TASKS
2.1 TASK OVERVIEW
2.2 STANDARD PRACTICES AND CONVENTIONS (SPC)
2.3 SQA RESOURCES
3.0 REVIEWS AND AUDITS
3.1 GENERIC REVIEW GUIDELINES
3.1.1 CONDUCTING A REVIEW
3.1.2 ROLES AND RESPONSIBILITIES
3.1.3 REVIEW WORK PRODUCT
3.2.1 SYSTEM SPECIFICATION REVIEW
3.2.1.1 DESCRIPTION OF SPPR
3.2.1.2 TIMING OF THE REVIEW
3.2.1.3 WORK PRODUCT PRODUCED
3.2.1.4 REVIEW CHECKLIST
3.2.2 SOFTWARE PROJECT PLAN REVIEW
3.2.3 RMMM REVIEW
3.2.3.1 DESCRIPTION OF RMMM REVIEW
3.2.4 REQUIREMENTS SPECIFICATION REVIEW

3.2.4.1 DESCRIPTION OF RSR

3.2.5 DATA DESIGN REVIEW
3.3 SQA AUDITS
4.0 PROBLEM REPORTING AND CORRECTIVE ACTION/FOLLOW-UP
4.1 REPORTING MECHANISMS
4.2 RESPONSIBILITIES
4.3 DATA COLLECTION AND VALUATION
4.4 STATISTICAL SQA
5.0 SOFTWARE PROCESS IMPROVEMENT ACTIVITIES
5.1 GOAL AND OBJECT OF SPI
5.2 SPI TASKS AND RESPONSIBILITIES
6.0 SOFTWARE CONFIGURATION MANAGEMENT AND OVERVIEW
7.0 SQA TOOLS, TECHNIQUES, METHODS


SOFTWARE QUALITY ASSURANCE PLAN
1.0 INTRODUCTION
The purpose of this Software Quality Assurance Plan (SQAP) is to define the
techniques, procedures, and methodologies that will be used to assure timely
delivery of the software that meets specified requirements within project
resources.

1.1 SCOPE AND INTENT OF SQA ACTIVITIES
This document serves as a guide for the project manager and developers of this
project software. All team members must read this document and apply the
procedures stated in it. The document applies to all phases of software
development as defined in the Project management plan. Detailed information
about the software quality assurance activities for these phases will be added
during the project.
The use of this plan will help assure the following:
(1) That software development, evaluation and acceptance standards are
developed, documented and followed.
(2) That the results of software quality reviews and audits will be given to
appropriate management within CMS. This provides feedback as to how well the
development effort is conforming to various CMS development standards.
(3) That test results adhere to acceptance standards.

1.2 SQA ORGANIZATIONALE ROLE
The project manager reviews the product at specific times during product
implementation. Upon reviewing, the Development teams duties will be to
evaluate the software at its current development stage and recognize any defects
in the subsequent stage (design or implementation). The team will conduct group
discussions, discussing any errors or possible enhancements that have been
identified. In addition, the project manager will ensure that the development team
has not deviated in any way from the initial design specifications.

Specific responsibilities include:
Project sponsors/Client assures availability of essential project resources for
identified quality activities. Ensure resolution of quality issues escalated by the
project manager.
Project manager review and approve the quality plan. Include project quality
activities in the project plan and work assignments. Facilitate resolution of quality
issues, escalating as needed.
Business analysts help determine the alpha test, beta test and production
readiness acceptance criteria for this project. Provide feedback on the
deliverables and the requirements and testing processes.
System's analyst and Project Programmer provide feedback on the quality plan;
help determine the quality reviews, metrics and acceptance criteria for this
project. Be a part of the quality reviews (including testing) and provide feedback
on the deliverables and the overall process.
Document specialists prepare and update the quality plan and coordinate quality
reviews and checkpoints. Provide test and test management support, including
monthly status of testing and bugs. Monitor the quality activities for completion
and improvements. Review project processes and artifacts.

2.0 SQA TASKS
These are the task included in SQA:
Preparing SQA plan
Participating in the development
Review software engineering activities
Audit designated software work products
Ensure that work products are documented
Record any evidence of noncompliance


2.1 TASK OVERVIEW
All software development tasks for CMS, within the scope of this
document, will be performed by the development team. The development of
the Curriculum Management System (CMS) is managed by the Project
Manager. SQA will assure that the CMS is validated and that internal as well as
external deliverables are produced in accordance with the SDP, and this
document. SQA will certify that the Curriculum Management System (CMS)
acceptance process used will verify the acceptability for use of Course
Management.

2.2 STANDARD PRACTICES AND CONVENTIONS (SPC)
Preparing SQA plan

Participating in the development

Review software engineering activities

Audit designated software work products

Ensure that work products are documented

Record any evidence of noncompliance

2.3 SQA RESOURCES
Since we are just 5 members of the development team. We are the only one who
is designated in each tasks implicated in SQA. The SQA leader or Project
manager will be assigned to control the flow of information. The PM will oversee
the software quality control to ensure that the Development team are conforming
to the standards of the Requirements Specification document. Furthermore, the
PM will have the duty of assigning a relative rank of priority to every defect
reported - functional or cosmetic. The priority will be used to determine which

defects or enhancements are deemed the most important for the development
team to correct first. Every defect or enhancement request is submitted to the
PM for review. The PM will be in control of all SQA activities including SQA
meetings and reviews.

Project programmer will actively and frequently test the current prototype of CMS
for possible defects or necessary enhancements. This ensures that CMS is
functioning properly and follows the Requirements Specification document.
Completely debugging source code can be difficult; therefore, each PP will be
responsible for checking every major iterations of the CMS prototype to ensure
that many or most defects are intercepted in early programming stages.

3.0 REVIEWS AND AUDITS
The Development team randomly checks all product documents to ensure that
the product adheres to the document standards and that team members do their
job properly. It is observed that program code adheres to the coding standards.
Random checks are an addition to the reviews. Project document undergoes a
random check at least once. To save time, the Development team will not have
to write a report. It just reports the results to the DS and PM (possibly during a
progress meeting). If problems are discovered a date is set when the problem
must be solved and then the document is checked again. The Development team
will also conduct random checks on tools.

3.1 GENERIC REVIEW GUIDELINES
3.1.1 CONDUCTING A REVIEW
Development team will have scheduled reviews to detect any defects in
the current prototype, and to determine any notable enhancements that
should be implemented. This will be completed for the user-interface.
The current prototype will be broken down into smaller subsets and each
subset will be reviewed. The Development team as a whole (consisting of
five people) will imply each review, and critique each others part of the

software to ensure that the maximum numbers of possible defects are
accounted for.

3.1.2 ROLES AND RESPONSIBILITIES
The PM will oversee any formal technical reviews, any defects or
enhancements overseen will be discussed and recorded. Each defect or
enhancement will be given a priority rank. Once the review is complete,
the DS will make a summary of each defect or enhancement and
distribute them to appropriate team member.

Each team member will be responsible for reviewing project software
module during module creation and upon module completion. Once each
major software module is complete, it is ready for review.

3.1.3 REVIEW WORK PRODUCT
PM will keep a defect log. The defect log contains all defects and
enhancements, as well as a priority rank for each. The following will also
be noted in the defect log:
(1) Whether or not the defect or enhancement has been handled,
(2) Which software engineer oversaw the correction, and
(3) What date the correction was completed.

3.2.1 SYSTEM SPECIFICATION REVIEW
3.2.1.1 DESCRIPTION OF SSR
The System Specification Review will provide a forum to
analyze the proposed design of the software. To determine
any obvious design flaws, the focus of this review will be to
analyze the major software functions outlined in the System
Specification. Once a design defect has been recognized,

the PM will discuss with the team members any ideas or
suggestions on how to compensate for the design flaw.

The System Specification Review will be held upon completion of
the System Specification. This occurs within the first few weeks of
the CMS development. This is necessary so that the underlying
design of the CMS is sound and will not create any serious
problems for the Development team in the future.

3.2.1.3 WORK PRODUCTS PRODUCED
The PM will create a summary report of the System Specification
Review. The summary report will include any changes to the CMS
major design. Once design defects have been identified, the
Development team will discuss possible solutions. Each possible
solution will be noted and reviewed to determine if the solution will
have an impact on the rest of the design. Once all obvious design
defects have been handled, the System Specification will be
amended to account for the design changes.

Is the proposed design the best possible solution?
Is there a better way to break up the software into
subsystems? If yes, how?
Is there any obvious design flaws that have not been
accounted for? If yes, what?
Are there any necessary enhancements for the
software?
Is the proposed System Specification within the time
frame?

Is each subsystem possible to implement in languages of
choice?
3.2.2 SOFTWARE PROJECT PLAN REVIEW
The Software Project Plan review will focus on determining if the
proposed cost and scheduling estimates are feasible. If it is
determined that the proposed estimates within the Software Project
Plan are not practical estimates, the estimates will be
discussed and the Software Project Plan will be
amended to compensate.

The Software Project Plan review will be held upon completion of
the CMS Project Plan, which occur within the first few weeks of the
CMS development. This is necessary so that the scheduling and
cost estimates of CMS are within reason and can be followed
relatively precisely during the software's development cycle.

The System Project Plan review will also be held as software
development commences. This will help keep CMS on track, and
within the cost and schedule estimates.

The PM will create a summary report of the System Project Plan
review. This includes any serious over and under estimations that
have been made with regard to development time and cost. If
problems have been found, the System Project Plan will be
amended with appropriate estimate changes.

Is there enough time to complete the project overall?

Is there enough resources to complete the project overall?
Has enough time been allocated for development of CMS?
Have tasks been delegated appropriately? If not, why?

3.2.3 RMMM REVIEW
3.2.3.1 DESCRIPTION OF RMMM REVIEW
The RMMM review will focus on determining if the proposed risk
management for the development of this software is within reason.
Main focus will be on if the risk management is capable of handling
a proposed problem accordingly. If the RMMM document is not
managing each risk accordingly, the RMMM will be amended to
correct the oversight.

The RMMM review will be held upon completion of the RMMM
document. This occur within the first few weeks of CMS
development. The RMMM review is necessary, because it provides
for a decent guideline on how to handle a problem if a proposed
risk occurs early in the CMS development.

The PM will create a summary report of the RMMM review. This
includes any possible risks that have not been covered, and any
risks that have been accounted for, but are not managed
appropriately. Once a new risk is proposed, a discussion will take
place on how to handle the risk if it were to occur. Any risks being
managed inappropriately will also be discussed and an amendment
to their management will be made to better handle the risk.


Have all risks been thoroughly covered in the document? If
not, what is missing?
From the risks covered in the document, are there any that
did not seem to be effectively covered? If yes, which
one(s)?
From the risks covered in the document, are there any that
did not seem to be appropriately managed? If yes, which
one(s)?

3.2.4 REQUIREMENTS SPECIFICATION REVIEW
3.2.4.1 DESCRIPTION OF RSR
The Requirements Specification review will work to analyze
the proposed design of CMS. The focus of this review will be
to remove or discuss changes to any obvious design flaws.
Once a design defect has been encountered, the
Development team will discuss with the each members any
ideas or suggestions about how to compensate for the
design flaw.

The Requirements Specification review will be held upon completion of the
Requirements Specification. This occurs within the first few weeks of CMS
development. This is necessary so that the underlying design of CMS is sound
and will not create problems for the development team in the future.

To ensure that CMS is conforming to the restrictions of the design, each team
member will frequently conduct his own Requirements Specification review. If the
team members determines that the current design of a module is flawed, it will be
brought to the attention of the PM and an appropriate discussion to amend the
problem will be held.


The PM will create a summary report of the Requirements Specification Review.
This includes any defects or enhancements that have been brought to attention.
Once design defects have been identified, the PM will discuss possible solutions
with the Development team. Each possible solution will be noted and reviewed
again to determine if the solution will have an impact on the rest of the design.
Once all obvious design defects have been handled, the Requirements
Specification will be amended to account for the design changes.

Is the proposed design the best possible solution?
Are there any obvious design flaws that have not been accounted for? If yes,
what?
Are there any necessary enhancements for the software?

3.2.5 DATA DESIGN REVIEW
The Data Design Review will work to analyze the proposed design of the major
data members for CMS. The review will focus on determining if the design of the
data objects of the CMS is within the bounds of languages of choice
(NETBEANS or ADVANCE JAVA). Further focus will be on reviewing each data
object to determine if the object is designed correctly and efficiently. If a data
object does not make sense or is not effective in reducing CMS complexity, a
discussion of how to redesign the object to better fit within the constructs of our C
will be held.

The Requirements Specification review will be held upon completion of the
Requirements Specification. This occurs within the first few weeks of CMS

development. This is necessary so that the underlying design of CMS is sound
and will not create problems for the development team in the future.

Development team will frequently conduct Data Design review to ensure that
CMS is conforming to the restrictions of the design. If the software engineer
determines that a current data design is flawed, it will be brought to the attention
of the PM and an appropriate discussion to amend the problem will be held.

The SQA leader will create a summary report of the Data Design Review. This
includes data design flaws that have been brought to attention. Once data design
defects have been identified, the Development team will discuss possible
solutions. Each possible solution will be noted and again reviewed to determine if
the solution in question will have an impact of the rest of the design. Once all
obvious data design defects have been handled, the Requirements Specification
will be amended to account for the design changes.

Is the proposed data design the best possible solution?
Is there any obvious data design flaws that have not been
accounted for? If yes, what?
Does each data object make sense? If not, why?
Does each data object help to abstract data, or is it simply
unnecessary?
Does each data object further enhance CMS simplicity?
Does the data object contain any unnecessary information?
If yes, what?
Do the data objects interact properly or are their lines of
communication too complex?

3.3 SQA AUDITS

4 PROBLEM REPORTING AND CORRECTIVE ACTION/FOLLOW-UP
4.2 REPORTING MECHANISMS
4.3 RESPONSIBILITIES
4.4 DATA COLLECTION AND VALUATION
4.5 STATISTICAL SQA
5 SOFTWARE PROCESS IMPROVEMENT ACTIVITIES
5.2 GOAL AND OBJECT OF SPI
5.3 SPI TASKS AND RESPONSIBILITIES
6 SOFTWARE CONFIGURATION MANAGEMENT AND OVERVIEW
7 SQA TOOLS, TECHNIQUES, METHODS

Curriculum Management System

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Curriculum Management System

Transféré par

Droits d'auteur :

Formats disponibles

Curriculum Management System Page 1

Vous aimerez peut-être aussi