Final Year Project Proposal

Code smell detection using JAVA

<Submitted by>

AZHAR ZAFAR
HAMZA REHMAN
MUHAMMAD JAHANGIR
MUHAMMAD USMAN JUNAID

<Supervisor>

ISRAR ALI

<Coordinator>

DR. ASIM ALI RIZVI

 List of Abbreviations and Acronyms:

CSD Code Smell Detector

LM Long Method

CSD Code Smell Detection

LPL Long Parameter List

FE Feature Envy

DC Data Class

QA Quality Assurance

SDLC Software Development Life Cycle

SLR Systematic Literature Review

IDE Integrating Development Environment

Final Year Project Proposal Page 1 of 28

 Abstract:
Code smells are poor implementation choices, thought to make object-oriented
systems hard to maintain. Code smells refer to any symptom in the source code of a
program that possibly indicates a deeper problem, hindering software maintenance
and evolution. Detection of code smells is challenging for developers and their
informal definition leads to the implementation of multiple detection techniques and
tools. Tools for automatic or semi-automatic detection of code smells support
developers in the identification of “smelly” entities. The implementation of detection
techniques by using (Refactoring) allows the tools to highlight the entities that most
likely present code smells.
I will use Code Smell Detection, which will use a scientific approach to identify five of
the 22 code smells. CSD will make refactoring suggestions for all five of these smells.

Flowchart:

Final Year Project Proposal Page 2 of 28

Table of Contents
Section – 1....................................................................................................................................... 4
1.1 Project Identification ........................................................................................................... 4
Section – 2....................................................................................................................................... 8
2.1 Introduction ......................................................................................................................... 8
2.2 Aim and Objectives.............................................................................................................. 9
2.3 Benefits .............................................................................................................................. 9
Section – 3..................................................................................................................................... 10
3.1 Literature Review.............................................................................................................. 10
Section – 4..................................................................................................................................... 14
4.1 Research Approach ........................................................................................................... 14
4.2 Functional and Non-Functional Requirements: ................................................................ 17
4.3 Use Case: .......................................................................................................................... 18
4.4 Use Cases Narrative ................................................................................................................ 18
4.5 Risk Analysis .................................................................................................................... 19
Section – 5..................................................................................................................................... 19
5.1 Resources & Other Requirements ........................................................................................... 19
Bibliography ................................................................................................................................. 21
Annexure–A: Project Schedule / Milestone Chart / Gantt chart .................................................. 23
Annexure–B: Proposed Budget.................................................................................................... 23
Annexure–C: Business Canvas Model: ........................................................................................ 26
Prototype: ...................................................................................................................................... 27

Final Year Project Proposal Page 3 of 28

 Final Year Project Proposal

Section – 1

1.1 Project Identification

Project Title:

Code smell detection by using JAVA

Group Leader (GL):

1. Name: Azhar Zafar

Reg #: 41671
CGPA: 3.2

Mobile # : 03012313588 azhar.41671@iqra.edu.pk

Email:
Signature:

Group Members (GM’s):

2. Name: Hamza Rehman

Reg #: 43714
CGPA: 2.9

Mobile # : 03110233763 hamza.43714@iqra.edu.pk

Email:
Signature:

3. Name: Muhammad Jahangir

Reg #: 43430
CGPA: 3.03

Mobile # : 03151263147 muhammad.43430@iqra.edu.pk

Email:
Signature:

Final Year Project Proposal Page 4 of 28

4. Name: Muhammad Usman Junaid

Reg #: 41574

CGPA: 2.5

Mobile # : 03120298713 Muhammad.41574@iqra.edu.pk

Email:
Signature:

What technology is core to your product?

[ ] 3D/4D Printing [ ] Augmented Reality / Virtual Reality
[ ] Big Data, Artificial Intelligence [ ] Block chains
[ ] Cloud [ ] Neurotic
[ ] Robotics [ ] Shared economy
[ ] The Internet of Things [ ] Wearables, Implantable
[✓] Others (specify): Automated tool for detection of code smells in program code

What is the target market(s) for the products?

