Professional Documents
Culture Documents
Practical: 1: Dr. Subhash Technical Campus
Practical: 1: Dr. Subhash Technical Campus
PRACTICAL: 1
AIM: SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
Definition: Software life cycle models describe phases of the software cycle and the order in
which those phases are executed. Each phase produces deliverables required by the next
phase in the life cycle. The Systems Development Life Cycle (SDLC), or Software
Development Life Cycle in systems engineering, information systems and software
engineering, is the process of creating or altering systems, and the models and methodologies
that people use to develop these systems.
1) System Planning : The Planning phase is the most crucial step in creating a
successful system, during this phase you decide exactly what you want to do and the
problems you are trying to solve by:
Defining the problems, the objectives and the resources such as personnel and
costs.
Studying the ability of proposing alternative solutions after meeting with
clients, suppliers, consultants and employees.
Studying how to make your product better than your competitors.
After analyzing this data you will have three choices: develop a new system,
improve the current system or leave the system as it is.
feasibility study will be made for the project as well, involving determining whether
it’s organizationally, economically, socially, technologically feasible. It is very
important to maintain strong communication level with the clients to make sure you
have a clear vision of the finished product and its function.
3) System Design: The design phase comes after a good understanding of customer’s
requirements; this phase defines the elements of a system, the components, the
security level, modules, architecture and the different interfaces and type of data that
goes through the system.
A general system design can be done with a pen and a piece of paper to
determine how the system will look like and how it will function, and then a detailed
and expanded system design is produced, and it will meet all functional and technical
requirements, logically and physically.
OUTCOMES:
After complete these experiments I have learn what is software development life cycle.
I learn the different phases of the software development life cycle.
I learn what working of each phases of software development life cycle.
I learn how to actual develop the software.
PRACTICAL: 2
AIM: PROJECT SCHEDULING & TRACKING, RISK
ANALYSIS.
Project Scheduling:
Project Scheduling in a project refers to roadmap of all activities to be done with specified
order and within time slot allotted to each activity. Project managers tend to define various
tasks, and project milestones and they arrange them keeping various factors in mind. They
look for tasks lie in critical path in the schedule, which are necessary to complete in specific
manner (because of task interdependency) and strictly within the time allocated.
tasks in the project work breakdown structure (WBS) that determine the project
duration time.
Timeline (Gantt) charts enable software planners to determine what tasks will be need
to be conducted at a given point in time (based on estimates for effort, start time, and
duration for each task).
The best indicator of progress is the completion and successful review of a defined
software work product.
Time-boxing is the practice of deciding a priori the fixed amount of time that can be
spent on each task. When the task's time limit is exceeded, development moves on to
the next task (with the hope that a majority of the critical work was completed before
time ran out).
Task set for project planning:-
Task Network:-
Task network
graphic representation of the task flow for a project;
depicts major new tasks
Take into consideration
task interdependencies
parallel tasks
critical path tasks
Project Risk:-
Technical Risk:-
Technical risks threaten the quality and timeliness of the software to be produced.
If a technical risk becomes a reality, implementation may become difficult or
impossible.
Technical risks identify potential design, implementation, interface, verification,
and maintenance problems.
In addition, specification ambiguity, technical uncertainty, and 3leading4edge3
technology are also risk factors.
Business Risk:-
Known Risk:-
Known risks are those that can be uncovered after careful evaluation of the project
plan, the business and technical environment in which the project is being
developed.
Other reliable information sources (e.g., unrealistic delivery date, lack of
documented requirements or software scope, poor development environment).
Predictable Risk:-
Predictable risks are generalized from past project e1perience (e.g., staff turnover,
poor communication with the customer, etc).
Unpredictable risks are the joker in the deck. They can and do occur, but they are
e1tremely difficult to identify in advance.
Reactive Risk Management:-
Project team reacts to risks when they occur.
More commonly, the software team does nothing about risks until something goes
wrong.
Then, the team involved into action in an attempt to correct the problem rapidly.
This is often called a fire fighting mode.
When this fails, crisis management! takes over and the project is in real jeopardy.
OUTCOMES:
After complete these experiments I have learnt about project scheduling and project
tracing.
I have learnt the the risk analysis and different types of risks and risk management.
I have learnt about all the basic tokens of coding.
PRACTICAL: 3
AIM: ANALYSIS OF SOFTWARE CODING AND STANDARD
1. Coding Standards:
General coding standards pertain to how the developer writes code. The SISEPG
has come up with a small set of items it feels should be followed regardless of the
programming language being used.
Indentation :
Proper and consistent indentation is important in producing easy to read and
maintainable programs. Indentation should be used to:
o Emphasize the body of a control statement such as a loop or a select
statement
o Emphasize the body of a conditional statement
o Emphasize a new scope block
Examples:
/* Indentation used in a loop construct. Four spaces are used for
indentation. */
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.
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.
Use of Braces
In some languages, braces are used to delimit the bodies of conditional statements,
control constructs, and blocks of scope.
Compiler Warnings
Compilers often issue two types of messages: warnings and errors. Compiler
warnings normally do not stop the compilation process. However, compiler errors
do stop the compilation process, forcing the developer to fix the problem and
recompile.
Compiler and linker warnings shall be treated as errors and fixed. Even though the
program will continue to compile in the presence of warnings, they often indicate
problems which may affect the behavior, reliability and portability of the code.
2. Coding Guidelines
General coding guidelines provide the programmer with a set of best practices which
can be used to make programs easier to read and maintain. Unlike the coding
standards, the use of these guidelines is not mandatory. However, the programmer is
Line Length
It is considered good practice to keep the lengths of source code lines at or below 80
characters. Lines longer than this may not be displayed properly on some terminals
and tools. Some printers will truncate lines longer than 80 columns. FORTRAN is
an exception to this standard. Its line lengths cannot exceed 72 c
Spacing
The proper use of spaces within a line of code can enhance readability. Good rules
of thumb are as follows:
o A keyword followed by a parenthesis should be separated by a space.
o A blank space should appear after each comma in an argument list.
o All binary operators except “.” should be separated from their operands by
spaces. Blank spaces should never separate unary operators such as unary
minus, increment (“++”), and decrement(“—“) from their operands.
o Casts should be made followed by a blank space.
Wrapping Lines
When an expression will not fit on a single line, break it according to these following
principles:
o Break after a comma
Variable Declarations
Variable declarations that span multiple lines should always be preceded by a type.
Example:
Acceptable:
int price , score ;
Acceptable:
int price ;
int score ;
Not Acceptable:
int price ,
score ;
Program Statements
Program statements should be limited to one per line. Also, nested statements
should be avoided when possible.
Use of Parentheses
Inline Comments
Inline comments promote program readability. They allow a person not familiar
with the code to more quickly understand it. It also helps the programmer who
wrote the code to remember details forgotten over time. This reduces the amount of
time required to perform software maintenance tasks.
There are many aspects to programming. These include writing software that runs
efficiently and writing software that is easy to maintain. These two goals often
collide with each other. Creating code that runs as efficiently as possible often
means writing code that uses tricky logic and complex algorithms, code that can be
hard to follow and maintain even with ample inline comments.
Software modules and methods should not contain an excessively large number of
lines of code. They should be written to perform one specific task. If they become
too long, then chances are the task being performed can be broken down into
subtasks which can be handled by new routines or methods.
It is much easier to sort through code you did not write and you have never seen
before if there are a minimal number of routines per file. This is only applicable to
procedural languages such as C and FORTRAN. It does not apply to C++ and Java
OUTCOMES:
After complete these experiments I have learnt how to code in any languages.
I have learnt the different coding standards, guidelines and compiler warning when
executing the code.
I have learnt about all the basic tokens of coding.
PRACTICAL: 4
AIM: SOFTWARE QUALITY ASSURANCE
Importance of SQA:
Quality control and assurance are essential activities for any business that produces
products to be used by others.
Prior to the twentieth century, quality control was the sole responsibility of the
craftsperson who built a product.
As time passed and mass production techniques became commonplace, quality control
became an activity performed by people other than the ones who built the product.
Software quality assurance starts from the beginning of a project, right from the analysis
phase.
SQA checks the adherence to software product standards, processes, and procedures.
SQA includes the systematic process of assuring that standards and procedures are
established and are followed throughout the software development life cycle and test
cycle as well.
The compliance of the built with agreed-upon standards and procedures is evaluated
through process monitoring, product evaluation, project management etc.
The major reason of involving software quality assurance in the process of software
product development is to make sure that the final product built is as per the
requirement specification and comply with the standards.
SQA Activities:
The plan is developed as part of project planning and is reviewed by all stakeholders.
Quality assurance actions performed by the software engineering team and the SQA
group are governed by the plan.
The SQA group reviews the process description for compliance with organizational
policy, internal software standards, externally imposed standards, and other parts of the
software project plan.
Review software engineering activities to verify compliance with the defined software
process:
The SQA group identifies, documents, and tracks deviations from the process and verifies
that corrections have been made.
Audit designated software work products to verify compliance with those defined as
part of the software process:
The SQA group reviews selected work products; identifies, documents, and tracks
deviations; verifies that corrections have been made; and periodically reports the results
of its work to the project manager.
Ensure that deviations in software work and work products are documented and
handled according to a documented procedure:
SQA Techniques:
Data Collection:
OUTCOMES:
After complete these experiments I have learnt about the quality and assurance of
software.
I have learnt the importance of SQA, different SQA techniques and SQA activities.
I have learnt the steps about data collection.
PRACTICAL: 5
AIM: SOFTWARE MAINTENANCE
Definition:-
Corrective
Adaptive
Perfective
Preventive
Corrective Change
Adaptive Change
Perfective Change
Preventive Change
can have in the long term and helps it become scalable, stable, understandable and
maintainable.
The main aim of the software application maintenance is to correct the issues and
faults in the product and to improve its performance.
Whilst the common perception regarding the software maintenance is that it is just
meant to fix defects in an application, researches have shown that most of the time
it involves non-corrective actions.
Much like automobiles, the software applications also need timely maintenance in
order to make sure that they run smoothly and prevent of issues from occurring.
OUTCOMES:
After complete these experiments I have learnt about the software maintenance.
I have learnt about objectives and different types or categories of software
maintenance.
I have learnt the advantages of software maintenance.
PRACTICAL: 6
AIM: SOFTWARE ENGINEERING AND SOFTWARE
ENGINEERING SERVICES.
To indicate a Sequence:
Statement 1
Statement 2
To indicate "IF-THEN-ELSE":
if
True False
True
False
Case 1 Case n
OUTCOMES:
After complete these experiments I have learnt about the software Software
engineering and software engineering services.
I have learnt about basic path and graph.
PRACTICAL: 7
AIM: CASE STUDY FOR LIBRARY
4. Exploratory
Criteria or parameters instead of purpose
Example: Christopher Columbus’ voyage to the new world
Example: What do CMM level 3 organizations have in common?
Problem Statement:
The case study titled Library Management System is library management software for
the purpose of monitoring and controlling the transactions in a library. This case study
on the library management system gives us the complete information about the library
and the daily transactions done in a Library.
We need to maintain the record of new s and retrieve the details of books available in
the library which mainly focuses on basic operations in a library like adding new
member, new books, and up new information, searching books and members and
facility to borrow and return books.
The following are the brief description on the functions achieved through this case study:
End-Users:
Librarian: To maintain and update the records and also to cater the needs of the users.
Reader: Need books to read and also places various requests to the librarian.
Vendor: To provide and meet the requirement of the prescribed books.
1. Class diagram: These diagrams depict the behavioral pattern of the system, i.e. how each
and every class is inter-related to the other one, which relationship exists among each of the
classes, etc. There would be only one class diagram possible for a single system.
2. Use case diagram: Use case diagram comprises of use cases and actors such that there
would be various kinds of relationships among the use cases and the actors.
3. Activity diagram: This diagram denotes the structural flow of the activities in the form of
flow chart with decision boxes enhanced and hence is also used for troubleshooting like
raising exceptions when a particular action is done and the alternative to be done when
something abnormal is done.
Class Diagram
Classes identified:
Library
Librarian
Books Database
User
Vendor
OUTCOMES:
After complete these experiments I have learnt about case study and why we are using
case study.
I have learnt about different types or case study.
I have learnt the different types of class diagrams.
PRACTICAL: 8
AIM: EXAMPLES ON SOFTWARE ENGINEERING BASED
ON COCOMO MODEL.
Example:
Suppose that a project was estimate to be 400KLC. Calculate the efforts &
development time for each of the three models.D=Cb(E)db
1) Organic
2) Semidetached
3) Embedded
Solution:
The basic COCOMO equations take the form
E=ab(KLOC)bb
D=cb(E)db
E=2.4(400)1.05
E=1295.31 PM
D=2.5(1295.31)0.38
D=38.07 M
2) Semidetached mode:
E=3.4(400)1.12
E=2462.79 PM
D=2.5(2462.79)0.35
D=38.45 M
3) Embedded mode:
E=3.6(400)1.20
E=4772.81 PM
D=3.60(400)0.32
D=37.59 M
OUTCOMES :
After complete these experiments I have learnt about COCOMO Model.
I have learnt examples of COCOMO model and calculation of three modes of
COCOMO model.
PRACTICAL : 9
AIM : EXAMPLE OF COST ESTIMATION.
Software Measurement:
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
1) Productivity=FP/PM
2) Quality=Number of faults/FP
3) Cost=$/FP
4) Documentation=Pages of documentation/FP
Example: Study of requirement specification for ABC project has produced following
results.
Need for 7 inputs
10 outputs
6 inquiries
17 files
4 external interfaces
Input and external interface function point attributes are average complexity and all
other function points attributes are of low complexity.
Determine adjusted function points assuming complexity adjustment value is 32.
Solution:
7 inputs
10 outputs
6 inquiries
17 files
4 external interfaces
Adjusted function point value ∑(Fi)=32.
Let us calculate count total value:
Measurement Count Weighting Weighting Weighting
parameters factors factors factors
× Simple Average Complex
Input 7 × 4 28
Output 10 × 4 40
Inquiries 6 × 3 18
Files 17 × 7 119
Interfaces 4 × 7 28
Count FP =233
OUTCOMES :
After complete these experiments I have learnt about Software measurements.
I have learnt examples of Cost estimation.
PRACTICAL: 10
AIM : PREPARE SOFTWARE REQUIREMENT SPECIFICATION
(SRS).
1.1 Purpose :-
The clear understanding of the HMS and its’ functionality will allow for the correct
software to be developed for the end user and will be used for the development of the
future stages of the project.
This SRS will provide the foundation for the project. From this SRS, the HMS can be
designed, constructed, and finally tested.
1.2 Scope :-
1.3 Definition:-
End users – The people who will be actually using the system
1.3.1 Overview :-
The first is The Overall Description and the second is the Specific Requirements. The
Overall Description will describe the requirements of the HMS from a general high
level perspective.
The Specific Requirements section will describe in detail the requirements of the
system.
The system work on internet server, so it will operated by any end user for the buying
purpose.
2. General Description:-
3. Functional Requirement :-
3.1 Description :-
3.1.1 Registration:-
If customer wants to buy the product then he/she must be registered, unregistered user
can’t go to the shopping cart.
Customer logins to the system by entering valid user id and password for the
shopping.
3.1.3 Payment:-
For customer there are many type of secure billing will be prepaid as debit or credit
card, post paid as after shipping, check or bank draft. The security will provide by the
third party like Pay-Pal etc.
After the payment or surf the product the customer will logged out.
After all transaction the system can generate the portable document file (.pdf) and
then sent one copy to the customer’s Email-address and another one for the system
data base to calculate the monthly transaction .
This system will work on client-server architecture. It will require an internet server
and which will be able to run PHP application.
The system should support some commonly used browser such as IE etc.
4. Interface Requirement:-
The System must run over the internet, all the hardware shall require to connect
internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN,
Ethernet Cross-Cable.
All databases for the HMS will be configured using Oracle 8i. These databases
include hotel rooms and customers information. These can be modified by the end
users.
The room database will include the room numbers and if they are vacant or occupied.
The customers information database will contain all the information of the customer
such as first name, last name, number of occupants, assigned room, default room
rate(may be changed), phone number, whether or not the room is guaranteed, credit
card number, confirmation number, automatic cancellation date, expected check in
date and time, actual check in date and time, expected check out date and time,
amount owed by customer, and abbreviated customer feedback.
5. Performance Requirement:-
There is no performance requirement in this system because the server request and
response is depended on the end user internet connection.
6. Feasibility study:-
Depending on the results of the initial investigation the survey is now expanded to a
more detailed feasibility study.
First of all in the part of “technical feasibility” we study that weathers this software
project is technically feasible or not. Means to study that whether the necessary
software &hardware are available or not. Also study that weather the current software
project can be completed with the technology available in the company or in the
market or not. So, all these above factors are being considered in the study of
“technical feasibility”.
Here in the case of the software project of “HOTEL MANAGMENT” we have done
study on “technical feasibility” and we have derived several points as noted below:
o In these industry they already have computer with latest genuine Secondly they
configuration.
o Secondly they have either windows 98 or windows 2000 operating system in the
entire computer.
o Also they have to manage all the data & all the computers are on the network.
Economic justification is generally the “Bottom Line” consideration for most systems.
Economic justification includes a broad range of concerns that includes cost benefit
analysis. In this we weight the cost and the benefits associated with the candidate
system and if it suits the basic purpose of the organization i.e. profit making, the
project is making to the analysis and design phase.
The financial and the economic questions during the preliminary investigation are
verified to estimate the following:
o The cost of hardware and software for the class of application being considered.
7.1 Sequrity:-
The system use SSL (secured socket layer) in all transactions that include any
confidential customer information.
The system must automatically log out all customers after a period of inactivity.
The system should not leave any cookies on the customer’s computer containing the
user’s password.
The system’s back-end servers shall only be accessible to authenticated
administrators.
Sensitive data will be encrypted before being sent over insecure connections like the
internet.
7.2 Reliablity :-
The system provides storage of all databases on redundant computers with automatic
switchover.
The reliability of the overall program depends on the reliability of the separate
components. The main pillar of reliability of the system is the backup of the database
which is continuously maintained and updated to reflect the most recent changes.
Thus the overall stability of the system depends on the stability of container and its
underlying operating system.
7.3 Availability:-
The system should be available at all times, meaning the user can access it using a
web browser, only restricted by the down time of the server on which the system runs.
In case of a of a hardware failure or database corruption, a replacement page will be
shown. Also in case of a hardware failure or database corruption, backups of the
database should be retrieved from the server and saved by the administrator.
7.4 Maintainability:-
A commercial database is used for maintaining the database and the application server
takes care of the site.
In case of a failure, a re-initialization of the program will be done. Also the software
design is being done with modularity in mind so that maintainability can be done
efficiently.
7.5 Portability:-
The application is HTML and scripting language based. So The end-user part is fully
portable and any system using any web browser should be able to use the features of
the system, including any hardware platform that is available or will be available in
the future.
Waterfall Strengths :-
Waterfall Deficiencies :-
Reference sites:-
OUTCOMES:
After complete this experiment I have learnt how to prepare SRS document for any
project development.
I have learnt steps of SRS.