Natural Language Processing

Natural Language

Refers to the language spoken by people, e.g. English, Japanese, as opposed to artificial languages, like C++, Java, etc.

Natural Language Processing

NLP is the branch of computer science focused on developing systems that allow computers to communicate with people using everyday language.NLP is related to human -computer interaction.  NLP encompasses anything a computer needs to understand natural language and also generate natural language.NLP is a sub field of artificial intelligence. Devoted to make computers “understand” statements  written in human language. 

Why Natural Language Processing  

•kJfmmfj  mmmvvv  nnnffn333

•Uj iheale eleee mnster vensi credur

•Baboi oi cestnitze

•Coovoel2^ ekk; ldsllk lkdf vnnjfj?

•Fgmflmllk mlfm kfre xnnn!

Computers “see” text in English the same we have seen the above text!

People have no trouble understanding language 

• Common sense knowledge 
• Reasoning capacity 
• Experience 

Computers have 

• No common sense knowledge 
• No reasoning capacity 

 that’s why we need natural language processing. 

Steps in natural language processing

 

Morphological analysis

Individual words are analyzed into their component and non word tokens. punctuation are separated from word .

e.g   carried= carry+ed

Syntactic analysis

.grammatical structure of sentence is analyze. some word sequence may be rejected if they violate the rules of language . e.g  syntactic analyzer reject the sentence 

  “Boy the go  the to store”

Semantic analysis

. determine possible meaning of sentence.

. Sentence which has no meaning is rejected.

. For eg “ colorless green ideas ” has no meaning.

Discourse Analysis

. The meaning of  an individual sentence may depends on  the sentence that precede it and may influence the meaning of sentences that follow it.

e.g  “john wanted it” the word ‘it’  depends upon john.

Pragmatic analysis

. It derives knowledge from external commonsense information.

. It means understanding purposeful use of language in situation.

e.g   “ DO you know what time it is?”

   should be interpreted as a request.

Software Development Fundamentals

Management fundamentals

Estimation and Scheduling

Well-run projects go through three basic steps to create a software schedule. They first estimate the size of the project, then they estimate the effort needed to build a product of that size, and then they estimate a schedule based on the effort estimate.

Planning

software development problems

•  Ill-defined contract
•  Unstable problem definition
•  Inexperienced management
•  Political pressures
•  Ineffective change control
•  Unrealistic deadlines

 software project includes these activities

• Estimation and scheduling
• Determining how many people to have on the project team, what technical skills are needed, when to add people, and who the people will be
• Deciding how to organize the team
• Choosing which life cycle model to use
• Managing risks
• Making strategic decisions such as how to control the product's feature set and whether to buy or build pieces of the product

Tracking
Once you've planned a project, you track it to check that it's following the plan—that it's meeting its schedule, cost,' and quality targets. Typical management-level tracking controls include task lists, status meetings, status reports, milestone reviews, budget reports, and management by walking around. Typical technical-level tracking controls include technical audits, technical reviews, and quality gates that control whether you consider milestones to be complete.

Measurement

You need to have a basic knowledge of software measurement to develop efficiently. You need to understand the issues involved in collecting metrics, including how much or how little data to collect and how to collect it. You should have a knowledge of specific metrics you can use to analyze status, quality, and productivity. An organization that wants to develop rapidly needs to collect basic metrics in order to know what its development speed is and whether it's improving or degrading over time.

Requirements Management

  Requirements management is the process of gathering requirements; recording them in a document, email, user-interface storyboard, executable prototype, or some other form; tracking the design and code against them; and then managing changes to them for the rest of the project.

Here are the fundamentals of requirements management

• Requirements-analysis methodologies including structured analysis, data structured analysis, and
  object-oriented analysis
• System-modeling practices such as class diagrams, data flow diagrams, entity-relationship diagrams,data-dictionary notation, and state transition diagrams
• Communication practices such as Joint Application Development (JAD), user-interface prototyping, and general interview practices
• The relationships between requirements management and the different life cycle models including evolutionary prototyping, staged releases, spiral, waterfall, and code-and-fix

 Design Management

 Just as it makes sense to create a set of blueprints before you begin building a house, it makes sense to create an architecture and design before you begin building a software system. A design error left undetected until system testing typically takes 10 times as long to fix as it would if it were detected at design time.

 Software Configuration Management

 the practice of managing project artifacts so that the project stays in a consistent state over time. SCM includes practices for evaluating proposed changes, tracking changes, handling multiple versions, and keeping copies of project artifacts as they existed at various times.

