Computer Science Capstone Design

Assignment: Technological Feasibility Analysis

Overview

It's easy to come up with the most imaginative and crazy designs: magically updating distributed data stores, super fancy reactive graphical interfaces, massive networks of maps or nodes that all layout automatically and perfectly. We all know, however, that not all designs that you can imagine are feasible, meaning that they can't be implemented within the given cross-section of chosen platform, speed/usability goals, computational limitations, and other factors that frame your particular project. Even when projects are clearly feasible, there is the question of exactly which of many competing technologies (frameworks, database types/brands, packages, etc.) are the best choices for tackling key elements of the project.

For these reasons, it's important to (a) identify the key technological challenges and major design decision that a project presents very early in a project; (b) explore what approaches or existing products might be out there that could address those challenges; and (c) make a preliminary decision on which approach/product the team is going to choose to solve each of these challenges. In this way, the team will prove the feasibility of the project by demonstrating that they have found viable solutions to all of the key design challenges.

The most vital feature of a strong feasibility analysis is that it is done in a structured, data-driven fashion: care must be taken to be sure that all core technological challenges are correctly identified, and that the analysis of potential alternative solutions to each challenge is done carefully, i.e., rather than picking the first package or framework that comes to mind in a semi-random fashion. Too often we've had Capstone teams that have not done this well, and have chosen a technology/framework central to their project that much later – generally as implementation shifts to high gear in spring – have discovered that their chosen technology has major shortcomings. Starting back at the drawing board at that point is, needless to say, extremely stressful and disappointing.

The objective of this assignment is simply to structure your exploration of these feasibility questions, and to answer them in as complete a fashion as possible at this early project stage. Doing a feasibility analysis is a great way to make sure you have your bases covered and can launch into solution design within realistic framework for envisioning your final product.

Technological Feasibility Analysis

There are many aspects of "feasibility" that are relevant to the development of a software system: technological, market/competetive, physiological, and so on. Considering all of these might be useful to producing a successful product but, at this point, we are primarily interested in Technological Feasibility. We want to make sure that we understand that key "challenging" aspects of the project/product; identify possible technological solutions to each of them; do some research to convince ourselves that, in fact, our envisioned solution will really work; and then capture that in a document that becomes part of the project documentation. In particular, this feasibility analysis becomes your major element of design rationale for the project, sheds light on why you choose particular solutions to particular problems. Having access to such design rationale has proven to be a major factor in supporting long-term maintainance and further development of a system throughout it's life cycle. Think about it: you are given an existing system to expand/maintain, you read through the as-built document, consult the code (hopefully well-commented), and you invariably ask yourself "why did they do it that way? Why did they choose this algorigthm, this tool, this framework?". The design rationale documentation provides exactly this insight to these higher level design questions; for each of the technological challenges you identify it:

Outlines what the design decision or technological challenge is, and how its functions are relevant to the overall outcome of the product
States what the alternatives (frameworks, products, packages, algorithms) for addressing that challenge that were identified as candidate solutions.
How all of the alternatives were explored or evaluated, i.e., what preliminary coding was done or how rankings of alternatives were arrived at.
Which alternative was chosen, based on the outcomes of the analysis.

When combined with the technology demo deliverable due near the end of the term, essentially "proves" that you have a solid and realistic foundation for system implementation.

Technological Feasibility: Scope

The exact content of a feasibility analysis will vary depending on the exact project, as you might expect; each project has its own unique constraints and technological challenges. Here are a just a few topical areas that might be relevant to your project, just to prime your own thinking:

Programming and scripting languages
Database technologies
Networking and communication: framework, libraries, protocols
Front-end libraries/frameworks, particularly those supporting dynamic, rich-media content through the web, i.e., Web2.0 sites
Device-specific interfaces and libraries (mobile or embedded computing)
Off-the-shelf service providers, e.g., cloud hosting or resources you plan to integrate, or existing services that you'll build into your product.
Graphics engines, algorithms, and libraries. If you need to do something computationally interesting (e.g., scene analysis, complex data processing, etc.), then you'll want to have a firm idea of what software exists that you could use, versus what you'd be looking at writing yourself.
APIs to remote services (for example, REST or SOAP interfaces)
Modeling languages or schema definitions

Technological Feasibility: Content

As always in any design process, your goal here is to proceed in a logical fashion...and to make that "story" clearly visible to your reader in your written report. Overall, you want to start by introducing the project (as in every document!), then introducing the major technical challenges and key design decisions you foresee in your project. You will then have major subsections (generally with identical internal flow) that go though and present your detailed analysis of each design challenge/decision. Here is a basic outline for your document:

Cover Page and TOC: Of course you should have the customary cover page for your report. If any project document is longer than five pages (which this one most certainly is), then you should include a Table of Contents as the second page, outlining the major subsections (but not the sub-sub sections, subsubsub-sections etc...don't index every single heading!)

Introduction: Every single document related to a project should have an introduction; you never just dive into the meat of things! Think of our story-telling metaphor! In this introduction, you are briefly going to "sell" your project: remind people why it's important and how amazing your solution vision is. Here is the flow:

Start with the "big picture" paragraph: Why should the world care? Stuff like "Over 50 million Americans suffer from diabetes and it costs our healthcare system XX billion/year" for a project related to diabetes management, or "Species extinction is wiping out xx species a year" for a project related to monitoring/addressing natural preservation". Often you can get a start on this from your project description document, plus conversations with your sponsor. After finishing this section, your reader should be thinking "This is a really serious and important issue!"
Then talk about how the problem you invoked is currently being dealt with. Start with how current solutions look like in general, and then introduce your sponsor and how the role their outfit plays in the process, i.e., how they specifically have been trying to solve the problem. Then narrow it done to the problems your sponsor has: how, if at all, has your sponsor been managing so far? What is there "current solution"? Obviously you'd want to highlight how inadequate/inefficient/labor intensive the current approach is. Be specific: this is also your chance to educate the reader about how the "business process" of your sponsor works. After finishing this paragraph(s), your reader should be thinking "wow, what a mess...something needs to be done!"
Now that you've set the stage, you are finally ready to introduce your solution vision. Start with a general sentence or two that describes your overall product/approach (i.e., we're building a webapp/mobile app/whatever) and what it does in general. Then go on to highlight a few of the key features/functions; it should be immediately obvious to the reader that these proposed features are exactly what is needed to address the client problems you outlined earlier!

A good intro section is absolutely critical. In real life, many managers/investors are going to read the intro of your document...and if that doesn't grab their attention, they won't really bother with the rest. You should see this project intro section as an investment for your entire capstone year: you can essentially re-use this intro section on all project documents, refining it a bit more each time, until it appears on your final project report! In term of length: it's hard to do a good intro in less than 0.75 pages...and if it stretches beyond about 1.5 pages that it's too lengthy.

Segue into the main document body: A "segue" is transition, or bridge, between the sections of a document. Think of them as the glue that smooths the way between topics and helps the whole thing flow. You'll want them throughout your document, as you transition from talking about one thing to talking about another. They often sound something like this "Now that we have established that X,Y, we are ready to turn to a more a careful analysis of Z. In the next section, we <outline topics>." As your first segue from the intro discussion into the main document, you'll want to turn from talking about the project in general to telling the reader what role the upcoming document plays and how it is structured. So something like "At this early stage in the project, we are in the process of analyzing the key technological challenges, identifying possible alternatives, and selecting which of those alternatives are the most promising solutions." Ok, good, now go on to briefly outline how your discussion will be organized: "In this Technological Feasibility Analysis document, we begin by analysing the major technological challenges we expect <blah blah>; in the subsequent major subsections, we then analyze each of these areas carefully in turn, looking at alternatives, how we explored these, and rationale for choosing a particular solution; in Section Z, we then...". You get the picture: outline how your argument will flow.

Having outlined your "story" in this way, you now just launch into providing the flesh on the bones:

Technological Challenges: In this section, you will outline all of the major "technological needs/challenges" that you see facing in your project. Of course, you may discover others later, but the whole point of this exercise is to think carefully at this early point, to avoid those surprises later on. So every major piece of the system that you can envision having to deal with based on what you know so far should be covered. These are essentially "high level requirements" for your system, things that it'll have to do...which raise the question of "how are we going to implement that?" The detailed contents here will, of course, vary widely depending on the project details; no two will be identical within our class! Just as examples, you might have things like:

We will need a secure interaction and user authentication on our web app.
We will need a way to communicate between our mobile app and the embedded hardware controller
We will need a way to provide a highly reactive interface in order to do <outline what specific functions require this> in our product.
We will need a reliable data store backing our product that is capable of secure, highly-accessible storage of <quantity> of data.
We will need a way to keep the mobile apps synchronized to a level of fidelity of X seconds of delay between all of the users connected to the same group.
We will need a way to spatially lay out a graphical genetic map based on a large database of genetic markers and their genomic positions.

You get the picture: every team will need to brainstorm to think about the specific technological hurdles they need to overcome. The emphasis here is on "major" and on "hurdles". There's no need to worry or talk about design details that are minor and unproblematic. You're not doing the full design here, you're trying to highlight and treat the major design decisions.

Technology Analysis: This is the meat of your whole feasibility analysis; it constitutes the bulk of this document! In the intro/segue to this section, you will introduce the major technological issues or design decisions that you have identified as critical to project success in your early project explorations with the client. In the following major (3-5 page) subsections, you will then work through each of these issues in detail, describing the issue, your detailed, analysis, and its outcome. Specifically, each subsections will likely have its own subsections as follows:

Intro the issue. Talk about the issue/challenge in a bit more detail, give some detail about what functions you see needing to provide and the role that you see them playing in the final product.
Desired Characteristics: Now that we understand the design decision or tech challenge overall, talk about what an ideal solution would look like. In particular, you want to introduce the "key characteristics" that an ideal solution would have that are directly relevant for your particular project. This will vary by project, of course, but some typical characteristics might be licensing cost, speed/performance, ease of maintenance, existing user base, how mature the tech is, and so on. For each issue you identify, you must make it clear why this characteristic is important for your particular project. Just because someone else used this solution doesn't mean it's a good fit for your project! These characteristics are vital: they become the "metrics" on which you will be evaluating the alternative solutions.
Alternatives: Now introduce the possible approaches to addressing this particular issue. For each one, have a little paragraph where you introduce the alternative, say a little about how you found it (e.g. comparing approaches on forums, client recommended you look at it, whatever). Then give few overview sentences with some general background on that product/package/framework: who developed it, how long has it been around, who has typically used in before and in what kinds of applications. Not a major novella, just help us understand a bit about this product.
Analysis: Now you're ready for the important part: describe how you evaluated each of the alternatives on each of the criteria (desired characteristics) that you outlined earlier. "Evaluation" could take many forms: maybe you installed each of the alternative packages and subjected them to some basic testing, or maybe programmed a little 'hello world' trial in each of them; if you criterion was security, maybe you dug into the security features that each option provides and/or investigated how it ranks of various security forums. There is no magic formula, it will vary depending on project and criteria chosen. The key is that you show that you have done "reasonable" and logical investigation of each alternative on each criterion...versus just flipping a coin and choosing one!
Chosen approach: To end the subsection, you bring your investigations on that technological choice to a decision. Start with a few summary sentences on what you found: pros and cons of the various options. Then bring this to a point with a little table where you have the alternatives in one dimension, and "desired characteristics" in the other; the table is then filled with rankings (e.g. scale of 1-5, red/yellow/green dots, whatever) of each alternative on each criterion. You've all seen these kind of comparison tables, e.g., comparing pros/cons/features of various software products, etc. Again, it should be clear how those ranking could have emerged from the analysis that you did, versus just something you're making up. You then have a short paragraph that discusses the table and what it shows, and how this leads you to chose alternative X as the most promising solution to that technological design decision.
Proving feasibility: So you've done some basic investigation and analysis and have made a rational choice of one particular alternative as the way to go. Moving forward, however, you'll want to go beyond this preliminary analysis to *actually show* that the solution **will actually work** for the challenge raised by this particular project, i.e., when used for its actual task on the project. So in this short closing paragraph, you outline your plans for further testing/validating your choice. In particular, you outline some specific "demos" that you will develop as part of the "Technology Demo" assignment due later in the first Capstone semester.

Technology Integration: In this section, you need to bring it all together. You've introduced individual challenges and how you plan to solve them...but how will all of these "micro-solutions" come together into a coherent overall system. A great way to organize this is to write an little intro where you segue in, then talk about needing to put all the pieces together into a coherent architecture that is capable of satisfying all of the product requirements. You then introduce a "system diagram" of your envisioned system that shows how the major elements relate to each other. What things are connected to others, what things are inside or part of others, how data or tasks flow between them. Then you briefly walk through the diagram in subsequent narrative, making it clear how the parts work together within the broader product you're building. This is essentially a first cut at envisioning an overall software architecture for your system.

Conclusion: No document is ever complete without a conclusion. What you're trying to do in any conclusion is to (a) remind reader of the problem and how important it is; (b) summarize what you've covered in the document, including a few highlights; and (c) close in conveying the sense that you've done a complete and competent job...and how you'll now be moving forward with the projects next steps. Keep in mind that many busy readers (e.g. your boss/division manager/CEO) will read just two things: the document intro, and the conclusion.

Deliverables

To provide learning feedback and give a chance for you to improve the document, we will be doing this document in two steps: A "Initial submission (draft)" phase; after you get feedback on that, you will then submit the final report. Deliverables:

1st submission: Submit a professional copy of your draft document to your team mentor (Canvas) for grading and feedback. This is due by the due date shown in the course schedule.
Final Submission: Submit the improved, final version of your Feasibility Report in professional hardcopy to your team mentor, as well as your marked up draft report, to help your mentor evaluate how well you have been able to address earlier feedback. Due on date shown on course schedule.
To client: You should also provide the final version of your Feasibility Report to your client. As always, any documents that go to client should be of top quality, i.e., bound in an attractive report cover.