CMSC B399 Senior Conference - Spring 2024
Milestone #2: Extended Abstract
Due Friday Feb 16, 2pm EST

Overview and Objectives

The Extended Abstract, serves as a more detailed proposal that adds further information about the problem area, your proposed solution, and how you intend to implement and evaluate it, as well as a
review of related work and a schedule for finishing the project in the Spring. This document also serves as a progress report on the work you’ve done so far. You may reuse parts of your proposal and Outline where appropriate, but please be sure to complete all sections in this document. In completing this assignment, you will:

- Flesh out additional details of your project
- Organize: what you’re going to do, why you’re doing it, how you’ll know you’ve done it
- Consider different options for approaching your solution and evaluate their tradeoffs
- Decompose a large, complicated solution into smaller pieces
- Determine the appropriate scope of your project by creating a delivery schedule

This may feel like a lot of writing so early in the project, but much of what you write here will be in your Final Report. The idea is to get this writing done sooner rather than later, and in so doing so flesh out your ideas and plans.

Structure
Your Extended Abstract should be a PDF document of around 6-8 pages; single- spaced, 12-point serifed font with 1.0 inch margins all around. The Extended Abstract should have the following sections:

1. Title of Project
2. Student & Advisor Information
3. Summary
   Describe your project in one sentence.
4. Problem Statement (Goals)
   Expand on the problem statement you provided in your proposal. In particular, give a broader overview of the problem area or domain that your project will address, or the overall goal of your project. You should answer such questions as:
   
   - What is the problem you’re trying to solve, or the overall goal of the project?
   - Why is this important?
   - Why is this difficult?
   - Who will benefit from solving this problem or achieving this goal?
   
   
5. Solution (Approach, Features, Requirements)
   In this section, describe your solution in more detail than what you provided in your proposal, incorporating the feedback you received from your classmates and subsequent meetings with your advisor. If you are developing software or a computing system, you should identify the requirements or major features of the solution, e.g. using user stories and engineering tasks. If you are working on an algorithm or a conceptual solution, describe it in enough detail so that a person who is familiar with this area of Computer Science would be able to understand and potentially implement it
   themselves. In addition to describing your solution, be sure to mention:
   
   - What is your intuition for why this will be a good solution? Show that it is clearly relevant and appropriate for solving the problem you identified.
   - How will it address the things you identified as difficult in your problem statement?
   - How sure are you that your solution is technically feasible?
   - What have you done so far that makes you think so?
   - Also think about whether there may be any legal requirements regarding the use of your system and the data and functionality it provides, for instance: security and access control; data privacy and integrity, e.g. adherence to FERPA, HIPAA, etc.; record keeping and logging for auditing purposes
   - user interface accessibility, e.g. adherence to the Americans with Disabilities Act (https://www.justice.gov/sites/default/files/crt/legacy/
   2009/02/18/oldsoftware.pdf). Likewise, consider any ethical implications of your solution: are there ways in which individuals, or society in general, be put at risk through the use (or misuse) of your solution?
   
   
6. Design
   Whether you’re building a piece of software, a system, or an algorithm, or applying something that already exists to a set of data, there are bound to be different ways to implement or “realize” what you want to create. “Design,” then, is the activity of considering some of those different ways, evaluating their tradeoffs, choosing one, and decomposing it into smaller pieces that can be addressed when you start to implement your solution. Start by describing the major components/modules/pieces of the things you are building. Although it may be hard to exactly define what that means, think of them as “things that can stand alone but are then combined together to form our solution.” These may be things like:
   
   - user-facing applications, e.g. mobile apps or webapps
   - server software that uses APIs and protocols such as HTTP, WebSockets, REST, SOAP, etc.
   - data sources such databases or file systems
   - hardware components
   
   For each of these components, describe what its responsibilities are and what technologies it will use. Also include an explanation or diagram showing how the components will relate to each other and how they will communicate and interact. Since design is about tradeoffs, you should also answer these questions:
   
   - What other design options did you consider?
   - Why did you pick this particular one?
   - What makes you think this design is “good” on its own, not just “better than the alternatives”?
   
   Try to demonstrate that you considered other reasonable alternatives and made a conscious decision to move forward with the one you described in the previous section. Of course, in some cases there may not have been a decision to make, e.g. if a particular data source is only available from one web service using one protocol, but for other components for which there are reasonable alternatives, you need to justify your decisions.
   
   
7. Implementation (Progress to Date)
   Briefly describe the progress you have made so far in implementing your solution. You should refer back to requirements/features from the Solution section and aspects of your design from the Design section so that it is clear what you have done and what still is left to do. By this point, you should at the very least have completed some sort of proof-of- concept so that you know that your solution is technically feasible. Please do not include source code in this document, but you can include diagrams or screen shots as needed to show what you have done.
   
   
8. Evaluation Plan
   In this section, describe how you will know that your solution has solved the problem that you have identified. You should provide more detail about your evaluation plan than you did in your proposal. As with just about everything else in this document, you can change this later in the project, but at this point there should be enough information so that someone could actually perform the evaluation you’re describing, assuming there is something to evaluate. If you are performing a user study, think about: Who are the users? What will you ask them to do? How will you collect information? Once you have that information, how will you relate it back to your problem statement? If you are doing some sort of experiment, e.g. to evaluate an algorithm, think about: What data will you use? How will you state your hypothesis? How will you try to validate it? What are the threats to validity? The goal of this section is not only to get you to try to relate your solution back to your problem, but also to avoid any “oh, we should have…” situations later in the project when it comes to things like data collection.
   
   
9. Related Work
   Give an overview of related work in this area. This can include other attempts to solve the same problem (or similar problems), or other solutions that are similar to yours but perhaps were targeted at different problems. This section does not need to be super-thorough, but should convey the idea that you have looked into what other people have tried to do and understand where your solution stands in relation to theirs. In a related work section such as this, it is not enough to say, “these people did this; these other people did that” because you need to convince the reader that what you are proposing is in some way better than what has been done before. For each work that you describe, provide a sentence or two explaining why your solution will be better than what already exists. It may simply be that other solutions weren’t necessarily addressing the exact same problem, or that they tried to tackle some other aspect of the problem, but demonstrate here that you are aware of other work in this space and where your work will be placed within it.
   
   
10. Schedule
    To make sure that you are able to complete all the work presented in this document by the end of the semester, briefly describe what you hope to achieve by the milestones in terms of your implementation. Be sure to discuss this schedule with your faculty advisor to make sure that you’re all on the same page!
    

Submission and Presentation
Submit the Extended Abstract in PDF form by email to dkumar@brynmawr.edu. If working in a group, only one submission is required for the group.

During the class meeting on the date on which this document is due, your team will do a brief, informal presentation of the document to the instructor and to your classmates. You do not need to put together a presentation or anything like that (hence “informal”) but you may be asked to show the document on-screen and walk us through the main parts so that we can get a sense of your project and also provide feedback. Come prepared.