Quality-Assurance Fundamentals 

projects try to save time by reducing the time spent on quality-assurance practices such as design and
code reviews. Other projects—running late—try to make up for lost time by compressing the testing
schedule, which is vulnerable to reduction because it's usually the critical-path item at the end of the project.These are some of the worst decisions a person who wants to maximize development speed can make because higher quality (in the form of lower defect rates) and reduced development time go hand in hand.

Error-Prone Modules

An error-prone module is a module that's responsible for a disproportionate number of defects.Barry Boehm reports that about 20 percent of the modules in a program are typically responsible for about 80 percent of the errors (Boehm 1987b).Modules with such high defect rates are more expensive and time-consuming to deliver than less error-prone modules.

Testing

The most common quality-assurance practice is Undoubtedly execution testing, finding errors by executing a program and seeing what it does. The two basic kinds of execution testing are unit tests, in which the developer checks his or her own code to verify that it works correctly, and system tests, in which an independent tester checks to see whether the system operates as expected.

Technical Reviews

Technical reviews include all kinds of reviews that are used to detect defects in requirements, design, code, test cases, or other project artifacts.

• walkthrough:- The term "walkthrough" is loosely defined and refers to any meeting at which two or more developers review technical work with the purpose of improving its quality.
• Code reading:- In code reading, the author of the code hands out source listings to two or more
  reviewers. The reviewers read the code and report any errors to the author of the code.
• Inspections:- The "moderator" hands out the work product to be inspected before the inspection meeting. The "reviewers" examine the work product before the meeting and use checklists to stimulate their review. During the inspection meeting, the "author" usually paraphrases the material being inspected, the reviewers identify errors, and the "scribe" records the errors. After the meeting, the moderator produces an inspection report that describes each defect and indicates what will be done about it.

General Strategy for Rapid Development

We can achieve rapid development by following a four part strategy:

1. Avoid classic mistakes.
2. Apply development fundamentals.
3. Manage risks to avoid catastrophic setbacks.
4. Apply schedule-oriented practices

Four Dimensions of Development

People

people ware issues strongly influence productivity, it is also now crystal clear that any organization that's serious about improving productivity should look first to the people ware issues of motivation, teamwork, staff selection, and training. There are other ways to improve productivity, but people ware offers the greatest potential benefit. If you are serious about rapid development, you have to be serious about people ware issues.

any organization that wants to improve its productivity should be actively trying all these things.

• Team organization
• Motivation.

Process

Process, as it applies to software development, includes both management and technical methodologies.

A focus on process can help.

• work avoidance.
• Quality assurance.
• Development fundamentals.
• Risk management.
• Resource targeting.
• Life cycle planning.
• Customer orientation.

Product
The most tangible dimension of the people/process/product/technology compass is the product dimension, and a focus on product size and product characteristics presents enormous opportunities for schedule reduction.

Both product size and product characteristics offer opportunities to cut development time.

• Product size.
• Product characteristics.

Technology

 The current move toward component ware (VBXs and OCXs) might eventually produce similarly dramatic results. Choosing tools effectively and managing the risks involved are key aspects of a rapid-development initiative.

Classic Mistakes

Some ineffective development practices have been chosen so often, by so many people, with such
predictable, bad results that they deserve to be called "classic mistakes."

People

• Undermined motivation.
• Weak personnel.
• Uncontrolled problem employees.
• Heroics.
• Adding people to a late project.
• Noisy, crowded offices.
• Friction between developers and customers.
• Unrealistic expectations.
• Lack of effective project sponsorship.
• Lack of stakeholder buy-in.
• Lack of user input. 
• Politics placed over substance.
• Wishful thinking.

Process

