Sefinal 68

Software Engineering 16CE072
Practical-1
AIM:- Study and compare different software process models and compare
them based cost, simplicity, risk, involvement of user, flexibility, maintenance,
integrity, security, reusability, and requirement. Study waterfall model,
incremental model, spiral model, AGILE and RAD models
Software Required: - None
Knowledge required: - importance of software engineering.
Theory/Logic:-
Waterfall model:-Longer period and a very well-formed structured to analysis of the system. So it
is better for some security and defense project.
Incremental model: - The incremental build model is a method of software development where
the product is designed, implemented and tested incrementally (a little more is added each time)
until the product is finished. It involves both development and maintenance.
Prototype model: - Prototyping is used to allow the users evaluate developer proposals and try
them out before implementation. It also helps understand the requirements which are user specific
and may not have been considered by the developer during product design.
Raid model: - RAD model is Rapid Application Development model. It is a type of

incremental model. In RAD model the components or functions are developed in parallel as if they
were mini projects. The developments are time boxed, delivered and then assembled into a
working prototype.
Spiral model: - The spiral model is a risk-driven process model generator for software projects.
Based on the unique risk patterns of a given project, the spiral model guides a team to adopt
elements of one or more process models, such as incremental, waterfall, or evolutionary
prototyping.
Agile model: - Agile SDLC model is a combination of iterative and incremental

process models with focus on process adaptability and customer satisfaction by rapid delivery of
working software product. Agile Methods break the product into small incremental builds. These
builds are provided in iterations.
1
Comparison :-
Incremen Prototyp
Parameter Process Waterfall tal e Rad Spiral Agile
Model Model Model Model Model Model Model
Much
Cost Low Low High Very high expensive Expensive
Simplicity Simple Simple Low Simple Medium Simple
Novel
Risk High Risk Yes Low Yes No
Only at
Involvement of user beginning Yes High Yes High Yes
Flexibility No Low No Yes Yes Yes
Maintaina
Maintenance Least ble High Easy Typical Easy
Integrity Least Robust Weak Vital High Less
Security Vital Robust Weak Vital High Yes
Re-usability Limited Yes Yes Yes Yes More
Requireme
nt Yes Yes No Yes No Yes
Conclusion:-
Process models help the application to be integrated into the entire framework. Some work
application can use sprightful the concept of a model. Some application demand a very different
hybrid of various models.
2
Practical-2
AIM: - Design questionnaires and other Techniques to elicit the requirements
for a given project.
Software Required: - None
Knowledge Required: - Communication Skills
Questions:
1. What is your work domain?

2. What is your workflow?
3. What is your existing system?
4. What are your problems and how we can meet your requirements?
5. Which is the necessary function do you want?
6. Who is your user ? who will give input?
7. Who will get output?
8. What are approximate number of users?
9. Who are your stakeholders?
10. What are the results you expect from us?
11. When will be ready to start?
12. What is your deadline?
13. Which security feature do you want?
14. How often you want update and maintenance?
How requirements questions

 How will you use this feature?
 Is this feature a process and, if so, what are the steps? Or, what questions can I ask to ascertain
the steps?
 How might we meet this business need?
 How might we think about this feature a bit differently?
 How will we know this is complete?
Where requirements questions

 Where does the process start?
 Where would the user access this feature?
 Where would the user be located physically when using this feature?
 Where would the results be visible?
3
When requirements questions

 When will this feature be used?
 When do you need to know about…?
 When will the feature fail?
 When will we be ready to start?
Who requirements questions

 Who will use this feature?
 Who will deliver the inputs for the feature?
 Who will receive the outputs of the feature?
 Who will learn about the results of someone using this feature?
 Who can I ask to learn more about this?
What requirements questions

 What do I know about this feature?
 Or, what assumptions am I making about this feature that I need to confirm?
 What does this feature need to do?
 What is the end result of doing this?
 What are the pieces of this feature?
 What needs to happen next?
 What must happen before?
 What needs to be tracked?
Why requirements questions

 Is there any other way to accomplish this?
 Does this feature meet the business need and solve the problem we’re trying to solve?
Desired Future state
1. What business requirements will this system address?

2. What information do you need from this system that you don’t have now?
3. Where is any of this data currently captured in another corporate system?
4. How would you like to see this information?
5. What functionality do you need from the system?
6. What data and/or functionality is shared by other (many) business areas?
7. If the reports were dynamic, what would they do differently?
8. How much historical information is required?
4
Business Objectives
1. What are your goals in developing this system?

