Language Translation Chat Application

Language Translation Chat Application 1
LANGUAGE TRANSLATION CHAT APPLICATION
By
DALEEL MUHAMMAD ASLAM
2015-GCUF-14869
&
DAWOOD ANWAR
2015-GCUF-14804
The project is submitted for the partial fulfillment of
the requirement of the degree of
BACHELOR OF SCIENCE
IN
SOFTWARE ENGINEERING
DEPARTMENT OF SOFTWARE ENGINEERING
GOVERNMENT COLLEGE UNIVERSITY FAISLABAD
Department of Software Engineering

JUNE 2018
DECLARATION
We carried the work mentioned in this document to accomplish the project under the supervision of
Dr. Khurram Zeeshan Haider Department of Software Engineering, Government College University
Faisalabad.
We hereby declare that the “LANGUAGE TRANSLATION CHAT APPLICATION” and all the
contents of this project are the outputs of our efforts and research. We further declare that the all the
work which we mentioned in this document has not been submitted for the award of any other
degree or diploma. The university may take action if the information provided in this document is
inaccurate at any stage.
Signature of the student: Signature of the student:

STATEMENT OF SUBMISSION
This is to certify that Daleel Muhammad Aslam Roll # 14869 and Muhammad
Dawood Anwar Roll # 14804 have successfully completed the final year project
named as “LANGUAGE TRANSLATION CHAT APPLICATION” at the department of
Software Engineering, Government College University Faisalabad to fulfill the
partial requirements of the degree of BS (Software Engineering).
Project Supervisor
Project Coordinator
Head
of Department
Software Engineering

Government College University Faisalabad.

Chapter 1: Software Project Management Plan (SPMP)
1. SCOPE AND REFERENCES

1.1. Scope
1.2. References
2. DEFINITIONS
3. SOFTWARE PROJECT MANAGEMENT PLANS
3.1. Project Overview
3.2. Project Deliverables
3.3. Evolution of SPMP
3.4. Reference Materials
3.5. Definition and Acronyms
4. PROJECT ORGANIZATION
4.1. Process Model
4.2. Organizational Structure
4.3. Organizational Boundaries and Interfaces
4.4. Project Responsibilities
5. MANAGERIAL PROCESS
5.1. Management Objectives and Priorities
5.2. Assumptions, Dependencies, and constraints
5.3. Risk Management
5.4. Monitoring and Controlling Mechanisms
5.5. Staffing Plan
6. TECHNICAL PROCESS
6.1. Methods, Tools, and Techniques
6.2. Software Documentation
6.3. Project Support Functions
7. WORK PACKAGES, SCHEDULE, AND BUDGET
7.1. Work Packages
7.2. Dependencies
7.3. Resource Requirements
7.4. Budget and Resource Allocation
7.5. Schedule
8. ADDITIONAL MATERIAL
Chapter 2: Software Quality Assurance Plan (SQAP)
1. OVERVIEW
1.1. Scope
2. REFERENCES

3. DEFINITIONS AND ACRONYMS
3.1. Definitions
3.2. Acronyms
4. SOFTWARE QUALITY ASSURANCE PLAN
4.1. Purpose
4.2. Reference documents
4.3. Management
4.4. Documentation
4.5. Standards, practices, conventions, and metrics
4.6. Review and audits
4.7. Test
4.8. Problem reporting and corrective action
4.9. Tools, techniques, and methodologies
4.10. Code control
4.11. Media control
4.12. Supplies control
4.13. Records collection, maintenance, and retention
4.14. Training
4.15. Risk management
Chapter 3: Software Requirements Specifications (SRS)
1. INTRODUCTION
1.1. Product Overview
2. SPECIFIC REQUIREMENTS

2.1. External Interface Requirements
2.2. User Interfaces
2.3. Hardware Interfaces
2.4. Software Interfaces
2.5. Communications Protocols
3. Software Product Features
4. Software System Attributes
4.1. Reliability
4.2. Availability
4.3. Security
4.4. Maintainability
4.5. Portability
4.6. Performance
5. 2.4 Database Requirements
Chapter 4: Software Design Description (SDD)
1. INTRODUCTION
1.1. Design Overview
1.2. Requirements Traceability Matrix
2. SYSTEM ARCHITECTURAL DESIGN
2.1. Chosen System Architecture
2.2. Discussion of Alternative Designs
2.3. System Interface Description