[ ] Automotive, aviation, marine [ ] Business, marketing, finance
[ ] Defence, security, safety [✓] Education and training
[ ] Environment, water management [ ] Entertainment, tourism, sport/recreation
[ ] Food, livestock, agribusiness [ ] Healthcare
[ ] Infrastructure, housing & transport [ ] Mining equipment technology & services
[ ] Oil, gas, energy [ ] Textiles, clothing, footwear
[✓] Others (specify): Education purpose, Industrial Business(Software Houses)

Other Organizations Involved in the Project:

Academic Organizations:
# Organization Name Role / Contribution
1. Iqra university Resources and supervision
2.

Final Year Project Proposal Page 5 of 28

Industrial Organizations:
# Organization Name Role / Contribution
1. None None
2.

Funding Organizations:
# Organization Name Role / Contribution
1. None None
2.

Key Words:

Software inspection, Quality assurance, Refactoring, Code smells, Detection tool.

Research and Development Theme:

The complexity of software systems is rapidly increasing, which leads software houses
to anticipate continuous change. Developers spend more than 60% of their time
understanding the code before proceeding with its maintenance, leading to massive
costs.
These expenses can be reduced by detecting and eliminating code smells in the early
stages of development, help for java developer and automated detect smells in code.

Project Status:
[✓] New [ ] Modification to previous Project
[ ] Extension of existing project

Project Duration: 12 Months

Proposed Budget: -------approx. PKR

The Problem:

As a software system evolves over time, it becomes more difficult to maintain. Its design
grows increasingly complex and difficult to follow. Developers spend more than 60% of
their time understanding the code before proceeding with maintenance, resulting in major
costs; as a result, it is important to rearrange the code on a regular basis. When rewriting
code, the most important thing is to verify that the program behaves the same way it did

Final Year Project Proposal Page 6 of 28

before the reorganization. Refactoring is a term for software modifications that maintain
meaning.

Refactoring can be overwhelming when it comes to detecting and removing code smells.
Without sufficient expertise and knowledge of the software's design, the chances of
breaking the code and damaging the design are considerable. Refactoring might
inadvertently modify software functionality if done incorrectly. When refactoring is done
correctly, it not only maintains software behavior but also avoids the introduction of new
bugs.

Refactoring improves internal program attributes such as reusability, maintainability, and

readability, rather than exterior software qualities. The fact that software design evolves
regularly throughout development is obvious. Refactoring increases reuse of existing
code rather than rewriting new line of code, which is a good coding discipline.

In this project, we focus our attention on code smells and on automatic tools Developed
for their detection Coding smells are structural features of software that can suggest a
code or design issue, making it difficult to improve and maintain. Fowler [Fow99], who
specified 22 different types of smells, first presented the term.

Synopsis:
The main goal for this project is to develop a prototype for the detection and presentation
of code smells in Java source code. Refactoring is a software engineering technique that
is used for restructuring existing source code, altering its internal structure without
changing its external behavior. By applying a series of small behavior-preserving
transformations, a software system’s design, readability and extensibility can be
improved. Code smells are signs that indicate that source code might need refactoring.

Target market for project is The complexity of software systems is rapidly increasing,
which leads software houses to anticipate continuous change. Developers spend more
than 60% of their time understanding the code before proceeding with its maintenance,
leading to massive costs.

These expenses can be reduced by detecting and eliminating code smells in the early
stages of development, help for java developer and automated detect smells in code.

Final Year Project Proposal Page 7 of 28

Section – 2

2.1 Introduction
Throughout the Software Design Life Cycle, software undergoes different modifications
(SDLC). By introducing undesired design flaws into the code, these changes cause it to
decrease in quality. In the early stages of the SDLC, developers usually pay little
attention to the overall architecture and system design. Most developers look for quick
and easy solutions for defects rather than an overall system design at later stages of
quality analysis (QA) and maintenance. This is due to a combination of inexperience,
deadline pressure, and management's perception of budgets. Effort spent in improving
system design can be perceived as an upfront cost with little short-term return when
compared to a quick bug fix, even though its long-term payback in terms of reduced
maintenance costs can be worthwhile. These problems lead to the introduction of
various design flaws, which are called code smells. According to Beck, Brant, Fowler,
Opdyke, & Roberts (2000), there are 22 code smells in object-oriented source codes.