2. Who are the key stakeholders and users? Do their goals differ? If so, how?
3. How do the system goals map to business goals?
4. What is the most important business goal of the system?
5. How will the system change the way you are doing things now?
6. How will the system help you be more efficient?
7. What are the system deliverables?
8. What will the new system accomplish that is not currently accomplished manually or
with other systems?
9. What will the new system do?
Current Problems
1. What are the current problems you are facing today without the system?
2. What problems should this system solve?
3. What do you have to do manually that you would like to automate?
4. What performance problems need to change?
5. What functional limitations would you like to change?
6. What packages are you using that force you to constrain your business functionality to
the boundaries of the package?
7. Which reports do you currently use? What data on the report is important? How do you
use the information?
8. Where are there specific bottlenecks to getting at information?
9. How do you analyze the information you currently receive? What type of data is
used? How do you currently get the data? How often do you get new data?
10. What type of ad hoc analysis do you typically perform? Who requests ad hoc
information? What do you do with the information?
Success Criteria (What does “winning” look like?)

1. What is most important for success of the application?
2. What do we need to accomplish to make this project successful?
3. What do we need to change to make this project successful?
4. What buy-in do we need?
5. What critical elements such as budget, resource allocation, or support are we lacking?
6. What are training considerations for developers and users?
Identify Users
1. Who will be using the system?

2. What are the titles and roles of the people who will use the system?
3. What are their levels of expertise?
5
Assumptions
1. List assumptions.
2. List open issues, responsible parties and resolution date.
Conclusion: -
The aim of the contribution was to describe requirements engineering as a mandatory phase which
all development process start with. The requirements elicitation takes very important role in a
project success.
6
Practical-3
AIM:- Determine and analyze the functional nonfunctional Requirements
for a given project.
Software Required :- None
Functional requirement:
1) First time login page.
2) Fingerprint scan valid for 2 minutes.
3) Scan barcode with changing images.
4) Professor login page and attendance taking page.
5) Send data to server and process.
6) Sort the id received and store those in one cell.
7) Professor should see total number of students present at attendance time
8) Professor and students should be able to view attendance per day, per month.
9) Delete attendance by faculty.
Non Functional requirement
1) Accessibility
2) Adaptability
3) Auditability and control
4) Availability
5) Backup
6) Capacity, current and forecast
7) Configuration management
8) Cost, initial and Life-cycle cost
9) Data integrity
10) Data retention
11) Deployment
12) Development environment
13) Disaster recovery
14) Documentation
15) Durability
16) Efficiency (resource consumption for given load)
17) Effectiveness (resulting performance in relation to effort)
18) Extensibility (adding features, and carry-forward of customizations at next major
version upgrade)
19) Failure management
20) Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management)
21) Legal and licensing issues or patent-infringement-avoidability
22) Maintainability (e.g. Mean Time To Repair - MTTR)
23) Management
24) Modifiability
7
25) Network topology

26) Performance / response time (performance engineering)
27) Platform compatibility
28) Privacy
29) Portability
30) Quality (e.g. faults discovered, faults delivered, fault removal efficacy)
31) Reliability (e.g. Mean Time Between/To Failures - MTBF/MTTF )
32) Resource constraints (processor speed, memory, disk space, network bandwidth,
etc.)
33) Response time
34) Reusability
35) Robustness
36) Safety or Factor of safety
37) Security (cyber and physical)
38) Stability
39) Supportability
40) Usability (Human Factors) by target user community
A functional requirement describes what a software system should do, while non-
functional requirements place constraints on how the system will do so.
Functional Requirements:
R1: Login
Login using roll number.
R2: Administrators
Some users are promoted as administrators which gives them extra rights over the system
and which can manage database. Which has also right to reset someone’s account and
block it.
R3: Report Generation
Daily reports are generated based on the buying and selling of products.
R4: QR Code Scanner
QR code scanner will scan QR code and make entry in database for valid user.
R5: Security
Security algorithm will compare check weather student is valid or not.
8
Non-Functional Requirements:
R8: Performance
Computer performance is the amount of work accomplished by a computer system.
R9: Scalability
Scalability is the capability of a system or process to handle an enhanced level of operations

without constraints or structural bottlenecks.
R10: Availability
Availability of a system is typically measured as a factor of its reliability –as reliability

increases, so does availability.
R11: Reliability
The ability of a component or system to function at a specified moment or interval of time.
R12: Maintainability
Maintainability is the ease with which a product can be maintained.
R13: Serviceability
It refers to the ability of technical support personnel to install, configure, and monitor
computer products, identify exceptions or faults, debug or isolate faults to root cause
analysis, and provide hardware or software maintenance in pursuit of solving a problem
and restoring the product into service.
R14: Usability
The degree to which a software can be used by specified consumers to achieve quantified
objectives with effectiveness, efficiency, and satisfaction in a quantified context of use.
9
Application:
To prepare a Formal Specification Document for functional and nonfunctional requirements.
Conclusion:-
Functional requirements are characterized by the core or the basic operations, an application is
expected to deliver, such as order, purchase, place order etc. On the contrary non-functional
requirements comprise of the extra or precisely the external factors that lay a foundation for an
application, say, how scalable an application is to be able to adapt to varying user loads, reliability
to ensure that the application isn't vulnerable to frequent malware attacks, delivers a consistent
performance and so on.
Thus requirements for functional and non-functional aspects are inseparable to ensure an
application's sustenance in the long run.
10
PRACTICAL 4
AIM: - SRS document for given project. (IEEE Standard)