3. DETAILED DESCRIPTION OF COMPONENTS
3.1. Component-n
4. USER INTERFACE DESIGN
4.1. Description of the User Interface
4.2. Screen Images
4.3. Objects and Actions
Chapter 5: Software Test Documentation (STD)
1. INTRODUCTION
1.1. System Overview
1.2. Test Approach
2. TEST PLAN
2.1. Features to be Tested
2.2. Features not to be Tested
2.3. Testing Tools and Environment
3. TEST CASES
3.1. n Case-n
3.2. n.1 Purpose
3.3. n.2 Inputs
3.4. n.3 Expected Outputs & Pass/Fail criteria
3.5. n.4 Test Procedure
4. ADDITIONAL MATERIAL (including appendix A)
5. APPENDIX A. TEST LOGS
5.1. A.n Log for test n

5.2. A.n.1 Test Results
5.3. A.n.2 Incident Report
Chapter 6: Working Software
Of course a working Software is mandatory to pass the course
Chapter 7: User Manual
1. GENERAL INFORMATION
2. SYSTEM SUMMARY
3. GETTING STARTED
4. USING THE SYSTEM
5. REPORTING
8 Individual Reflections on Degree Project (Post mortem Report)
1. Introduction
2. My roles and Tasks
3. What worked well?
4. What didn’t work well
5. Team Effectiveness
6. Lesson learned
7. Challenges
8. Conclusion

CHAPTER # 1
SOFTWARE PROJECT MANAGEMENT PLAN

(SPMP)

1. Scope and References
1.1 Project Scope

Language Translation Chat Application is an Android platform based App, which will be used as an
instant messaging app with Real-Time translation. LTCA will automatically translate all incoming
and outgoing messages to and from one language to another desired language. Eliminates the
Language barrier and helps you to stay connected to people with diverse languages across the World.
LTCA can be used for International business purposes, International students, Social chat app and
travelers.
1.2 References
2 DEFINITIONS
3 SOFTWARE PROJECT MANAGEMENT PLANS
3.1 Project Overview
Language Translation Chat Application is an application developed in Android Studio which

features the instant messaging with real-time translation. You can chat with different people
having preference of different languages, Translation made possible with the help of integrating
(Google Translator), after Signing up and Log in with your (Gmail) app moves to main
Dashboard where all chats are placed. Selecting desired chat, we can set Preferred language for
each chat for both ends (Receiver and sender) in chat bubble window. We can also set user
Profile details.
3.2 Project Deliverables
Nine project deliverables must be delivered on time with working software:
Table 1 Project Deliverables
Document Description Activities

Deliverables
 System Requirement
Software project Description of the software Analysis
management plan project and associated  Software
(SPMP) milestones. Requirement
Analysis.
Description of the software  Product Quality

Software Quality engineering processes and
Assurance Plan methods, which are used to  Process Quality
ensure the quality.

Software Description of the expected

Requirements features, Attributes,  Process
Specification interfaces and constraints. Implementation
Software Design It will describe in detail that  System

Description how the software will fulfill Architectural design
the user requirements.  Software Detailed
design
Software Test Description of all the tools  Software Validation

Documentation and techniques that are Test
useful to verify and validate  Software
the System. Qualification Test
Description for the end

User Manual user, which describe how to  User Manual
use the Software/system.
This is the final working

Working Software software, which will fulfill  Working Software
the user requirements.
Post Mortem Report Description of individual  Post Mortem Report

reflections on project.
3.3 Evolution of SPMP
Any required changes in the software project management plan will be

monitored and send to team.
3.4 Reference Materials
3.5 Definition and Acronyms
4 PROJECT ORGANIZATION
The software project management plan will identify the processes or models
that are used to develop the system and identify the ways, which are followed
to organize the project. It will identify the external entities and their way to