Code Smells:

The term “Code Smell” appears to have been coined by Kent, Beck in the late 1990s
(Roperia, 2009). Let us consider an example to understand the meaning of code smell.
An unusual long method in an object-oriented programming language like Java might
indicate a “Long Method” smell. It indicates lack of understanding of or disregard for a
proper object design and the use of simple procedural programming in an object-
oriented language. This is a very common sign of code smell in object-oriented
language. In rare cases this could be normal, but most likely such long-winded methods
perform too much functionality thus making it difficult to understand and maintain. To
solve this problem, such methods should first be split into smaller methods or functions
to promote reusability. As a second step, if an object-oriented language is being used,
the object model should be reviewed as well. However, that does not mean that a long
method is always a code smell problem – it is most likely an indicator of a design issue
in the software than of a problem.

Refactoring:

Refactoring is a solution to the problem that is indicated by code smell. It's a method of
applying a better design to an already-existing, fully or partially functional software
program. It has a higher up-front cost than fast fixes and repair, but the long-term
advantages can be great. Refactoring is a more cost-effective solution than a total
program redesign. Large software is usually designed and tested over a long period of
time. A comprehensive rewrite needs again another lengthy development and testing
cycle. Refactoring existing code allows you to improve the software design and eliminate
code smells without having to build from zero.

If a method is long, splitting it into smaller methods is actually a refactoring technique

that improves the design of the source code, making it easier to understand, enhance,
and maintain. To better understand and emphasize the importance of refactoring, we

Final Year Project Proposal Page 8 of 28

 can take “Duplicate Code” smell as an example. Duplicate code is not just a design
issue; it also leads to incorrect calculations and redundant code and data. Therefore, to
ensure the software works as per specification, it is necessary to refactor duplicate lines
of code into smaller, more manageable methods and invoke these methods from the
client code. Thus, the refactoring technique improves the structure of the code
dramatically while retaining its functionality.

The ability to detect code smells correctly is essential for developing a reworking
strategy. The quality of code will improve if the plan is implemented correctly. The
refactoring process is affected by the system's smells, and it has a direct impact on
software maintenance costs. There are a total of 72 refactoring approaches, which are
divided into seven categories (Lassenius, Mantyla, & Vanhanen, 2003). One or more of
these refactoring techniques can be used depending on the code smell. If a class has
been recognized as carrying the "Data Class" smell, we can use the "Extract Method"
approach first, then the "Move Method" from the client class to the data class if the client
class method has several capabilities; otherwise, we can use just the "Extract Method"
technique.

2.2 Aim and Objectives

The main objective, which leads us in the development of this project, is Code smell
detection tools could help developers to maintain software quality by applying different
techniques for detecting code smells, and refactoring the some type of smell. Code smell
detection is a tool that analyses Java source code and detects code smell automatically.
The functionality of CSD is limited to detecting five code smells.

2.3 Benefits
Expected Outcomes:
The expected outcome for this project will be a user-friendly tool for anyone and this
project is Code smell detection tools could help developers to maintain software quality.
Key Benefits:
• Code smells point out the developer mistakes, which directly not affect the output
but violate the design principle.
• Code Smells point out the certain points in the source code where developer
violates the rules or laws of designing during development.
• The key benefit of this project is the Easy to understand when software update or
modifications save times improve maintenance and readability.

Final Year Project Proposal Page 9 of 28

Section – 3

3.1 Literature Review

Introduction:
Ever increasing maintenance costs are often a consequence of poor software design, bad
coding style, and undisciplined practices. Among the consequences of such a scenario,
error proneness stands out. Code smells are symptoms in source code that are indicative
of bad style and/or design. They violate good practices and design principles, affecting
understanding and maintenance and promoting a negative impact on software quality and
ease of evolution.