Software Required: None
Knowledge Requirement: About SRS and its characteristics of SRS.
Theory
The SRS document should contain the following aspect of the system.
1. Functional Requirement.
2. Non-functional Requirement
3. Goals of Implementation
11
Software Requirements
Specification
for
Android Base Attendance

System
Version 1.0 approved
Prepared by NIRAV C. PANSURIYA, JAIMIL PATEL, KEVAL PATEL
THE LIZARD SOLUTION
2nd October 2018
12
Software Requirements Specification for attendance
system Page xiii
Table of Contents
Table of Contents xiii
Revision HistoryError! Bookmark not defined.
1. Introduction 15
1.1 Purpose 15
1.2 Document Conventions 15
1.3 Intended Audience and Reading Suggestions 15
1.4 Product Scope 15
1.5 References Error! Bookmark not defined.
2. Overall Description 16
2.1 Product Perspective 16
2.2 Product Functions 16
2.3 User Classes and Characteristics 16
2.4 Operating Environment 16
2.5 Design and Implementation Constraints 16
2.6 User Documentation 3
2.7 Assumptions and Dependencies 17
3. External Interface Requirements 4
3.1 User Interfaces 4
3.2 Hardware Interfaces 5
3.3 Software Interfaces 5
4. System Features 6
4.1 System Feature 1 6
4.2 System Feature 2 (and so on) 6
5. Other Nonfunctional Requirements 7
5.1 Performance Requirements 7
5.2 Safety Requirements 7
5.3 Software Quality Attributes 7
6. Other Requirements 7
Appendix 8
xiii
Software Requirements Specification for attendance
system Page xiv
Change History
Date Version Description Updated By
2nd October 2018 1.0 Initial Draft The Lizard Solution
xiv
Introduction
Purpose
Purpose of this project is to provide smart, fast and paperless Attendance System. This system
id very secure and make sure that no one can do fake attendance. The convention attendance
system is more time consuming and hard to maintain. This project will overcome all this
problems.
Document Conventions
Bold Text shows heading in this document. Normal Text shows content of each section. Square
and Round symbols are used for E-R Diagram.
Intended Audience and Reading Suggestions
Intended Audience are Project Manager, Coders, Designers and other readers. This SRS is
divided into four six parts: Introduction, Overall Description, External Interface Requirements,
System Features, Non-functional requirements, Other Requirements.
Product Scope
This project will make attendance procedure very smart, fast and paperless. By this one can
easily manage attendance. This project can be used in colleges and universities.
15
Overall Description
Product Perspective
This project is better replacement of conventional attendance management system. Student and
Professors are stakeholders of this product. Android and web technology is used in this project.
As a interface between database and student’s mobile devices, LAN technology is used.
Product Functions
 Login
 Recognize User
 Check if user is fake or not
 Scan QR Code
 Check validity of QR code
 Make Entry in Database
 Generate Report For Faculty
User Classes and Characteristics
Developer will use this SRS for functional requirements. Clients will use this SRS for check
whether product is completed or not. Project Manager will user this SRS for check progress of
this product. User will use SRS for know about working of the product.
Operating Environment
 Android (Version Grater Then 6.0)

 Web Browser (Java Script)
 MySQL Database
Design and Implementation Constraints
LAN is medium between android device and database. So, sometimes network issues can
cause system failure. Someone can capture and send qr-code to another student and scan
rapidly. In this case, fake attendance can be possible.
16
User Documentation
User Manual will be delivered at the time of installation of product.
Assumptions and Dependencies
The product will not work properly if there is not enough updated android version. In very big
classrooms, it is possible that qr code will not scanned by application because of large distance.
So, one can assume that qr code will be enough near of every student.
17
External Interface Requirements

User Interfaces
Student has to login with this screen. It will show error if ID or PASSWORD will be wrong.
Otherwise it will go to scan qr code screen.
Student will scan qr code with this scanner. If student will not be fake then Success message
will be shown. Otherwise error will be generated.
Hardware Interfaces
Android devices will be used for run product. For that user has to install given apk. LAN network
will be use for communication between device and database. Universities’ LAN (wifi) will be use
for it. Android device camera will be use for scan qr code. Qr code will be shown on projectors.
18
Software Interfaces
Android will grater version than 6.0 will be use for run application. My sql database will be use
for store data. Java script will be use for generate dynamic qr code. Good web browser wll be
use for shows it.
System Features
Security
4.1.1 Description and Priority