interact with the system as well as internal project structure and roles and
responsibilities for the project.
4.1 Process Model
To develop this system, we choose the waterfall model due to the following
reasons:
 Requirements are clear at the start of project so there are less likely
chances to change the requirements.
 The stages mentioned and used in the model are clear to understand.
 Phases are completed and it is an ongoing process.
 There are a little bit chances to update the system.
 It is an easy to manage.
Requirements
Product requirements document
Design Software Architecture
Implementation
Software
Verification
Maintenance
Figure 1 Waterfall Model
Table 2 Different phases of Project
Phase Activity Deliverable
Requirements Specify what the software

Specification will do and how it will be SRS & Prototype
expected to do.
Create the design for the

Design project that will fulfill the Software Design Document
user requirements.
Implementation Implement all the user

requirements to get the Working Software
final working software.
Testing Check whether the Software test plan

working software is And test report.
fulfilling the user
requirements or not.
Maintenance In this phase all the Maintain the system.

functions relating to
maintain the system are
performed.
4.2 Organizational Structure
There are only two team members, one is team head and other is a project
manager. The hierarchy of stakeholders to develop the system is as follows.
External Stakeholders:

The Language Translation Chat Application” is useful for International

businessmen, Students and foreign tourists from all over the world as well as
everyone around the globe to stay connected beyond the language barriers.
Internal Stakeholders
This project is developed by only two team members, which perform all the
duties including Leadership, Planning, Quality Assurance, Development
processes, Testing processes, Documentation etc.
Team Leader (Daleel M Aslam)
 Motivate the team for the progress of the project.

 Lead the team in obtaining the needed tools and goals.
 Keep track and resolve the team’s issues and risks.
 Manage the configuration management system.
 Help the team in allocating the tasks.
Process Manager (M Dawood Anwar)
 Set up and manage communication between development teams.

 Review and Publish test cases on requirements gathering sessions.
 Keep Track of all the processes necessary to meet the requirements.
Planning Manager (Both Team Members)
 Plan about the project cost as well most suitable process model
 Arrange and attend the meetings for project evaluation on weekly basis.
Development Manager (Both Team Members)
 Manage development team to code and develop the system.

 Ensure that the developers follow the coding standards.
Document Writer (Both Team Members)
 Ensure to follow the IEEE standards in documentation.

 Documentation should be project specific.

 All the related documents must be prepared and delivered on time.
Developers
 Adopt the coding standards.

 Responsible for developing working software.
Tester
 Remove all the bugs and conduct white & black box testing.
 Prepare test Report
Team Leader
Development Support Manager

Planning Process
Manager Manager Manager
Document Writer
Team Developer
Developer Tester
Figure 2 Organizational Structure
4.3 Organizational Boundaries and Interfaces
4.4 Project Responsibilities

Two types of roles and responsibilities are shared among the members of the
team.
 Process roles are allocated to each of the team member.
 Development roles are allocated to each of the team member
Head
 Motivate the team members to perform their tasks.

 Help the team in allocating the tasks and resolving the issues.
 Create and maintain project SRS.
Team Leader
 Lead the team in producing the high-level design.

 Lead the team in producing the design specification.
 Lead the team in producing the development strategy.
 Lead the development of project SRS.
 Lead the team in developing the Build, integration and system test
plans.
 Lead the team in developing the test materials and running the tests.
 Lead the team in producing the product user documentation.

Support Manager
 Manage the configuration Management system.

 Maintain the team issues and risk tracking system.
 Lead the team in determining its support needs.
5 MANAGERIAL PROCESS
5.1 Management Objectives & Priorities
 The main objective of the management is to assure the proper delivery

of working software with all documents.
 Another objective of the management is to time-to-time delivery of all
deliverables.
 Management assigned priorities based on timely delivery of
deliverables.
 A good management always try to save the time as well as the cost of
the project.
 A good management always try to assure the possibility of success.
 Management always monitored and appreciated the efforts of team
members.
 Working software should have all the features mentioned in the SRS.
5.1 Assumptions, Dependencies, and constraints
There are several assumptions and constraints, which are important for
the project and for the team leader
 The team will work together to accomplish the task.
 The team will respond to all the questions asked by the staff on timely
