Transcript MSCS Graduate Project Guidelines

MSCS Graduate Project
Guidelines
Computer Science & Software Engineering
April 13th, 2011
Overview
• Independent projects
– Worth of 8-9 credits
– Spanning 2-3 quarters
• Workload
– 3 hours per credit per week
• Work with a faculty member
• Two options
– Software implementation projects
– Research projects
How to Start Your Project?
• A project request form must be submitted and
approved before you can register for a project course
• Submit your project request form during the quarter
prior to the planned start of the project:
Starting quarter
Deadline
Fall/Summer*
May 15th
Winter
November 1st
Spring
February 15th
• Meet with your project advisor to refine the project
topic and begin planning after approval
What is on a Project Request Form?
• The form include a title and brief description
of your desired project topic
• It also includes the names of one or more
faculty you think would be appropriate
advisors for your project
• You are encouraged to talk to faculty members
before submitting the form
Software Implementation Project
• Goal
– Design and implement software to address
problems/applications
• Examples:
– simulators, research tools, courseware tools and
new applications/services
Software Implementation Project
1. Submit your project proposal (the first quarter)
–
The first quarter
Deadline
Fall
October 10th
Winter
January 25th
Spring
April 15th
What should be included?
•
•
•
•
Project overview
What problems/application to address?
Project deliverables (documentation, source code…)
Project timelines (tasks and milestones, activities schedule)
Software Implementation Project
1. Submit project proposal (the first quarter)
2. Work on project (weekly meetings, 3 hours per
credit per week)
Software Implementation Project
1. Submit project proposal (the first quarter)
2. Work on project (weekly meeting, 3 hours per
credit per week)
3. Submit project progress report (the end of the
quarter, but not the last quarter)
Software Implementation Project
1. Submit project proposal (the first quarter)
2. Work on project (weekly meeting, 3 hours per
credit per week)
3. Submit project progress report (the end of the
quarter, but not the last quarter)
4. Final deliverables
Software Implementation Project
1.
2.
3.
Submit project proposal (the first quarter)
Work on project (weekly meeting, 3 hours per credit per week)
Submit project progress report (the end of the quarter, but not the last quarter)
4. Final deliverables
–
Documentation
• Project goals, design, testing, user documentation,
deployment & maintenance guidelines
– Experience report
• Accomplishments, open issues, lessons learned
– Source code
– Final presentation & demo
Software Implementation Project
Grading
Component
Percentage (%)
Proposal
15
Progress report
5
deliverables
55
Final presentation
15
Professionalism*
10
* Commit your time and meet deadlines.
Research Project
• Conduct in-depth studies on selected topics
• Produces a technical report suitable for
publication
• Might involve implementation components as
part of evaluation
• More challenging than software implementation
projects!
• Examples:
– Framework development, measurements and
analysis, modeling, prototypes of new systems
Research Project
1. Literature review
–
–
–
–
Review the published literature on the selected topic
Learn more about the selected topic
Narrow the scope of the study/investigation
Provide inspiration for possible solutions / ideas that can
be investigated in the proposed research.
Research Project
1. Literature review
2. Submit your project proposal (the first quarter)
–
The first quarter
Deadline
Fall
October 25th
Winter
February 10th
Spring
April 30th
What should be included?
•
•
•
•
•
•
Problem statement
Related work
Justification
Evaluation
Research plan (tasks and milestones, activities schedule)
References
Research Project
1. Literature review
2. Submit your project proposal (the first quarter)
3. Work on project (weekly meetings, 3 hours per
credit per week)
Research Project
1. Literature review
2. Submit your project proposal (the first quarter)
3. Work on project (weekly meeting, 3 hours per
credit per week)
4. Submit project progress report (the end of the
quarter, but not the last quarter)
Research Project
1. Literature review
2. Submit your project proposal (the first quarter)
3. Work on project (weekly meeting, 3 hours per
credit per week)
4. Submit project progress report (the end of the
quarter, but not the last quarter)
5. Deliverables
Research Project
1.
2.
3.
4.
Literature review
Submit your project proposal (the first quarter)
Work on project (weekly meeting, 3 hours per credit per week)
Submit project progress report (the end of the quarter, but not the last quarter)
5. Final deliverables
–
Technical report
•
–
–
Abstract, Introduction, Related work, Description of research,
Evaluation & results, Conclusions, Future work, References
Source code, data, …
Final presentation
Research Project
Grading
Component
Percentage (%)
Proposal
15
Progress report
5
Research work
35
Technical report
20
Final presentation
15
Professionalism*
10
* Commit your time and meet deadlines.
Resources
• MSCS Project Guidebook for Faculty and
Students
• MSCS Project Request Form
• MSCS Project Progress Report
All will be available on the department website!
Q&A
WORKING WITH FACULTY
Areas of their research interest
Richard LeBlanc
Professor and Department Chair
Areas of Interest
•
•
•
•
Software Engineering
Programming Languages
Compilers & Programming Environments
Computing Education
• Things of great interest to you
Susan Reeder
• Projects for St. Joseph Catholic Church, Issaquah
– Build new OWA server
• Connect to Exchange server behind firewall
– Web site work
• Upgrades
• Social network for small groups
– Security work
• Policy development
• Risk assessments, critical asset identification &
protections
• Endpoint protection-build out a program for re-imaging,
eradicating malware, etc.
• Penetration testing
Susan Reeder
• St. Joseph Catholic Church, continued
– Other
• Migration to Win7, Office2010 or move to Google docs
• Mobile device support for staff
• Church wireless infrastructure including legal vetting of
having a public hotspot
• Big screens in the sanctuary & gathering space for
music lyrics, sermon support, videos
• Liturgical Ministry scheduling support (web or email)
Adair Dingle, Professor CSSE
Primary interest: SOFTWARE DESIGN
Code construction
Software Maintenance
Legacy Code
Memory management
ownership, temporaries, integrity
Software Modeling for design
Adair Dingle, Professor CSSE
Secondary interest: ALGORITHMS
Heuristics
Garbage Collection
Prof. Annie Dai
[email protected]
Research Project
• Goal: Bridge the gap between Software Development and
Information Security
Information Security
Software Development
Security Design Methodologies
Software Developers:
Familiar with..
Software development models
Design methodologies
Architecture styles…
Lack..
Security domain knowledge
Often fail to recognize security
flaws and solutions
Security Verification and Analysis Tools
Security Languages
Security Platforms
Security Frameworks
Security Libraries
Some images are from google image.
Security Professionals:
Familiar with..
Real-world attacks
Software vulnerabilities
Security techniques
Lack..
Overall knowledge of system design
Reactive solutions , installing software
patches, shoring up firewalls, updating
intrusion detection signature databases..
E-Health System Security Development
• The healthcare industry is shifting
to e-Healthcare practice.
– Effective and timely communication
– Collaboration among distributed
physicians
– Coordinated healthcare services for
patients
– …
• Many security issues
– Patient records are highly sensitive
– Decentralized players, doctors,
nurses, insurance, researchers.
governments, employees
– Interoperability of health records
– Complex nature results many
traditional security solutions cannot
apply
Laws
Policies
Best Practice
Domain-Specific Generic
Security & Privacy Primitives
e.g. Consent, Roles, Context,
Situation, De-Personalization
Generic/Core Security & Privacy Primitives
e.g. Authentication, Authorisation, Integrity,
Non-repudiation, Confidentiality, De-Identification etc.
The Pyramid of Security and Privacy for e-Healthcare Information
From: Electronic Healthcare Information Security
Architecture Development for Simsys: An Engaging
Game for Software & Systems Engineering
Simsys is a game platform that is developed to support the complex, interactive
simulation of software development for software and engineering education.
Goal: allows students to play games that explore and deeply
understand the complex dependencies among SE/Sys
stakeholders, their activities, and the engineering artifacts
they create.
– E.g., how does a decision made by a Requirements
Analyst constrain the decisions made by a designer,
tester, and project manager?
– Simulate complex “what if” scenarios in SE/Sys
development
– students can try out different roles (manager, designer,
developer, tester,…)
Architecture Development Goal: investigate architectures for Simsys to support multiple
and distributed players
Prof. Roshandel
[email protected]
Research Interest
• General area of software engineering
– Interested in developing principles, methodologies
and tools that help develop high quality software
systems
• Background:
– Software architecture
– Reliability modeling and analysis
– Security
Reliability Analysis for Software
Product Families
• Product families: Related products developed
for different markets, as upgrades,
adding/removing features, new variations
• Architecture-centered reliability analysis for
product families
– Develop approaches and tools to reuse parts of
reliability models, and analysis results by
exploiting the commonalities among the products
within a family
Multi-Layered Intrusion Detection for
Smartphones
• Proliferation of smartphones, coupled with their
advanced computational power, and large
volume of personal and confidential data makes
them an attractive target for security attacks
• Project Goals: Develop a framework and toolsuite to make the network of smartphones
resilient to emerging security threats
– Intrusion detection based on individual user’s
behavior and aggregate behavior of a group of users
RESISTing Reliability Degradation
through Proactive Reconfiguration
• Domain: Systems with dynamism and
unpredictability in their runtime architecture and
runtime behavior
– Self-adaptive systems
• Maintain a certain level of system reliability, while
taking into account other quality attributes of
concern (e.g., efficiency)
– Optimization problem
• Use the analysis to proactively adapt the system
at runtime (not reactively)
Dr. Larson’s Research
• Software Bug Detection
• Software Testing
• Software Bug Prevention
• Program Analysis (relating to the above areas)
Possible Research Projects
• Developing new techniques to find bugs
– Static analysis, runtime monitoring
• Testing tools and techniques for scripting
languages
• Testing tools and techniques for multithreaded
programs
– Especially for novice programmers
• Analysis of paths, loops, function calls
– C++ / Java / C#
Other Potential Areas
• Programming Languages (with a bug detection
/ prevention focus)
• Debugging
• Compilers
• Computer Architecture
• Operating Systems / Computing Systems
• Tools for Computer Science / Software
Engineering Education
Data Projects
Working with Jeff Gilles
Cassandra
Areas of Work
• Relational– Transactional – SQL
• NoSQL
• Wide Column Store
– Hadoop, Cassandra, SimpleDB
• Key/Value Store
– Azure Table, Hibari, Tokyo Tyrant
• Graph Databases
– Sones, Trinity, DEX
• Object Databases
– Versant, Objectivity, NEO, ZoDB
• Multivalue Databases
– U2, OpenInsight
Projects
• Object Database
– Reference Implementation
– Porting
• Others
– Architectures
– ACID capabilities
– Retrieval Issues
– Cost/Benefit
Dr. Yingwu Zhu
Area of Interest
•
•
•
•
•
Distributed systems
High-performance computing
Peer-to-peer networks
Social networks
Goal: Efficient information sharing, search, &
dissemination on large-scale distributed systems
• Possible projects: crawl social network sites to do
measurement and analysis