Security is very prior feature of this product. This product will make sure that no fake attendance.
4.1.2 Stimulus/Response Sequences
 Check device IMEI number with previous log entry. If it is different than user is fake.
 Also check if there is no already entry of the user in database.
4.1.3 Functional Requirements
REQ-1: User has to give permission of read IMEI number to the application.
Database Entry

Database entry is also very prior feature. If student is not fake then there must be entry in database of the
student.
Check if student is not fake. Then will do id of student in database.
REQ-1: Mysql Database
Report Generation

It’s priority is medium. If any faculty wants then they can generate attendance report.
First of all it will get data from database and then generate report.
REQ-1: Android Application developed by us
19
Other Nonfunctional Requirements

Performance Requirements
Qr code must be scanned in less than 3 seconds. At a time average 60 students can be able to
do attendance. Response time must be less than 2 seconds. There must be consistency in
database. User interface must be simple and less time consuming.
Safety Requirements
Database server must be in safe environment, otherwise it can cause in data loss. At some
particular time, there must be data backup of database.
5.3 Software Quality Attributes
This system is very easy to use and very less time consuming.
Other Requirements
There must be good LAN network and enough resources in universities (like projector).
Appendix
Android OS 2
Flow Chart 2
User Interface 4
Report Generation 6
MySql Database 6
Security 6
IMEI Number 6
LAN Network 7
20
PRACTICAL – 5
AIM: Study the estimation techniques using LOC, Function Point and COCOMO.
After manual calculation use COSTAR/SYSTEM STAR Tool to calculate and
explore other parameters for estimation of cost of your project. Study Analogous,
Parametric, Three-point, Bottom-up estimating techniques.
Software Required: COSTAR/SYSTEM STAR Tool
Knowledge Required: Number of inputs, outputs, records, inquires to the projects.
Theory/Logic:
The cost and effort required to build software, the number of lines of code produced, and
other direct measure are relatively easy to collect, as long as specific conventions for
measurement are established in advance. However, the quality and functionality of
software or its efficiency or maintainability are more difficult to assess and can be
measured only indirectly.
Size-oriented software metrics are derived by normalizing quality and/or productivity

measures by considering the size of the software that has been produced. The normal
methodology includes the lines of code as the normalization value.
Estimation Technique used: The project size is a measure of the problem complexity in
terms of the effort and time required to develop the product. Currently, two metrics are
popularly being used to estimate size: Line of code (LOC) and function point (FP).
Parameters Count Simple Average Complex Total

No. of user Input 25 X3 4 6 = 75
No. of user Output 11 X4 5 7 = 44
No. of Inquires 1 X3 4 6 =3
No. of Files 1 X7 10 15 =7
external Interface 0 X5 7 10 =0
FP Count:
FP = count total*[0.65+0.01 *∑(Fi)] FP = 31* [0.65+0.01*129]
21
FP = 60.14
Function Point is: 60.14

Line of code (LOC) = FP*30 = 60.14*30 = 1804.2 KLOC = 1.8042
Software Project Type
Type ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Effort = ab*(KLOC) ^bb

= 3.0*(1.8042) ^1.12
= 3.69 PM
Tdev = cb * (Effort) ^db
= 2.5*(1.8042) ^0.35
= 3.57 Months
Advantage/Disadvantage: Size oriented metrics is based on the simple fact of LOC or

KLOC which can be measure directly and hence various estimations can be done that
easily. But on the other hand LOC measures are programming language dependent, and
hence there can be various repercussions based on the later said fact. On the other hand
FP metrics are calculated based on the functionality measures but the weighting scale can
be taxed dependent on the person calculating the data.
The main advantage stems from the prior cost and effort estimation of the project, and
hence a trajectory of the effort can be calculated. This helps in proper unlocking of the
resources. The main disadvantage stems from the fact that the scale is weighted, and is
prone to human errors and considerations. Hence a chance of very high under-valuation
or over-valuation is possible
Application: Understanding the complexity of the project and effort and cost estimation
prior to project contract
22
PRACTICAL-6
AIM: Develop a Software Project Management Plan (SPMP) using Microsoft Project
2003/2007. (OpenProject, LibrePlan, ProjectLibre) And also prepare SPMP document.
Software Required: Microsoft Project , OpenProject, LibrePlan, ProjectLibre
Knowledge Required: Number of lines of codes and functionality derivation of the