manner.

 The team have enough experience as an individual and as a whole to

complete the project.
 Due to the nature of the project and its dependability on already existing
solutions and technologies third party software’s and already existing
solutions will be used in the project as needed.
 Additional financial resources are not available for the project.
 Dependencies are the relationships among tasks which determine the order in which
activities need to be performed
.
5.2 Risk Management
 The SPMP should specify the risk management plan for identifying,
analyzing and prioritizing project risk factors.
 The SPMP should specify the procedures for contingency planning and
the methods that will be used for tracking risk factors, changes in the
levels of factors and responses to those changes.
5.3 Monitoring and controlling plan
 Meetings are held to monitor the project development process.

 Documents repository was shared to among the team members.
 The team leader would be responsible to all kind of changes in the
documents.
 Goals are adjusted on the weekly basis by the suggestions of team
members.
 Documents are must be adjusted on the weekly basis.
 Work would be divided among the team members to get focus on the
work.
5.4 staffing plan

 For this project, only two members perform all kind of duties.
 Both team members are responsible for the documentation of the SRS,
SPMP, and SDD etc.
 Both team members are responsible to assure the delivery of working
software as well proper documentation.
 Both team members are responsible to perform the duties of staff
manager and project manager.
6 TECHNICAL PROCESS
The SPMP also specify the technical tools, technologies, methodologies and
models that are used / choose to develop the final product. Technical process
also specifies the project infrastructure and product acceptance plan.
6.1 Methods, Tools, and Techniques
During the development, process following tools and techniques are adopted.
 Waterfall model is used to develop the product.

 Cocomo model is used to calculate the cost of the project.
 Android studio 3.4.2 is used as a development environment.
 Word 2010 is used for the documentation of the project.
 Google Translator is used to translate the messages.
 Android studio APIs are used to connect Node.Js to Java file for instant
chat and translation in App.
 Microsoft project is used to create the SPMP.
 At backend Cloudinary (Database) for profile Image, Mongo db for Media,
Heroku cloud, FireBase cloud, Github.
6.2 Software Documentation

Software project documentation contain all the information about the project
including project startup plan, project schedule, project cost and time
management plan. Project documentation also contain the technical process.
Software documentation preparation is the responsibility of both the team
members.

6.3 Project Support Functions
7 WORK PACKAGES, SCHEDULE, AND BUDGET
7.1 Work Packages
As this project is built by only two persons under the supervision of university
staff. We conduct the survey of some nearby software houses and have an idea
that normally software houses charge almost 25 thousand for 10 hours and our
team has been work on this project for 5 hours per day so we calculate the cost
of the project, which is 60,000 only.
7.2 Dependencies
 The system cannot be functional to give its output to user until it will not
get its optimal environment of working.
 The App cannot translate language until the language preferences are
set
 To install the app in the mobile phone and to run it every time, internet
access is compulsory.
 To use the app user must have android phone.
7.3 Resource Requirements
7.4 Budget and Resource Allocation
The resources, which are described in the software project management plan,
should be available on time to time during development. All the
resources should be available for both the team members like roaming
facilities, internet access etc. The project must be deliver on the time, which is

prescribed in the document so that the budget and resources would not over
run.
7.5 Schedule
Chapter # 02
SOFTWARE QUALITY ASSURANCE PLAN
1 Project Overview
Language Translation Chat Application is an application developed in Android Studio which

features the instant messaging with real-time translation. You can chat with different people
having preference of different languages, Translation made possible with the help of integrating
(Google Translator), after Signing up and Log in with your (Gmail) app moves to main
Dashboard where all chats are placed. Selecting desired chat, we can set Preferred language for
each chat for both ends (Receiver and sender) in chat bubble window. We can also set user
Profile details.
1.1 Scope
Language Translation Chat Application is an Android platform based App, which will be used
as an instant messaging app with Real-Time translation. LTCA will automatically translate all