Code Smell and Refactoring:

The term “Code Smell” appears to have been coined by Kent, Beck on WardsWiki in the
late 1990s (Roperia, 2009). Let us consider an example to understand the meaning of
code smell. An unusual long method in an object-oriented programming language like
Java might indicate a “Long Method” smell. It indicates lack of understanding of or
disregard for a proper object design and the use of simple procedural programming in an
object-oriented language. This is a very common sign of code smell in object-oriented
language. In rare cases this could be normal, but most likely such long-winded methods
perform too much functionality thus making it difficult to understand and maintain. To solve
this problem, such methods should first be split into smaller methods or functions to
promote reusability. As a second step, if an object-oriented language is being used, the
object model should be reviewed as well. However, that does not mean that a long method
is always a code smell problem – it is most likely an indicator of a design issue in the
software than of a problem.

Refactoring is a solution to the problem which code smell indicates. It is the

implementation technique used to apply a better design to an existing, fully or partially
functional, software program. It does present a larger upfront cost compared to quick fixes
and patchwork; however, its long-term payoff can be significant. When contrasted with a
complete software rewrite, refactoring is a cost effective option. Large software usually
goes through a long cycle of development and testing. A complete rewrite means another
long cycle of development and testing. Refactoring existing code offers a way of improving
the software design and removing code smells without actually rewriting the entire code
from scratch.

If a method is long, splitting it into smaller methods is actually a refactoring technique that
improves the design of the source code, making it easier to understand, enhance, and
maintain. To better understand and emphasize the importance of refactoring, we can take
“Duplicate Code” smell as an example. Duplicate code is not just a design issue; it also
leads to incorrect calculations and redundant code and data. Therefore, to ensure the
software works as per specification, it is necessary to refactor duplicate lines of code into
smaller, more manageable methods and invoke these methods from the client code. Thus,

Final Year Project Proposal Page 10 of 28

 the refactoring technique improves the structure of the code dramatically while retaining
its functionality.

Fowler and Beck defined code smells as symptoms in the source code indicating that
there may be deficiencies in the design and/or programming style of a software system.
They proposed a catalog of 22 code smells to be used as indicators of poor design and
implementation choices. As a catalog, these code smells can also serve as a vehicle to
express what should be avoided to obtain good style and modularity in object-oriented
programming. Code smells usually appear during change activities and when software
bugs are fixed. To tackle this problem, approaches and tools were implemented to support
the identification of code smells.
Table 1. List of Code Smells according to Fowler and Corresponding Alternative Names.

Code Smells (Fowler) Alternative Name

Duplicated Code Clones (S15), Code clones (S1, S17)

Comments Comments Line (S12)

Long Method God Method (S4)

Long Parameter List Long Parameter List Class (S5)

Several tools are available to help detect code smells in program written in various
languages. In this study, we conduct a systematic literature review of published studies
(SLR). The influence of code smells on the occurrence of defects was reported in 16 of
the 18 research that were chosen. We identified 24 code smells with larger influence on
defects based on the analysis of these 16 research, particularly God Class, Comments,
Message Chains, and Feature Envy code smells. It was also possible to identify tools,
techniques, and resources that were used by several studies.

Refactoring Tools:
In early 1990s, Don Roberts and his colleagues developed a refactoring tool called the
Smalltalk Refactoring Browser [76]. This refactoring browser allows the user to perform
many interesting refactoring is automatically (e.g., Rename, Extract/Inline Method,
Add/Remove Parameter). However, this early tool was not popular because it was a
stand-alone tool separate from the integrated development environment (IDE).
Developers found it inconvenient to switch back and forth between the IDE (develop code)
and Refactoring Browser (refactor code).Thus later refactoring tools have been integrated
in the IDEs. The following are refactoring tools for Java.

IntelliJ IDEA:

Final Year Project Proposal Page 11 of 28

 This is an expensive commercial IDE. This tool also supports Rename and Move Program