project. Also the number of inputs, outputs, records, inquires to
the projects.
Theory/Logic:
Software project management is an art and science of planning and leading software
projects. It is a sub-discipline of project management in which software projects are
planned, implemented, monitored and controlled.
Need of Project Management:
Software is said to be an intangible product. Software development is a kind of all new
stream in world business and there’s very little experience in building software products.
Most software products are tailor made to fit client’s requirements. The most important
is that the underlying technology changes and advances so frequently and rapidly that
experience of one product may not be applied to the other one. All such business and
environmental constraints bring risk in software development hence it is essential to
manage software projects efficiently.
The image above shows triple constraints for software projects. It is an essential part of
software organization to deliver quality product, keeping the cost within client’s budget
constrain and deliver the project as per scheduled. There are several factors, both internal
and external, which may impact this triple constrain triangle. Any of three factor can
severely impact the other two. Therefore, software project management is essential to
incorporate user requirements along with budget and time constraints.
23
TABLE OF CONTENTS
1. INTRODUCTION .............................................................................. 3
a. Objective ........................................................................................ 3
b. Major Function .............................................................................. 3
c. Performance Issue ......................................................................... 3
d. Management and Technical Constraint ......................................... 3
2. PROJECT ESTIMATION................................................................. 4
a. Historical Data Used ...................................................................... 4
b. Estimation Technique Used ............................................................ 4
c. Effort, Resource, Cost, Project Duration Estimation ..................... 4
3. RISK MANAGEMENT ..................................................................... 4
a. Risk Analysis .................................................................................... 4
b. Risk Identification ............................................................................ 4
c. Risk Estimation, Risk Abatement Procedure ................................... 4
4. SCHEDULE ........................................................................................ 5
a. Work Breakdown Structure ............................................................. 5
b. Gantt Chart ...................................................................................... 5
5. PROJECT RESOURCES .................................................................. 6
a. People .............................................................................................. 6
b. Hardware and Software .................................................................. 6
6. STAFF ORGANIZATION ................................................................ 6
a. Team Structure ................................................................................ 6
24
1. Introduction
a. Objective
Conventional attendance management system is very hard to manage and very

time consuming. It also requires lots of paper per day. And report generation
is very hard. To overcome these problem, we developed attendance
management system based on Android. It is very fast, easy to manage and
paper saving system.
b. Major function
There are 3 major functions
i. Login:
This functionality will enter a data about student and their mobile devices.
So no other user can make proxy or fake attendance.
ii. Scan QR Code

This functionality will scan QR code and check weather user is valid
Or not. If user is valid then it will make data entry of student in DB.
iii. Report Generator

This functionality will generate the attendance report if faculty wants.
c. Performance Issue
This application can misbehave if number of students are very large.
25
2. Project estimation
a. Historical data used

There has not been the use of any historical data.
b. Estimation technique used
FP method is used for estimation of this project
c. Effort resource, cost, project duration estimation
Here, adjusted FP value is 54.88 and our LOC by IEEE standard is (same as
Perl) 1646.
Hence, by using COCOMO model:
Effort Estimation: 4 person months
Duration Estimation: 2 months
So, we need 2 people to complete this project.
3. Risk management plan
a. Risk analysis
We have used MITRE technique for analyze risk of this software
b. Risk identification
Few risks are mentioned below:
i. Someone manage to get QR code outside of collage
Priority - high
If someone manage to get QR code outside the collage then he/she can
make fake attendance.
ii. Someone gets a database access

Priority - Medium
This can lead to data getting stolen.
c. Risk estimation, risk abatement procedure

This depends upon how loyal the staff is so that no one is affected if they are
loyal to their work.
26
4. Schedule
a. Work Breakdown Structure
b. Gantt Chart Representation
27
5. Project resources
a. People
There are 4 assigned roles
1. System Analyst
2. Designer
3. Coder
4. Tester
b. Hardware & Software

 Hardware
Desktop with minimum 2GB RAM.
 Software
Apache Tomcat
MYSQL Database
Web Browser
6. Staff organization
a. Team Structure
Project Manager and System Analyst – NIRAV C. PANSURIYA

Coder and Project Architecture – JAINIL PATEL
GUI Designer and Tester – KEWAL PATEL
Advantage/Disadvantage:
1. Collaborate with team members in real time.
2. Ability to manage risk, cost.
3. Project management software may complicate simple projects.
28
PRACTICAL-7
AIM : Prepare design document for your project (UMLet 14.2 ,SmartDraw,
Visio 2007)
1. Procedure oriented methodology (DFD up to level 2, Structure chart)
2. Object oriented methodology
3. GUI Design (ForeUI, Pencil Tool)
Software Required : Microsoft Visio,Pencil Tool,ForeUI,UMLLet 14.2,Smart Draw
Knowledge Required : Procedural approach and Object Oriented Approach for software
development.
 DFD
29
 E-R Diagram
 Usecase Diagram
30
 Sequence Diagram
31
 State chart Diagram