incoming and outgoing messages to and from one language to another desired language. Eliminates
the Language barrier and helps you to stay connected to people with diverse languages across the
World. LTCA can be used for International business purposes, International students, Social chat app
and travelers.
2 References
Google Translator API
https://translate.google.com/
Work Breakdown Structure
https://en.wikipedia.org/wiki/Waterfall_model
Android Studio Logo
https://www.google.com.pk/search?q=android+studio+logo
Adobe Photoshop
https://www.google.com.pk/search?q=adobe+photoshop+logo
MS Project Logo
https://www.google.com.pk/search?q=adobe+photoshop+logo
3 Definition and Acronyms

SQAP – Software Quality Assurance Plan.
SPMP – Software Project Management Plan.
GLT – Google Language Translator.
API – Application Program Interface.
IEEE – Institute of Electrical and Electronics Engineers.
XML – Extensible Markup language.
SPMP – Software Project Management Plan.
APK – Android Package Kit.
KLOC – Kilo Line of code.
WBS – Work Breakdown Structure.
4 Software Quality Assurance Plan

4.1 Purpose

The main purpose of the software quality assurance plan is to establish the
pattern for all the actions that confirm that the working software is meet all the
technical requirements. Software quality assurance plan also specify the
processes, which are followed to develop the system.
4.2 Reference Documents

This section lists the documents referenced in this SQA Plan.
a. IEEE/EIA Standard 12207 Series - Standard for Information Technology – Software life cycle
processes, March 1998.
b. IEEE-Std-730-1998, IEEE Standard for Software Quality Assurance Plans, June 1998.
c. IEEE-Std-730.1-1995, IEEE Guide for Software Quality Assurance Planning, December 1995.
d. Software Engineering Process Policy, SPAWARSYSCEN SAN DIEGO INST 5234.1, July 2000.
e. Software Quality Assurance Process, PR-SQA-02.
f. Software Quality Assurance Plan Template, TM-SQA-01.
g. MIL-STD-1521, Technical Reviews and Audits for Systems, Equipment’s, and Computer Software.
h. Peer Review Process, PR-PR-02.
i. IEEE Std 1045-1992, IEEE Standard for Software Productivity Metrics, September 1992.
j. IEEE Std 1061-1992, IEEE Standard for a Software Quality Metrics Methodology, December 1992.
k. IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software, June
1988.
l. Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce
Reliable Software, September 1988.
4.3 Management
As this project is our final year project so all the duties relating to management
would be perform by two team members. The duties associated with this
project include, analyze the problem, create the design, implement the design,
create the chat box and change the language to desired language using Google
Translator API.
4.4 Documentation
Software project documentation contain all the information about the project
including project startup plan, project schedule, project cost and time
management plan. Project documentation also contain the technical process.
Software documentation preparation is the responsibility of both the team
members.
4.5 Standards, practices, conventions and metrics

IEEE standards will be followed for documents when appropriate throughout
this project. Source code and comments will follow the guidelines in the C#

coding standards and style guide. COCOMO will be used as a cost estimate
metric.
4.6 Review and audits

4.6.1 SQA Auditing Program
SQA Auditing program will specify that the working software have all the
requirements that are desired by the user. Auditor examine the both internal
and external deliverables of the project. Normally two types of auditing are
performed.
4.6.2 Scheduled Audits

Software Quality Assurance Plan generate and maintain the Schedule for
auditing. At each successful phase, auditing is done and results are discussed
with the person, which is most responsible of the development team.
4.6.3Unscheduled Audits
The SQA team do random or unannounced auditing to check the corrective
actions agreed to during the Scheduled audits. If any kind of problem is found,
then they communicate with the development team.
4.6.4Auditing results
The SQA generate auditing results and recommend some action to bring the
attention of the senior developer for producing the desired working software.
Corrective actions will be recommending and reviewed for the individual and
SPM.
4.6.5Project Reviews
The Project reviews are conducted to ensure that the code has been tested and
now it meets the module specification. The project review may be differing in
nature it may be Formal, Informal, or Quality Review.
4.6.6Formal Review
The SQA team review the final documentation before its submission date to
ensure that the system mentioned in the documentation would be available on
the time or not. SQA team also check whether the system have the
components as described in the documentation
4.6.7Informal Review
The SQA team review informally to check that whether the process is verifiable
which is used to identify the all action items generated during this review
process. The SQA team will audit this process to ensure that the all actions
have been implemented, which are compulsory to develop the product.
4.6.8Quality Review
Before the final release of the product SQA team, conduct the quality review to
check the following things.

 The code of the App is tested and meet the specifications, which are