Entities (e.g., package, class, method, and field), Change Method Signature, Extract
Method, Inline Method, Introduce Variable, Introduce Field, Inline Local Variable, Ex-tract
Interface, Extract Superclass, Encapsulate Fields, Pull-up Members, Pushdown Members
and Replace Inheritance with Delegation.

RefactorIt:
RefactorIt is a commercial software that supports many automatic refactoring’s. It can
cooperate with Sun 1 Studio, Oracle 9i JDeveloper and Borland JBuilder. The supported
refactoring’s are: Rename, Move Class, Move Method, Encapsulate Field, Create Factory
Method, Ex-tract Method, Extract Superclass/Interface, Minimize Access 9Rights, Clean
Imports, Create Constructor, and Pull Up/Push down Members.

JRefactory:
JRefactory is a tool that is first developed by Chris Seguin. However, Mike Atkinson has
taken over the leadership role since late 2002. This tool allows easy application of
refactorings by providing user interface based on UML diagrams as visualization of Java
classes. It can cooperate with JBuilder and Elixir IDEs. JRefactory supports the following
refactoring’s: Move Class, Rename Class, Add an Abstract Superclass, Remove Class,
Push up Field, Pull Down Field, Move Method.

JFactor:
JFactor for VisualAge Java is a commercial product that provide a set of refactoring’s.
Extract Method, Rename Method Variables, Introduce Explaining Variable, Inline Temp,
Inline Method, Re-name Method, Pull Up/Push Down Method, Rename Field, and Pull
Up/Push Down Field, Encapsulate Field, Extract Superclass/Interface.

Eclipse:
Eclipse is a generic development environment by IBM. It also has refactoring support and
some analysis. This project is open source. The current version of Eclipse (Helio version
3.6.1) supports many types of refactoring’s which include Move Method, Rename
Method, Encapsulate Fields and etc.

My Project (Code Smell detection using JAVA):

Our tool, analyzes Java source code to detect code smell automatically. CSD’s
functionality is limited to the detection of five code smells: “Switch Cases,” “Data Class,”
“Middle Man,” “Long Parameter List,” and “Long Method”. These code smells will be
discussed in detail later in this section. In cases where “Data Class “and “Long Method”
smells are detected, JSD provides an option to refactor the code. Refactoring techniques
are suggested for “Switch Cases,” “Middle Man,” and “Long Parameter List” smells.

Final Year Project Proposal Page 12 of 28

 Comparison:

Refactoring Tools
IntelliJ RefactorIt JRefactory JFactor Eclipse My Project
Technique/ IDEA (Code Smell
Method detection
using JAVA)
Extract Yes Yes No Yes Yes Yes
Method
In Line Yes No No Yes Yes Yes
Method
Replace No No No No No Yes
Method
Replace
temp with No No No No No Yes
Query
Move No Yes Yes No Yes Yes
Method
Push Down Yes Yes Yes Yes Yes Yes
Method
Rename Yes Yes Yes Yes Yes No
Method
Encapsulate Yes Yes No Yes No Yes
Field
Pull Up Yes Yes Yes Yes Yes No
Method
Create No Yes No No No No
Constructor
Extract Super No
classes Yes Yes No Yes Yes
Replace
Parameter
with Explicit No No No No No Yes
Methods
Replace
Delegation Yes No No No No Yes
with
Inheritance
Abstract
Super Class No No Yes No No No
Remove No No Yes No No Yes
Middle Man

Final Year Project Proposal Page 13 of 28

 Replace
Conditional
with No No No No No Yes
polymorphis
m
Replace type No No No No No Yes
code
Hide Method No No No No No Yes
Introduce
parameter No No No No No Yes
object
Preserve
Whole object No No No No No Yes

Summary:
Code smell detection is a very complex procedure. Careful design analysis of the
Software system is required for detecting the code smell. It is believed that human intuition
is the best way to detect code smell (Roperia, 2009); however, detection becomes more
difficult as system size increases. This creates the need for automated detection,
especially for larger systems. The automatic detection of code smell can be done using
statistical data analysis. However, the detection of all of the 22 smells using statistical
data is not possible (Bhalla, 2009).