32
PRACTICAL – 8
AIM: Design Coding Standards and Guidelines for a given project. (C, C++, Java, HTML
etc.)
Software Required: None
Knowledge Required: Knowledge about coding standard and coding convention.
Theory/Logic:
Importance of Coding Guidelines:
Coding guidelines are which help in writing the software code efficiently and with
minimum errors. These guidelines, known as coding guidelines, are used to implement
individual programming language constructs, comments, formatting, and so on. These
guidelines, if followed, help in preventing errors, controlling the complexity of the
program, and increasing the readability and understandability of the program.
There are numerous programming languages for writing software codes, each having
different features and capabilities, coding style guidelines differ from one language to
another. However, there are some basic guidelines which are followed in all programming
languages. These include naming conventions, commenting conventions, and formatting
conventions.
Different coding Guidelines:
There are certain rules for naming variables, functions and methods in the software code.
These naming conventions help software; developers in understanding the use of a
particular variable or function. The guidelines used to assign a name to any variable,
function, and method are listed below.
• All the variables, functions, and methods should be assigned names that make the
code more understandable to the reader. By using meaningful names, the code can be self-
explanatory, thus, minimizing the effort of writing comments for variables. For example,
if two variables are required to refer to 'sales tax' and 'income tax', they should be assigned
names such as 'sales Tax' and 'income Tax'.
33
• For names, a full description in a commonly spoken language (for example, English)
should be used. In addition, the use of abbreviations should be avoided. For example,
variable names like 'contact Number' and 'address' should be used instead of 'cno' and
'add'.
• Short and clear names should be assigned in place of long names. For 'example,
'multiply The Two Numbers' can be shortened to 'multiply Numbers' as it is clear and
short enough to be expressed in reasonable length.
As with variables and constants, there are some guidelines that should be followed while
naming functions in the software code. These conventions are listed below.
• The names of functions should be meaningful and should describe the purpose of
the function with clarity and briefness. Like variables, the names should be self-
explanatory so that no additional description about the task of that function is required.
• The function name should begin with a verb. For example, the verb 'display' can be
used for the function that displays the output on the screen. In case the verb itself is not
descriptive, an additional noun or adjective can be used with the verb. For example, the
function name 'add Marks' should be used to clarify the function and its purpose.
• In case the function returns a Boolean value, the helping verbs 'is' and 'has' should
be used as prefixes for the function name. For example, the function name 'is Deposited'
or 'has Deposited' should be used for functions that return true or false values.
Implementing coding Guidelines
• All the codes should be properly commented before being submitted to the review
team.
• All curly braces should start from a new line.
• All class names should start with the abbreviation of each group. For example, AA
and CM can be used instead of academic administration and course management,
respectively.
• Errors should be mentioned in the following format: [error code]: [explanation]. For
example, 0102: null pointer exception, where 0102 indicates the error code and null
pointer exception is the name of the error.
• Every 'if statement should be followed by a curly braces even if there exists only a
single statement.
• Every file should contain information about the author of the file, modification date,
and version information.
34
Advantages of Coding Guidelines
Coding Standards:
Proper and consistent indentation is important in producing easy to read and

maintainable programs. Indentation should be used to:
• Emphasize the body of a control statement such as a loop or a select statement
• Emphasize the body of a conditional statement
• Emphasize a new scope block
A minimum of 3 spaces shall be used to indent. Generally, indenting by three or four

spaces is considered to be adequate. Once the programmer chooses the number of
spaces to indent by, then it is important that this indentation amount be consistently
applied throughout the program. Tabs shall not be used for indentation purposes.
Examples:
/* Indentation used in a loop construct. Four spaces are used for indentation. */
for ( int i = 0 ; i < number_of_employees ; ++i )
{
total_wages += employee [ i ] . wages ;
35
}
// Indentation used in the body of a method.
package void get_vehicle_info ( )
{
System.out.println ( “VIN: “ + vin ) ;
System.out.println ( “Make: “ + make ) ;
System.out.println ( “Model: “ + model ) ;
System.out.println ( “Year: “ + year ) ;
}
/* Indentation used in a conditional statement. */
IF ( IOS .NE. 0 )
WRITE ( * , 10 ) IOS
ENDIF
10 FORMAT ( “Error opening log file: “, I4 )
Inline Comments
Inline comments explaining the functioning of the subroutine or key aspects of the
algorithm shall be frequently used. See section 4.0 for guidance on the usage of inline
comments.
Structured Programming
Structured (or modular) programming techniques shall be used. GO TO statements shall