compulsory for the project.
 In the documentation, all the changes which may be need to do in the
application
 The basic tests for the validation have been run.
 Tools and techniques, which are used to check the validity of the system,
are identified and controlled.
4.7 Test
Testing is done on various levels like software testing, Unit testing, Integration
testing, System testing, code validity testing to check whether the system
working according the prescribed characteristics and to check the errors or
bugs to make the code errors free.
4.7.1Module Testing
This is the primary level of testing in which each module is tested to check
whether it is working according to desired output. After completing one module
we perform on it module testing to by giving it some arbitrary values to check
whether it is draw the line from the current location to final destination or not.
4.7.2Integration Testing
After testing all the modules, we integrate them and now we perform the
integrating testing in which we check how the modules are work after
connecting with each other and check the interference with each other.
4.7.3System Testing
After completing the integration of different modules, we check the overall
performance of the system. We check the system output by giving it random
locations.in system testing especially operational module is checked.
4.7.4Validation Testing
Validation testing is performed to check the validity of the system outputs; it
means we check the system whether it is giving the output as mentioned in the
documents or not.
4.8 Problem reporting and correction action

4.8.1Problems in code
 Presence of errors.
 Code Standards are not followed.
 Not proper working.

 Lack of functioning.
4.8.2Problems in Documents
 Documents are not relevant.
 Standards by IEEE for documentation are not followed.
 If the documents are incomplete.
4.8.3Problem Reporting Procedure.
The person who find the error would be responsible to remove it at the spot.
During the review if any problem would be find then the SQA team member
would be remove it.
4.8.4Problem Solving Procedure

 The team leader of corresponding team will examine the nature or type
of problem and then suggest the solution of that particular problem to its
team members.
 The leader will check whether the changings in the system solve the
particular problem.
 If the solution for the problem does not find, then the meeting would be
arranging under the supervisions and then any decision would be taken
for the plan.
4.9 Tools, techniques and methodologies

During the development, process following tools and techniques are
adopted.
 Waterfall model is used to develop the product.

 Cocomo model is used to calculate the cost of the project.
 Android studio 3.4.1 is used as a development environment.

 Word 2013 is used for the documentation of the project.

 Google translator API is used for translation.

 MS Project 2007 for project planning.
 My SQL for database server.
4.10 Code control

The access to documents is only provide for the authorized persons
No file is unnecessarily hidden.
Naming conventions are consequently
4.11Media control
Media control includes the items listed below:
Regularly scheduled backup of the media.
Labeled and inventoried media filed in a storage area in accordance with security requirements and in a
controlled environment that prevents degradation or damage to the media.
Adequate protection from unauthorized access
4.12 Supplies control
Prior to any purchase of software to support the development effort, SQA and project
members will define and provide complete requirements to the supplier/vendor. The Software
Tool Evaluation Process will be followed. Part of the evaluation process will require the
supplier or vendor to describe their technical support, handling of user questions and
problems, and software product upgrades.
4.13 Records collection, maintenance and retentions
SQA activities are documented by records and reports that provide a history of product quality
throughout the software life cycle. Measurement data collected will be reviewed for trends and
process improvement. All SQA records will be collected and maintained in the SDL or archival
storage for the life cycle of the product or a minimum of [state number of years].
4.14 Training
TABLE ( SQA TRAINING MATRIX )
TASK SKILL REQUIREMENTS TYPE SOURCE
Code Reviews Source Language, Peer Classroom/ SEPO, Peer Review Process
Reviews OJT and Workshop
Documentation Software Development and Classroom/ SEPO, Peer Review Process

Reviews Documentation standards and OJT and Workshop
guidelines, Peer Reviews
Process Audits Software Development Life Classroom/ MIL-STD-498, IEEE/EIA

Cycle Processes, Audit OJT 12207