https://www.researchgate.net/publication/320262316_On_the_evaluation_of_code_smells_and_d
etection_tools
https://jserd.springeropen.com/articles/10.1186/s40411-017-0041-
1#:~:text=In%20this%20study%2C%20we%20analyze,are%20presented%20and%20discussed%
20below.
https://homepages.cwi.nl/~storm/teaching/reader/LieberherrHolland89.pdf

Section – 4

4.1 Research Approach

Development / Research Methodology:

For our project, we will be using Agile Development Model. The Agile Development
Model refers to an approach to software development based on an iterative approach to
software delivery that, instead of trying to deliver all at once, develops software
incrementally from the beginning of the project. Agile strategies split projects into smaller
iterations or modules that do not require long-term preparation directly. At the start of
the planning process, the project scope and requirements are laid down. Plans are
specifically defined in advance about the number of iterations, the duration, and the
scope of each iteration.
Final Year Project Proposal Page 14 of 28
 In the Agile method model, each iteration is regarded as a short time "frame" which
usually lasts from one to four weeks. The division of the whole project into smaller parts
helps to minimize the risk of the project and to reduce the overall criteria for project
delivery time. Each iteration requires a team working through a complete life cycle of
software development, including planning, analyzing requirements, design, coding, and
testing before the client is shown a working product.
In the Agile model, steps involve:

• Requirement gathering and Analysis

• Design
• Coding
• Testing/ Quality Assurance
• Deployment
• Feedback

1. Requirements gathering and Analysis: In this phase, requirements will be

gathered according to this project. This project does not require any extra
hardware. It will be designed for JAVA programming code smell detection. There
will be no hardware cost and minimum 40 weeks would be required to complete
the development.
2. Design: As the project requirements will be clear before this phase, we will Work
with team member and supervisor to identify requirements when you have
defined the project. To show the work of new features, we can use the user flow
diagram or the high-level UML diagram to show how it will apply to our tool.
3. Coding: The work starts when the team determines the requirements. Designers
and developers are beginning to work on their project, which is intended to
incorporate a working product. In this phase, the development of detection tool
will begin. UI/UX designer will start working.
4. Testing/ Quality Assurance: The Quality Assurance team tests the performance
of the product in this process and searches for the bug.
5. Deployment: The team releases a product for the work environment of the
customer in this process.
6. Feedback: The last step is feedback after launching the product. In this, the team
receives reviews about the product and works through the feedback.

Our tool analyzes Java source code to detect code smell automatically. Our tool
functionality is limited to the detection of five code smells: “Switch Cases,” “Data
Class,” “Middle Man,” “Long Parameter List,” and “Long Method”.

Implementation Platform:
Code Smell Detection is implemented in Java and uses the Abstract Syntax Tree
(AST) parser. Abstract syntax tree is the tree structure representation of the source
code in any programming language. Each node of the syntax tree represents a part of
the abstract syntactic structure of the source code.

Final Year Project Proposal Page 15 of 28

 The classes of the input Java project are parsed through the AST Parser. The
detection process is done in two phases: During the initial phase, Our tool parses each
class to gather statistical data by visiting each AST node and creates an array list of
the method and variable names for each class. Our tool also creates a list of all the
class names used during the detection for “Data Class” smell. During the second
phase, our tool uses the gathered statistical data and the AST to identify the code
Final Year Project Proposal Page 16 of 28
 smells requested by the user. The detected code smells are then presented to the
user. Our tool also provides the option of applying refactoring techniques step by step.
The user can choose to accept or discard the refactoring suggestions.
Key Milestones and Deliverables:

Elapsed time
S.
since start of Milestone Deliverable
No.
the project
Group Creation and Proposed
Submission of Group,
1. Week 01 – 04 idea + abstract + design
Proposal, An Approval
Flowchart
Write Project Introduction,
Related Website research
2. Week 05 – 08 Problem Statement and
and evaluate
Literature Review
Write Research approach,
Research Methodology,
3. Week 09 – 12 Milestone and design Milestone
Project Use case, ERD
chart.
Write Functional and Non
Functional Requirements, and
Diagrams and Design and
4. Week 13 – 16 Design Use cases and ERD’s
budgeting
Business canvas model,
Budgeting
Prototyping, poster and
5. Week 17 – 20 Final Report and Poster
Complete Project Report
6. Week 25 – 24 Working on implementation code
Designing and
7. Week 25 – 28 Designing Code Implementation
Development
8. Week 29 – 32 UI Testing, Logic Testing Test System
Product Testing and end user A Product Set up of Test
9. Week 37 – 36
feedback System
Deployment/Delivery of
10. Week 37 – 40 Delivery of Product
Final product

4.2 Functional and Non-Functional Requirements:

Functional Requirements:
A system needs to be developed based on the following functional requirements:

• The tool must provide user friendly UI in order to use it easily

• The tool must detect the smell with accuracy.
• Browse source code file from Ide.
• Detect code Smells automatically.
• Option of applying refactoring techniques.
• User can choose to accept or discard the refactoring suggestions.
Final Year Project Proposal Page 17 of 28
Non-Functional Requirements:

• The tool must use correct command each time.

• The tool must be expandable, in case of add more type of smells detection over
the time.
• The tool must be refactor code with maximum accuracy in order to be reliable on
it.

4.3 Use Case:

Browse Source
Code File

Select Switch Case

Smell

Select Data Class

Smell

Select Middle Man

Smell

Developer
Select Long Method
Smell

Select Long Method

Parameter List
Smell

Refactor

4.4 Use Cases Narrative

Final Year Project Proposal Page 18 of 28

 Actor Goal Brief
Developer can browse or select
source code file, Detect Smell and
select five types of smells like data
class, switch case, Middleman,
Use tool for detect code smell And
Developer Long method and Long method
refactoring.
parameter list. The user can
choose to accept or discard the
refactoring suggestions.

4.5 Risk Analysis

Risk Likelihood Impact Mitigation

(Low, Med,
High)
Project completion Med Serious Paying a lot of attention to project
delays planning and Constantly track and
measure the progress.
The budget is not Med High Backup budget planning
enough / exceeds

Lack of team members Med High Tools for project management will be
cooperation used to support individual activities.
Laptop Issue High Serious Keep a laptop Backup

Section – 5

5.1 Resources & Other Requirements

Project Team:

Title / Position Number

Project Supervisor 1
Team Leads 1
Researchers 2
Developers 2
Designers 1

Final Year Project Proposal Page 19 of 28

 Software Quality Assurance 2

Team Structure:

Project Supervisor
Sir Israr Ali

Researcher
Team Leads
Azhar Zafar/Muhammad
Azhar Zafar
Jahangir

Developer Designer
Hamza Rehman/Azhar Zafar Usman Junaid

SQA
Azhar Zafar/Hamza Rehman

Final Year Project Proposal Page 20 of 28

 Title/Position Role/Key Minimum Expertise / Minimum
(of each member) Responsibilities Qualificatio Background Experience
n Required Required Required
(years)
Project Supervisor Overall responsibility Masters Leadership, 15
for a successful Negotiation,
planning, manage all Scheduling,
processes in the Risk
project Management,
business skills.
Team Leads Team leader will lead Bachelors in Strong 3
a team within the CS Organization
project Skills,
Confident in the
Team,
Respectful to
Others, Fair
and Kind
Researchers Research about the Bachelors in Attention to 2
project and CS detail
innovation and ideas/ ,Technical
Develop back end, skills, Critical
algorithm thinking,
Communication
, Planning and
scheduling
Developers Responsible for Bachelors in Technical skills, 2
developing android CS Critical thinking,
application Communication
, Planning and
scheduling /
JAVA
Designers Develop UI graphic Bachelors in Design/ Web 2
Design CS/SE or Design/ Poster
graphics Design
designing
certification
Software Quality For performing Bachelors in SDLC process, 2
Assurance software life cycle, Cs Quality
and for testing Engineering
overall system

Bibliography
Anonymous. (n.d.). Gendarme Rules Smells. Retrieved April 10, 2011, from Mono-Project