not be used as they lead to “spaghetti” code, which is hard to read and maintain, except
as outlined in the FORTRAN Standards and Guidelines.
Classes, Subroutines, Functions, and Methods
Keep subroutines, functions, and methods reasonably sized. This depends upon the
language being used. For guidance on how large to make software modules and
methods, see section 4.0. A good rule of thumb for module length is to constrain each
module to one function or action (i.e. each module should only do one “thing”). If a
module grows too large, it is usually because the programmer is trying to accomplish
too many actions at one time.
The names of the classes, subroutines, functions, and methods shall have verbs in them.
That is the names shall specify an action, e.g. “get_name”, “compute_temperature”.
36
Source Files
The name of the source file or script shall represent its function. All of the routines in a
file shall have a common purpose.
Variable Names
Variable shall have mnemonic or meaningful names that convey to a casual observer,
the intent of its use. Variables shall be initialized prior to its first use.
Example:
The variable names should be in camel case letters starting with a lower case letter. For
example, use 'total Amount' instead of 'Total Amount'.
Use of Braces
In some languages, braces are used to delimit the bodies of conditional statements,
control constructs, and blocks of scope. Programmers shall use either of the following
bracing styles:
for (int j = 0 ; j < max_iterations ; ++j)
{
/* Some work is done here. */
}
or the Kernighan and Ritchie style:
for ( int j = 0 ; j < max_iterations ; ++j ) {
/* Some work is done here. */
}
It is felt that the former brace style is more readable and leads to neater-looking code
than the latter style, but either use is acceptable. Whichever style is used, be sure to be
consistent throughout the code. When editing code written by another author, adopt the
style of bracing used.
Braces shall be used even when there is only one statement in the control block. For
example:
Bad:
if (j == 0)
printf (“j is zero.\n”);
Better:
if (j == 0)
{
37
printf (“j is zero.\n”);

}
Summary of Guidelines followed and not followed by us during our Project Coding
Implementation.
Name of Coding Standard Followed(Y)/Not Followed(N)

N
Inline Comments
Y
Structured Programming
Classes, Subroutines, Functions, and Y
Methods
Source Files Y
Y
Variable Names
N
Use of Braces
38
PRACTICAL – 9
AIM: Design the following for given project (Black Box Testing)
1. Test case
2. Test Suite
3. Testing Strategy
Also Design Test Cases using White Box Testing) , Gray Box testing and
Performance testing.
Software Required: Free software’s available on web portals. Can also use Win Runner,
Silk Runner, and Load Runner.
Knowledge Required: Testing skills is dependent on the software used to test the
software.
Theory/Logic:
Software Testing is evaluation of the software against requirements gathered from users
and system specifications. It is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test.
Black-box testing alludes to tests that are conducted at the software interface. They are
used to determine that software functional are operational, that input is properly accepted
and output is correctly produced, and that the integrity of external information (e.g.
database) is maintained. It does not consider the internal logic structure that importance.
White-box testing of software is predicated on close examination of procedural detail.

Logical paths through the software are tested by providing test cases that exercise specific
sets of conditions and/or loops. The status of the program may be examined at various
points to determine if the expected or asserted status corresponds to the actual status.
39
Black Box Testing:
Test Suites No: 1

Test Suite Detail: Login Function with Incorrect Username and Password and Submit
Button Click.
Test Function Test Case Expected Results Pass/Fail

Case ID Name (condition)
1 Login Username: abc This person cannot redirect Pass

Password: admin to Home page
2 Login Username: abc This person cannot redirect Pass
Password: abc to Home page
3 Login Username: admin This person cannot redirect Pass
Password: abc to Home page
40
PRACTICAL-10
AIM: Study different CASE tools and Testing tools (QTP, qTest, IBM Rational Functional tester, MSC
(message sequence chart), SDL (specification and description language), TTCN (testing and test
control notation), TTCN-3) and prepare a summary report.
Software Required: QTP, qTest, IBM Rational Functional tester, MSC, SDL, TTCN, TTCN-3
Knowledge Required: About CASE Tools and Automated Testing Tools.
Theory/Logic: Students has to prepare Case Study report on CASE Tools and Testing Tools like Win
Runner, Load Runner and Selenium Tool, Runtime testing tools.
CASE:
CASE (Computer-Aided Software Engineering) is the use of computer-based support in the

software development process. a CASE tool is a computer-based product aimed at supporting
one or more software engineering activities within a software development process; a CASE
environment is a collection of CASE tools and other components together with an integration
approach that supports most or all of the interactions that occur among the environment
components and between the users of the environment and the environment itself.
Advantage/Disadvantage: CASE Tools offer an excellent array of features that support the
development and business community through its Automated Diagram Support feature. The
various popular features that aid the development community are listed below:
 Checks for syntactic correctness

 Data dictionary support
 Checks for consistency and completeness
 Navigation to linked diagrams
 Layering
 Requirements traceability
 Automatic report generation
 System simulation
 Performance analysis
41
Automated Testing Tools:
1. Selenium
Selenium is possibly the most popular open-source test automation framework for Web
applications. Being originated in the 2000s and evolved over a decade, Selenium has been an
automation framework of choice for Web automation testers, especially for those who possess
advanced programming and scripting skills. Selenium has become a core framework for other
open-source test automation tools such as Katalon Studio, Watir, Protractor, and Robot
Framework.
Selenium supports multiple system environments (Windows, Mac, Linux) and browsers (Chrome,
Firefox, IE, and Headless browsers). Its scripts can be written in various programming languages
such as Java, Groovy, Python, C#, PHP, Ruby, and Perl.
While testers have flexibility with Selenium and they can write complex and advanced test scripts
to meet various levels of complexity, it requires advanced programming skills and effort to build
automation frameworks and libraries for specific testing needs.
2.QTP
Unified Functional Testing (UFT) software, formerly known as HP QuickTest
Professional (QTP), provides functional and regression testautomation for software applications
and environments. HPE Unified Functional Testing can be used for enterprise quality assurance.
HPE Unified Functional Testing supports keyword and scripting interfaces and features a graphical
user interface. It uses the Visual Basic Scripting Edition (VBScript) scripting language to specify
a test procedure, and to manipulate the objects and controls of the application under test.
42
3. qTest
There are many great features of this test case management tool, below are some:
 You can import and export test cases from Excel spreadsheet or other test management