• Overly optimistic schedules.
• Insufficient risk management.
• Contractor failure.
• Insufficient planning.
• Abandonment of planning under pressure.
• Wasted time during the fuzzy front end.
• Shortchanged upstream activities.
• Inadequate design
• Shortchanged quality assurance.
• Insufficient management controls.
• Premature or overly frequent convergence.
• Omitting necessary tasks from estimates.
• Planning to catch up later.
• Code-like-hell programming.
  

Product

• Requirements gold-plating.
• Feature creep.
• Developer gold-plating.
• Push-me, pull-me negotiation.
• Research-oriented development.
  

Technology

• Silver-bullet syndrome.
• Overestimated savings from new tools or methods.
• Switching tools in the middle of a project.
• Lack of automated source-code control.

Human Computer Interaction

Study about the interaction between human and computer

NIELSEN'S TEN USABILITY HEURISTICS

• Visibility of system status(Feedback) :The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
• Match between system and the real world (METAPHOR):The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than  system oriented terms.
• User control and freedom (NAVIGATION): Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Supports undo and redo and a clear way to navigate.
  
• Consistency and standards (CONSISTENCY):Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions
• Error prevention (PREVENTION):Even better than good error messages is a careful design, which prevents a problem from occurring in the first place
• Recognition rather than recall (MEMORY):Minimize the user’s memory load. Make objects, actions, and options visible.
• Flexibility and efficiency of use (EFFICIENCY):Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
• Aesthetic and minimalist design(DESIGN):Dialogues should not contain information, which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
• Help users recognize, diagnose, and recover from errors (RECOVERY):Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
• Help and documentation (Help):Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and
  not be too large.

Introduction to Rapid Application Development

the ideas of prototyping and iterative development into a methodology called RAD that focused on developing systems in a short time-frame with small teams of highly qualified, motivated and experienced staff.

Advantages of RAD methodology 

• increased speed:-the goal of delivering applications quickly is addressed through the use of CASE tools which focus on converting requirements to code as quickly as possible
• increased quality:- the quality is defined as both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance coasts
• early visibility;- because of prototyping
• productivity of developers will be increase

Disadvantages of RAD

• Reduced scalability:- the delivered solution may lack the scalability of a solution that was designed as a full application from the start
• Reduced features:- due to the time boxing , where features are pushed off to later versions in favor of delivering an applications in a short time frame
• less efficient

 Core Elements of RAD

• Prototyping:-is a technique it allows to see flaws and so look for ways to improve the system. it serves as a communications vehicle for allowing persons who require the system to review the proposed user interaction with the system.
• Iterative Development:-iterative development means creating increasingly functional versions of a system in short development cycles . the process is repeated until all functionality has been developed.
• Time Boxing:- time boxing is the process of putting off features to future application versions in order to complete the current version in as short amount of time as possible.
• Parallel Development :- the System is split into subsystems that can be developed and tested autonomously by multiple SWAT(Skilled workers with Advanced Tools) teams operating in parallel.   
• Team Members:- The RAD methodology recommends the use of small teams consists of experienced, versatile and motivated members that are able to perform  multiple roles.
• Management Approach:- in Addition to enforcing a strict timeline, management must focus on team member selection , team motivation and on clearing bureaucratic or political obstacles
• RAD tools:- RAD focus of the latest tools is as important today as it was when the methodology was initially created. 