techniques
Testing Testing Methodologies OJT
SQA Management Project Management Classroom/ SEPO, Software Project

OJT Management (SPM)
course
Metrics Data Collection and Analysis Classroom/ SEPO, SPM course

OJT
Problem reporting and Configuration Management Classroom/ SEPO, CM Practitioner's

correction action OJT Training
Tools Vendor supplied training Classroom/ Vendor

OJT
Code, Media, and Configuration Management Classroom/ SEPO, CM Practitioner's

Supplier Control OJT Training
Risk Management and Risk Management Process Classroom/ SEPO, SPM course
Analysis OJT
Software Management Software Management Classroom/ SEPO, Software

Process OJT Management for Everyone
(SME) Training, SPM
course
5.1 Risk management
The SPMP should specify the risk management plan for identifying,
analyzing and prioritizing project risk factors.
The SPMP should specify the procedures for contingency planning and
the methods that will be used for tracking risk factors, changes in the
levels of factors and responses to those changes.
Table ( Risk Management)
Risk Possibility Impact Solution

Resources All the important data must be stored

Unavailability Low Medium in external medium like USB or HDD
and stored online.
New Remain up to date with the new

Technology High High technology, online research, self-
learning, reuse components.
Share the knowledge in each meeting;

Team member Medium Medium remain in touch with the team
absence members through mobile phones,
email, Facebook or other social media
sources.
Lack of Staff monitor team members, Provide

Communicatio Medium Medium friendly environment
n
Check the work on weekly basis and

Time Out High High increase the working hours if the work
is not done on the expected time.
Budget Medium High Estimate the cost of the project

increase before starting it; divide the overall
cost to each deliverable.
6 Additional Material

Language Translation Chat Application

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Language Translation Chat Application

Încărcat de

Drepturi de autor:

Formate disponibile

Language Translation Chat Application 1

LANGUAGE TRANSLATION CHAT APPLICATION

DALEEL MUHAMMAD ASLAM

The project is submitted for the partial fulfillment of

the requirement of the degree of

DEPARTMENT OF SOFTWARE ENGINEERING

GOVERNMENT COLLEGE UNIVERSITY FAISLABAD

Department of Software Engineering

Signature of the student: Signature of the student:

Department of Software Engineering

Department of Software Engineering

Department of Software Engineering

Government College University Faisalabad.

1. SCOPE AND REFERENCES

Chapter 2: Software Quality Assurance Plan (SQAP)

Department of Software Engineering

3. DEFINITIONS AND ACRONYMS

4. SOFTWARE QUALITY ASSURANCE PLAN

4.2. Reference documents

4.5. Standards, practices, conventions, and metrics

4.6. Review and audits

4.8. Problem reporting and corrective action

4.9. Tools, techniques, and methodologies

4.10. Code control

4.11. Media control

4.12. Supplies control

4.13. Records collection, maintenance, and retention

4.15. Risk management

Chapter 3: Software Requirements Specifications (SRS)

1.1. Product Overview

Department of Software Engineering

2.1. External Interface Requirements

2.2. User Interfaces

2.3. Hardware Interfaces

2.4. Software Interfaces

2.5. Communications Protocols

3. Software Product Features

4. Software System Attributes

5. 2.4 Database Requirements

Chapter 4: Software Design Description (SDD)

1.1. Design Overview

1.2. Requirements Traceability Matrix

2. SYSTEM ARCHITECTURAL DESIGN

2.1. Chosen System Architecture

2.2. Discussion of Alternative Designs

2.3. System Interface Description

Department of Software Engineering

3. DETAILED DESCRIPTION OF COMPONENTS

4. USER INTERFACE DESIGN

4.1. Description of the User Interface

4.2. Screen Images

4.3. Objects and Actions

Chapter 5: Software Test Documentation (STD)

1.1. System Overview

1.2. Test Approach

2.1. Features to be Tested

2.2. Features not to be Tested

2.3. Testing Tools and Environment

3.2. n.1 Purpose

3.3. n.2 Inputs

3.4. n.3 Expected Outputs & Pass/Fail criteria

3.5. n.4 Test Procedure

4. ADDITIONAL MATERIAL (including appendix A)