tools
 Features to re-use test cases and test suites across multiple releases
 Easy requirement management and traceability
 Complete control over who modifies test cases
43
 Track changes to test cases and requirements

 Robust reporting with real-time status of test cycles, test results, test progress, and team
productivity.
4. IBM Rational
Rational Functional Tester is an object-oriented automated functional testing tool capable of

performing automated functional, regression, GUI, and data-driven testing. RFT supports a wide
range of applications and protocols, such as HTML, Java, .NET, Windows, Eclipse, SAP, Siebel,
Flex, Silverlight, Visual Basic, Dojo, GET and PowerBuilder applications.
Features
Rational Functional Tester includes the following features:
 Broad skills match – the IBM RFT tool has been designed for users of varying technical abilities
to ensure your quality assurance team isn’t tied up with basic
 Testing, and other experts in your business can get involved with and understand the test flow
using a visual storyboard format.
 IBM ScriptAssure® – advanced IBM technology learns user interface characteristics and applies
them to new software versions saving time spent creating new test scripts.
 Automated scripts – Rational Functional Tester enables your development teams to create
keyword associated scripts which allows for easy re-use, improving efficiency.
 Eclipse Java Developer Toolkit editor – makes it easy for your team to code test scripts in Java
with Eclipse. It automates code completion and offers advanced debugging options.
44
5. TTCN-3
The testing and test control notation (TTCN-3) is a new test specification and test implementation
language that supports all kinds of black-box testing of distributed systems.
TTCN-3 is built from a textual core language that provides interfaces to different data description
languages and the possibility of different presentation formats. This makes TTCN-3 quite universal
and application independent.
45

Sefinal 68

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sefinal 68

Загружено:

Авторское право:

Доступные форматы

Software Engineering 16CE072

Knowledge required: - importance of software engineering.

Raid model: - RAD model is Rapid Application Development model. It is a type of

Agile model: - Agile SDLC model is a combination of iterative and incremental

Model Model Model Model Model Model Model

Simplicity Simple Simple Low Simple Medium Simple

Flexibility No Low No Yes Yes Yes

Integrity Least Robust Weak Vital High Less

Security Vital Robust Weak Vital High Yes

Re-usability Limited Yes Yes Yes Yes More

Knowledge Required: - Communication Skills

1. What is your work domain?

How requirements questions

Where requirements questions

When requirements questions

Who requirements questions

What requirements questions

Why requirements questions

Desired Future state

1. What business requirements will this system address?

1. What are your goals in developing this system?

Success Criteria (What does “winning” look like?)

1. Who will be using the system?

Non Functional requirement

25) Network topology

Login using roll number.

R3: Report Generation

R4: QR Code Scanner

Security algorithm will compare check weather student is valid or not.

Computer performance is the amount of work accomplished by a computer system.

Scalability is the capability of a system or process to handle an enhanced level of operations

Availability of a system is typically measured as a factor of its reliability –as reliability

The ability of a component or system to function at a specified moment or interval of time.

Maintainability is the ease with which a product can be maintained.

AIM: - SRS document for given project. (IEEE Standard)

Android Base Attendance

Prepared by NIRAV C. PANSURIYA, JAIMIL PATEL, KEVAL PATEL

THE LIZARD SOLUTION

2nd October 2018

Date Version Description Updated By

2nd October 2018 1.0 Initial Draft The Lizard Solution

Intended Audience and Reading Suggestions

User Classes and Characteristics

 Android (Version Grater Then 6.0)

Design and Implementation Constraints

User Manual will be delivered at the time of installation of product.

Assumptions and Dependencies

External Interface Requirements

4.1.1 Description and Priority

4.2.1 Description and Priority

4.2.1 Description and Priority

Other Nonfunctional Requirements

Software Required: COSTAR/SYSTEM STAR Tool

Knowledge Required: Number of inputs, outputs, records, inquires to the projects.

Size-oriented software metrics are derived by normalizing quality and/or productivity

Parameters Count Simple Average Complex Total

Function Point is: 60.14

Software Project Type

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Effort = ab*(KLOC) ^bb

Advantage/Disadvantage: Size oriented metrics is based on the simple fact of LOC or