Simple Culculater in java Applet

 java is an platform independent language so we can show it's results in any other platforms here we are going see how to display java calculator in a applet form



 /////////////////////////////////CalculatorPanal.java

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class CalculatorPanal extends JApplet implements ActionListerner
{
    public CalculatorPanal()
    {
    setLayout(new BorderLayout());
    display =new JtextField("0");
    display.setEdittable(false);
    disply.setBackground(color.white);
   
    JPanal p=new JPanal();
    p.setLayout(new GridLayout(4,4);
    String buttons="789/456*123-0=+";
   
    for(int i=0;i<buttons.length();i++)
    addButtons(p,buttons.substring(i,i+1);
    add(p,"center");
    }
   
    private void addButton(Container c,String s)
    {
        JButton b=new JBotton(s);
        c.add(b);
        b.addActionListerner(this);
    }
   
        public void actionPerformed(ActionEvent ae)
        {
            String s=new ae.getActionCommand();
            if('0'<=s.charAt(0)&&s.charat(0)<='9'||s.equals(".")
            {
                if(start) display.setText(s);
                else display.setText(display.getText()+s);
                start=false;
            }
           
            else
            {
            if(start)
            {
            if(s.equals("="))
            {
                display.setText(s);
                start=false;
            }
            else
             op=s;
             }
             else
             {
                double x=Double.parseDouble(display.getText());
                calculator(x);
                op=s;
                start=true;
                    }
                    }
                    }
            public void Calculator(double n)
            {
                if(op.equals("+") arg += n;
                else if(op.equals("-")) arg -+n;
                else if(op.equals("*")) arg *=n;
                else if(op.equals("/")) arg /=n;
                else if(op.equals("=")) arg =n;
                display.setText(""+arg);
            }
           
            private JTextField display;
            private double arg=0;
            private String op="=";
            private boolean start=true;
    }


//////////////////////////////////////////////////////CalculatorApplet.java
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class CalculatorApplet extends JApplet
{
    public void init()
    {
    Container ContentPane = getContentPane();
    ContentPane.add(new CalculatorPanel());
    }
    }
////////////////////////////////////////////////////////Calculator.html



<head><title>calculator</title>
</head>
<body>
<APPLET code="CalculatorApplet.class" width="300" height="300">
</applet>
</body>

Login and Session Control in PHP

Let's see how to manage the Session in Web pages before that that we need to know what is the the Session and why it's need to web pages .Session mean we temporarily save or pass data to verify or to do some other actions  .Session will help to authenticate whether the request to access some other pages come from from authenticated user or else coming from other illegal access

<title>Login Page</title>

<Head><center>Login</center>

<script language="javascript">

    function validate(form)

    {

        var uname=form.uname.value;

        var pword=form.pword.value;

        if(uname==""||pword="")

        {

            alert("please fill all ");

            return false;

        }

        else

        {

            return true;

        }

    }

</script>

</head>

<div>

<body>

<form name="login" Method="POST" OnSubmit="return validate(login)" 

      action="check.php">

<center><table border="1">

<tr><td >Username</td><td><input type="text" name="uname"></td></tr>

<tr><td>PassWord</td><td><input type="text" name="Pword"></td></tr>

<tr><td></td> <td align="right"><input type="submit" value="submit"></td></tr>

</table></center>

</form>

</div>

</body>



/////////////////////////////////////////////check.php



    $uname=$_POST['uname'];

    $pword=$_POST['Pword'];



    $db=mysql_connect('localhost','root','') 

          or die('database connection is error');
    mysql_select_db('sms',$db);
    $sql="select * from usercredentials where Username='$uname'";
    $result1=mysql_query($sql);
    $row=mysql_fetch_array($result1);



    if($pword==$row['Password']&&$row['Privilege']=='admin')

        {
            session_start();
            $_SESSION['uname']=$uname;
            header("location:admin.php");
        }
    else if($pword==$row['Password']&&$row['Privilege']=="student")

        {
            session_start();
            $_SESSION['uname']=$uname;
            header("location:student.php");
        }

    else
        {
            header("location:index.html");
        }
    ?> 

////////////////////////////////////////////////Logout.php

 <?php

    session_start();

    if(isset($_SESSION['uname']))

            {
                session_destroy();
                header("location:index.html");
            }

    else
            {
            header("location:index.html");
            }

?>

Google AdMob Mobile application Student Challenge

Now Going on carry up to Register

In general, ad placement should work with the flow of your app. Banners can be placed at the bottom of a screen containing another view, as elements placed in a ListView (as long as you don't show more than one banner on screen at once!) or other places that work with the current layout of the screen.

On the other hand, interstitials should be placed at a natural break in your flow from screen to screen - for example, in between game levels. You can see more examples of ad integration in our Ad Catalog app.

Event-based Action

If you want to track the different lifecycle events of an AdView object, you can use an AdListener. This allows you to not only track, but also take action in onAdOpened(), onAdClosed() and other methods. You can see an example of an AdListener in the Ad Catalog app, and the basic AdListener behavior in this sample app.

Flair

Another fun thing to do is create Custom Events, which allow you to serve your own ads in the ad space. For example, if you know your user's birthday, you could deliver a Happy Birthday message instead of an ad on that day. Custom Events give you a lot of flexibility with your ad space, and we're excited to see how you use them.

For additional controls, such as location and ad color, check out our docs. And if you have any SDK-related questions, you can ask other AdMob developers (including me!) for help on our forum.

Remember, using AdMob is a requirement to submit your app for the student challenge. We're looking forward to your submissions and hope to see some innovative uses of the AdMob SDK!

Key Dates:

Student Registration: 6 November 2013 – 31 March 2014

Competition Window: 6 November 2013 – 15 April 2014

Deadline for submitting your app: 31 March 2014

Deadline for Submitting Business Reports: 15 April 2014

Finalists Announcement: 15 May 2014

Global Winner Announcement: 28 May 2014

By Google 

Steps in Software Project Proposal

Software engineering proposal is a document that a software developer submits to a business customer for acceptance. The proposal describes the problem to be solved and explains the resulting benefits to the customer.

What is Important in a Software Proposal

The key for a great proposal is to invent a great idea.
There is no “official template” for writing software proposals.
To sum up: Content is the key. Form is irrelevant.
Keep in mind that this is a proposal only, so you do not know that it will be accepted as such. Therefore, you do not want to waste time on formalities by following some formal descriptions/formats/templates.
The key is to diagnose the problem and propose a treatment, so to convince the customer to accept your proposal.
The customer wants to know first that you know what you are proposing to do.
They are not interested in idiosyncrasies of software engineering or programming. They assume you know that.
Only if you receive the customer’s approval, will come the issue of knowing how to do it.
The most important thing about a software engineering proposal is that the proposal is about the problem domain, not about programming. The proposal should clearly describe the motivation for the proposed work and the proposed solution along with its expected business value. The proposal should not contain any technical jargon. There are three key components of a software engineering proposal:
DIAGNOSE PROBLEM   ==>   PRESCRIBE TREATMENT   ==>   DESCRIBE PLAN OF WORK

How To Write a Software Engineering Proposal

To write a software engineering proposal, follow these steps:

1. Problem diagnosis: describe the problem domain, describe clearly what kind of issues exist in the current practice that you would like to address.
   Be as specific as you can and provide as many details and examples as possible.
   Describe the problem domain and the problem that you’re planning to solve. People usually make a mistake of describing at a very high level the problem, too generic, and then make a huge leap and dive deep into the tiny detail of their own solution. You must make effort to bridge this gap incrementally. Start with a brief description of high-level context (few sentences or a paragraph), then describe some specific issues that you’re interested in, then provide more specific details about the sub-issues that your work will tackle.
   The best approach is to observe personally the current practice, so that you know what you are talking about. Another useful approach is to interview “domain experts,” people who are working in your target domain and who will be your potential customers. Expert opinion carries greater weight/credibility to your statements and analyses than a naive guess.
   Think of yourself as a journalist, interviewing your potential users and documenting their opinion about current problems they are facing and suggestions on how to address those problems.


2. Proposed treatment: describe how you propose to address the diagnosed problems.
   What specific interventions will you introduce?
   What kind of metrics will you use to evaluate your success in solving the targeted problems?
   How will you know that you achieved your objective?
   Discuss the business value of your proposed solution. What will your customer and users gain from your proposed system that they are lacking now?
   Be as specific as possible in describing the envisioned benefits of your proposed solution. Provide example scenarios of how your proposed system will be used and explain how this solution is better than the current practice.


3. Plan of work: make a convincing case that you know how to achieve the proposed goal. Step-by-step, go in details about what needs to be accomplished, how long it will take, and how it relates to other parts (independent vs. builds upon another part). You cannot know all the details yet, because you haven’t even started, but your plan should outline the main steps so that it is clear that you have a plan. Do not just copy a generic plan from a textbook, because that looks lame.
   Describe your team. What are the strengths and expertise of each team member? Explain why your team size is adequate to tackle the problem, and why the problem size requires your team and not fewer people.
   Keep in mind that this is only an initial plan so that you can give your customer a preliminary estimate of costs and expected completion date. You will need to adjust both of these estimates as you progress, but hopefully not by much.
   State how you will know that you succeeded. How will you measure the success of your system in addressing the customer’s problem that you diagnosed?

Your proposal must be written in lay language, plain English, and you should avoid any engineering terminology (unless your problem domain is an engineering process, i.e., you will develop software to improve an engineering process).
The proposal should accurately describe the user experience, though in lay language rather than using software engineering jargon. The proposal is about the user experience of the proposed system, so this must be as accurate as possible. Otherwise, the decision to accept or reject the proposal will be based on inadequate information. On the other hand, the proposal should avoid discussing the implementation details of the system (how it will be done). It is useful, though, to include what is necessary to accomplish the proposed goal, such as access to certain data (e.g., financial reports, traffic reports, etc., depending on the problem domain), other resources (e.g., sensors, devices, equipment), or expertise (e.g., statistician, security expert). It helps to know whether such resources are available and at what cost.

Why Writing a Software Proposal is Difficult

It is not that writing itself is difficult. What is difficult is learning about your problem domain, how things are done now, how your proposed system will change that. Even if you’re familiar with the domain, it takes time to think new solutions. For example, you may be using a parking garage every day, or even working as a garage operator, but it takes a great deal of time to figure out how to propose a smart parking system.
One may argue that it is to be expected at an initial stage that your proposal will be sketchy on details. Writing a detailed project proposal requires time.

That is why you should avoid wasting time on formalities and focus on what matters. Which is, diagnosing the problem and proposing a treatment. But you cannot diagnose a problem unless you have a deep understanding of your problem domain. You cannot tell your customer how you will improve their work unless you know very well how they are doing their work now!
This is where the problem arises. You may be excited about writing new programs, but you are not excited about learning biology or finance or restaurant functioning. But you cannot diagnose a problem and propose a treatment unless you know your problem domain. You must know how your customer does their business now and how your proposed system will affect your customer’s work. It is important that you are excited about developing something you feel is valuable and important.
A key quality of a great software engineer is that he or she is willing (scratch that, excited) to learn new problem domains.
A great software engineer will learn medicine if he or she is to develop a medical software system; he or she will learn sociology if he or she is to develop a social networking system (popup quiz: what’s Dunbar's numberand why Path limits your social network to 150 friends?); the engineer will go observe how restaurant personnel do their work if he or she is to develop a software system to help run a restaurant; etc.

Software Project Must Include Programming

When deciding about the project, the most important thing to keep in mind is that the software product you will develop should require lot of programming. This is a design rather than a programming course. However, in order to learn good design, the process must include actual implementation of the design. Therefore, the project must include programming.
For example, creating a data-bank and processing this data is a programming task. If your system just allows the user to set or modify values of different database records, that is not data processing. Examples of programming (data processing) include, data-bank re-organization, keyword-based search and retrieval, filtering and summarization of the data-bank, selecting a small group of users for notification, etc. However, just saying: The system will provide search facilities, may mean that you are using SQL database calls and doing no programming at all. And, programming is done in a programming language, such as C, C++, Java, or C#.
Note: Designing web pages passive web pages which contain only HTML is not programming.Therefore, your project can include web page design, but that is not enough.
On the other hand, designing active webpages using AJAX, Flash, etc., is programming and is perfectly acceptable for the class project.
Focus more on automatic data processing: not what user can manually do, but what system does automatically to save the user’s effort. For example, suppose you are designing a system for online purchasing of airline tickets. You could incorporate the following data processing features:

• When user queries for the available flights, sort the results by price or some other attribute before displaying them;
• Allow pending reservation requests for a price below a certain threshold, or in case another passenger cancels a completely booked flight;
• Design a feature for marketing to the users based on their travel history;
• If the flight gets delayed or cancelled, the system should automatically send notification to the passengers;

Strive to reduce the user’s manual interaction with the system and increase the system “smarts”! Let the system do the work for the user! Nobody is impressed with a system where the user has to invest hard work to get even simple tasks accomplished. Make every effort to reduce the number of clicks and keystrokes necessary for task completion.
Keep in mind that the key purpose of this course is that you learn how to do modular design of software and how to document the design using symbolic representations, i.e., UML diagrams. Thus, you should avoid flashy user interfaces and proprietary software. These will definitely not contribute positively to your grade, and may have negative effects. Limit your software to the tools commonly and freely available on the Web.

Choice of the Topic

The proposed topic can be almost anything; however, it is advisable to come up with something novel and innovative to keep you interested in its realization, and because innovativeness tends to make impression on the reviewers.
You could get an idea for interesting service(s) by exploring these web-sites:

• https://joindiaspora.com/   |   Installing and Running Diaspora
• http://developers.facebook.com/

Your project may or may not be Web based, but it must include programming.The process of casting out the right-size project for a given period of performance can be very frustrating. You cannot ever know what you’ll encounter while working on it. I believe that it’s better to start more ambitious and later scale down, if necessary. Start with an initial idea of desirable services and discuss as much details as possible with your partners to figure out whether or not you as a team can develop it in the given time frame. Of course, you’ll have chance to adjust your goals during the semester, as you learn more details about your target product.

3.   Working from an Existing Proposal

If you like one of the project ideas described here, your main task for the proposal is to describe how different will be your project from the projects that were done by past students in this course.

Borrowing From Past Projects

You may borrow ideas and implementation from past projects as much as you like. It is fine that you borrow 100% from a past project, take everything and then build on top of it! In fact, this approach would be preferred instead of seeing you reinvent the wheel.
However, what is important is that you contribute new value! For example, you can implement better some features/functions from an existing project; your implementation may be faster, or easier to use. Or, you may add novel features / extensions to an existing project.

4.   Proposal Format, Submission, and Feedback

Proposal Format

Each proposal should contain the following:

1. Project title, Group number
2. URL of your project’s web-site (for free web hosting, see here)
3. Team profile:
   1. Individual qualifications and strengths (such as: programming, design, presentation, documentation, management and organization)
      Note: It is expected that every team member shall be involved in all project activities; this only indicates individual strengths, not their sole responsibilities
   2. Name of the elected team leader, if any (having a team leader is optional)
      The team leader should act as facilitator, to organize group meetings and generally keep track of project activities
4. Proposed project description:
   Regardless of whether you are proposing a completely new project or building on one of the example software projects, your project description must provide detailed explanation of your proposed project,
   You may also describe typical customers for your proposed system and mention if you already have a customer or someone interested in your proposed project.
5. Product ownership:
   Split your team into pairs of students (a team of 6 students will have 3 pairs), and each pair should list what specifically they will contribute to the end product:
   1. Functionality: which functions, if any, you will contribute, such as customer registration, data capture and storage, data processing to extract statistical parameters, etc.
   2. Qualitative property, if any, that you will contribute, such as tune up the system performance to achieve response time under x seconds, or develop and evaluate an easy-to-use user interface for this-and-this specific functional feature, or ensure confidentiatlity of a specific set of data, etc.
   Product ownership is critical to demonstrate that each team member will play a clearly defined role in the proposed project.

Proposals that are missing any of the above sections will be returned without review.

Proposal Submission

Because the project is a team work, each team submits a single document for the entire team. Email a PDF document of your proposal to both the instructor and the TA on or before the due date given here.
Submission deadline: 5:00 p.m. on the due date.
Here is a PDF writer you can use from Windows. Macs automatically convert postscript to PDF by clicking on the file icon. There are UNIX utilities that convert postscript to PDF for Linux users; make sure you include all fonts in the created PDF.
In case of novel project proposals (not based on the projects described in the class lecture notes), email immediately the breakdown of the individual contributions to the proposal.

Feedback

We will provide written feedback only for novel project proposals via email in case we feel the proposal should be revised. No feedback will be provided for proposals based on the projects described in the class lecture notes. The only two reasons for revision could be:

• Project does not appear to include programming
• Project does not appear to be sufficiently ambitious

The students are encouraged to be ambitious in the first iteration of the project. You will have chance to revise your project objectives at the end of the first iteration,