Final Year Project Proposal 21 | P a g e

Website: http://www.mono-project.com/Gendarme.Rules.Smells
Bhalla, D. (2009). Automatic detection of bad smells in Java code. Long Beach: ProQuest®
Dissertations & Theses .
Chaikalis, T., Tsantalis, N., & Chatzigeorgiou, A. (2008). JDeodorant : Identification and
Removal of Type-Checking Bad Smells. Software Maintenance and Reengineering,
2008. CSMR 2008. 12th European Conference (pp. 329-331). Athens: IEEE.
Code Smell. (2011, March 26). Retrieved April 10, 2011, from Wikipedia:
http://en.wikipedia.org/wiki/Code_smell
Cusumano, M. A., & Shelby, R. W. (1995). Microsoft Secrets. New York: NY: The Free Press.
Fokaefs, M., Tsantalis, N., & Chatzigeorgiou, A. (2007). JDeodorant: Identification and
Removal of Feature Envy Bad Smells. Software Maintenance, 2007. ICSM 2007. IEEE
International Conference (pp. 519-520). Paris: IEEE.
Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (2000). Refactoring Improving The
Design Of Existing Code. New Jersey: Addison-Wesley.
Gallardo, D. (2003, September 9). IBM Developer Works Technical Library. Retrieved March
25, 2011, from IBM Developer Works Web Site:
http://www.ibm.com/developerworks/library/os-ecref/
Holland, I. & Lieberherr, K. J. (1989). Assuring Good Dtyle of Object-Oriented Programs.
IEEE Software , 329-331.
Lungu, M., Ersze, G., Marinescu, R., & Mihancea, P. F. (2008). Prodeoos. Timisoara, Romania .
Mantyla, M., Vanhanen, J., & Lassenius, C. (2003). A Taxonomy and Initial Emphirical Study of
Bad Smells in Code. Proceedings of the International Conference on Software
Maintenance (p. 381). IEEE.
Marinescu, R. (2005). Measurement and Quality in Object-Oriented Design. Proceedings of the
21st IEEE International Conference on Software Maintenance. IEEE.

Final Year Project Proposal 22 | P a g e

Annexure–A: Project Schedule / Milestone Chart / Gantt chart

Annexure–B: Proposed Budget

ENTER
ESTIMATION
VARIABLES,
BELOW

PROJECT MANAGEMENT EFFORT % 40%

PROJECT MANAGEMENT OFFICE EFFORT % 50%

PROJECT CONTROL OFFICE EFFORT % 10%

TOTAL SHOULD BE 100% -------------------> 100%

WORK DAY LENGTH IN HOURS 8

ESTIMATED START DATE 10-09-2021

COMPUTED ESTIMATED END DATE 06-04-2022

ESTIMATED PROJECT DURATION IN WEEKS 34.0

Final Year Project Proposal 23 | P a g e

 ESTIMATED ACTUAL
PHASE
HOURS HOURS

Business Requirements
328 320
Functional Specifications
328 300
Detailed Design
408 399
Code and Unit Test
408 399
System Testing
328 322
User Acceptance Testing
328 322
Project Manager
168 201.60
-
Project Control Office
168 50
Project Management Office
168 252

COMPUTED
COMPUTED
TASK
WORK EFFORT
DURATION IN
IN DAYS
DAYS

40.0 13.3

37.5 18.8

49.9 4.5

49.9 4.5

41.0 10.3

Final Year Project Proposal 24 | P a g e

 40.3 10.1

258.5 61.5

25.2 61.5

21.0 61.5

31.5 61.5

ENTER RISK $
30%
CONTINGENCY 37,426.65
BASELINE
$
PROJECT COST
162,182
ESTIMATE
PROJECT
$
MINIMUM 30%
210,837
ESTIMATE
PROJECT
$
MAXIMUM 50%
243,273
ESTIMATE

Final Year Project Proposal 25 | P a g e

Annexure–C: Business Canvas Model:

Final Year Project Proposal 26 | P a g e

Prototype:

Final Year Project Proposal 27 | P a g e