Practical File On Software Engineering

SUBMITTED TO :Prof. vikas sejwaL Prof. Y.P.SINGH

SUBMITTED BY:SUNAI NA SINGH IT-09052 it 3rd year

Index

S No.

Contents

Page no.

1)

Project selection and planning A)Analyze given system B) Develop the system C) Deliver the system

2)

Create the SRS document.

3) 4)

Software developmental model Introduction to UML and use case diagram.

9 13

5)

System modeling.

14

6)

Estimate the cost of project using software project planning.

17

7)

User interface design.

20

9)

Create the document for different types of testing.

22

10)

Technical metrics for software.

27

Project Selection and Planning

a) Analyze given system-:
Communication is a natural human need. Man being a social animal wishes to stay connected with friends both far and near. At a time people wrote letters to each other which have now almost replaced by telephone calls, sms services and emails which are faster and more efficient way of communication. Latest addition to this list are social networking websites which provide an individual a completely new way to interact with both known and unknown people. On one hand where these websites are becoming extremely popular with people all over the world, there are a few people on the other hand who lament over the amount of information being shared through these websites.

Thus we can sum up the problem of existing systems are as follows:

Letters which at a time most popular way of communication and cheap are too slow and there is always a chance of them being lost or damaged. Telephone calls over long distances are very expensive. One cannot make calls very frequently over long distances to inform about day to day activities if one wishes to. Some people are not comfortable with the amount of information being shared on social networking websites in use today. This section includes people who only wish to communicate with their group of friends and dont want to be disturbed by other people. Sometimes people also wish to share the text and other information only with their friends without any intrusion from others.

b) Develop the System Envisioned System:

This part of project report describes the actual system which is being designed through this project. Based on key findings, a new system has been proposed. System will enable people who wish to communicate only with their group of friends but simultaneously. None of the information would be available to any other user unless both are friends. The website will be used by the two different types of users: 1. Customers 2. Administrator

c) Deliver the System: Completely personalized as per the user. Convenient and easy to use. Flexible Time Saver

Security

Create the Software Requirement specifications (SRS) document.

1) Purpose:The main purpose of this project is designing a website interface which will enable customers to: Create a friend list which includes people as per their wish and edit it when required. Enable people to share picture and other text with their friends. Send message to their friends and reply to the received messages Search a person or acquaintance with his/her name or email id as keyword . 2) Scope:This social networking websites will be used by two different types of users: 1. Customers 2. Administrator Customers have full time access and will be allowed to log in anytime registering once with website. But any customer or employee will have full access to search any category of movie without login and registration.

3)Features:
Secure: Use of .NET technology as programming language ensures security of website. To enhance security features of login-password authentication and web.xml features have been rendered. Easy To Use: PALSPACE provides very user friendly environment as well as very interactive and attractive features. Easy transaction Facility: Users can directly deduct required amount without even being queued at bank.

Software Developmental model used :

We have used the oldest model for software designing i.e. Iterative Waterfall model. The Iterative waterfall model consists of following steps. A brief introduction of the steps and their sequence is given below.

Iterative Waterfall Model

Feasibility: Defining a preferred concept for the software product, and determining its lifecycle feasibility and superiority to alternative concepts. Requirements: A complete, verified specification of the required functions, interfaces, and performance for the software product. Product Design: A complete verified specification of the overall hardware-software architecture, control structure, and data structure for the product, along with such other necessary components as draft user's manuals and test plans. Detailed Design: A complete verified specification of the control structure, data structure, interface relations, sizing, key algorithms, and assumptions of each program component. Coding: A complete, verified set of program components. Integration: A properly function software product composed of the software components. Implementation: A fully functioning operational hardwaresoftware system, including such objectives

as program and data conversion, installation, and training. Maintenance: A fully functioning update of the hardwaresoftware system repeated for each update. Phase out: A clean transition of the functions performed by the product to its successors.

Now the steps which we have followed in our implementation of the Iterative waterfall model are as follows:

Feasibility:

Interviewed the existing users of the system to know their expectations and also the problems they are facing with the existing system. Also asked customers about their expectations and the problems they are having with the existing system.

Requirements:

Decided about the requirements of the system. Decided that the system should be designed in Java because security and network implementation is the basic

requirement. Also decided that the system should be 3 tier software and implemented in a way so that it put minimum load on the network.

Product Design: Decided about the hardware of the system

(which will be the existing network) .Decided about all the 3 layers of the system, what functionality has to be put on which layer. Also decided the basic flow of system, different screens of the system and also the data structure.

Detailed Design: Designed complete architecture for the code

to be generated, Decided about the classes their attributes and methods. The inheritance hierarchy, ER diagram of the system, the validations to be performed, the data which will be transferred across network and also the basic classes of java which will be used for designing the code.

Coding:

Coded the complete system using java as main programming language and JSP to designed front end.

Integration:

Attached the complete java code together the client part, the server part and also the middle layer.. Also designed the JSP front end to make the system look more attractive.

Implementation: Installed the software on server and

configured the clients to make them work with the server(Apache Tomcat 5.5), by changing the port number(80). Also created all the tables on the database server(Oracle) and assigned them proper permissions. Deploy the software on the server and also configured the middle layer of the system.

Maintenance:

Made sure the system is functioning properly by using different test cases at different time.

Introduction to UML and Use case Diagram-:

UML-UML sequence diagrams
are used to show how objects interact in a given situation. An important characteristic of a sequence diagram is that time passes from top to bottom: the interaction starts near the top of the diagram and ends at the bottom .A popular use for them is to document the dynamics in an object-oriented system. There are three classifications of UML diagrams:

Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams. Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams. Structure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams.

Use case Diagram-:

A use case diagram depicts actors, use cases, and the relationships among them with some simple extensions, use case diagrams can be used to represent a usability professional's task model. A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted.Use Case diagrams are formally included in two modeling languages: 1)Unified Modeling Language (UML) 2) Systems Modeling Language (SysML).

System modeling.
System modeling is a technique to express, visualize, analyze and transform the architecture of a system. Here a system may consist of software components, hardware components, or both and the connections between these components. System modeling is intended to assist in developing and maintaining large systems with emphasis on the construction phase. The idea is to encapsulate complex or changeable aspects of a design inside separate components with well-defined interfaces indicating how each component interacts with its environment. System modeling can increase reliability and reduce development cost by making it easier to build systems, to reuse previous built components within new systems, to change systems to suit changing requirements such as functional enhancement and platform changes, and to understand systems. In this way, a system model can satisfy different requirements such as documenting the system, providing a notation for tools such as consistency checkers and can also be used in the design stage of system development. Thus, system modeling is used to ensure that a developing piece of software evolves in a consistent manner and that the task of integrating software components is simplified. Modeling framework and language For system modeling, we need a conceptual framework and a system modeling language, textual and/or diagrammatic. Besides textual notations like tables or prose, diagrammatic notations like graphs are common today. Within these diagrams, there are symbols representing the parts of the system, e.g. objects and groups of objects, and other symbols visualizing the connections between these parts. The number of symbols for each purpose differs noticeably between notations.

During the past decades four main conceptual frameworks have evolved: Design Methods Module Interconnection Languages (MILs) Software Architectures Design Patterns Design methods focusing on program language modules date back to the early seventies; modelling systems with objects is a technique of the late eighties. The first MIL was presented 1975, and in the following years a lot of different MILs have been developed. In contrast, software architectures and design patterns are more recent techniques and are each only about five years old. Design methods Design methods consist of a concept, a language, and a design process. The concept defines which parts of the program are to be represented by the components of the system model. The language is used to describe the system model. To carry out the design of the system according to the software lifecycle or a part of it, a step-by-step process is given to be followed by the designer. When modelling a system with a modular design method, program modules are used as the components of which the system is composed. Modules include related functions of a specific program language and may keep the data used by these functions. Further, a module offers an interface with the functions that may be used from this module. An interrelationship between two modules is established by a function contained in one module calling a function contained in another. Thus, this modelling method describes systems in terms of function calls and composition of modules containing functions.

Object-oriented design methods, on the other hand, do not focus on the functional aspect. An object component includes data and functions. These functions constitute an external interface, and represent the only possibility2 to manipulate and/or access the data within an object. Another type of components are classes, which serve as templates from which objects can be instantiated, i.e. derived. The connections between the objects of a system model are manifold, e.g. instantiation of an object from a class, composition, and use. Interacting objects often are not viewed as calling each others functions, but requesting each other via messages to perform a desired action on their data. An object is responsible that its representation is hidden from other objects. Thus, the object-oriented modelling method adds behaviour over a mere structural solution. Module Interconnection Languages Creating program modules and connecting them to form large systems are different design efforts. Module interconnection languages (MILs) are means to support the connection effort of large systems. A MIL is separate and distinct from an implementation language. Its purpose is to formally express the system designers intent regarding system structure. In the absence of a MIL, this information is buried within the implementation language modules, linker commands and informal documentation; thus, the information is scattered, unreliable and doesnt enforce connectivity.

The main features of MILs are: a separate language to describe the system, static intermodule type checking, design and construction information in a single description, and version control.

Estimate the cost of project using software project planning-:

Cost estimating is one of the most important steps in project management. A cost estimate establishes the base line of the project cost at different stages of development of the project. A cost estimate at a given stage of project development represents a prediction provided by the cost engineer or estimator on the basis of available data. According to the American Association of Cost Engineers, cost engineering is defined as that area of engineering practice where engineering judgment and experience are utilized in the application of scientific principles and techniques to the problem of cost estimation, cost control and profitability. Virtually all cost estimation is performed according to one or some combination of the following basic approaches: Production function. In microeconomics, the relationship between the output of a process and the necessary resources is referred to as the production function. In construction, the production function may be expressed by the relationship between the volume of construction and a factor of production such as labor or capital. A production function relates the amount or volume of output to the various inputs of labor, material and equipment. For example, the amount of output Q may be derived as a function of various input factors x1, x2, ..., xn by means of mathematical and/or statistical methods. Thus, for a specified level of output, we may attempt to find a set of values for the input factors so as to minimize the production cost. Empirical cost inference. Empirical estimation of cost functions requires statistical techniques which relate the cost of constructing or operating a facility to a few important characteristics or attributes of the system. The role of statistical inference is to estimate the best parameter values or constants in an assumed cost function. Usually, this is accomplished by means of regression analysis techniques.

 Allocation of joint costs. Allocations of cost from existing accounts may be used to develop a cost function of an operation. The basic idea in this method is that each expenditure item can be assigned to particular characteristics of the operation. Ideally, the allocation of joint costs should be causally related to the category of basic costs in an allocation process. In many instances, however, a causal relationship between the allocation factor and the cost item cannot be identified or may not exist. For example, in construction projects, the accounts for basic costs may be classified according to (1) labor, (2) material, (3) construction equipment, (4) construction supervision, and (5) general office overhead. These basic costs may then be allocated proportionally to various tasks which are subdivisions of a project.

Cocomo model
COCOMO is one of the most widely used software estimation models in the world It was developed by Barry Boehm in 1981 COCOMO predicts the effort and schedule for a software product development based on inputs relating to the size of the software and a number of cost drivers that affect productivity COCOMO has three different models that reflect the complexity: the Basic Model the Intermediate Model and the Detailed Model Basic COCOMO Model: Formula E=ab (KLOC or KDSI) bb D=cb (E) db P=E/D

where E is the effort applied in person-months, D is the development time in chronological months, KLOC / KDSI is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db are given in next slide.

Software project ab Organic Semi-detached Embedded 2.4 3.0 3.6

bb

cb

db
0.38 0.35 0.32

1.05 2.5 1.12 2.5 1.20 2.5

Effort Effort indicators allow the software manager to track personnel resources. They provide visibility into the contribution of staffing to project costs, schedule adherence, product quality and the amount of effort required for each activity. Effort indicators include trends in actual staffing levels, staffing profile by activity or labor category, or a profile of unplanned staff loses. Cost Cost management is an important activity for the success of a project, and labor is the primary component of software development cost. Managers must define the work in their area, determine the skill level required to perform the work, and use productivity estimates and schedule constraints to determine budgeted costs over time. Source Lines-of-Code Estimates Most SLOC estimates count all executable instructions and data declarations but exclude comments,blanks, and continuation lines. SLOC can be used to estimate size through analogy by comparing the new softwares functionality to similar functionality found in other historic applications.

Obviously, having more detailed information available about the functionality of the new software provides the basis for a better comparison. In theory, this should yield a more credible estimate. The relative simplicity of the SLOC size measure facilitates automated and consistent (repeatable) counting of actual completed software size. It also enables recording size data needed to prepare accurate estimates for future efforts. The most significant advantage of SLOC estimates is that they directly relate to the software to be built. The software can then be measured after completion and compared with your initial estimates.

Function Point Size Estimates Function points, as defined by A.J. Albrecht, are the weighted sums of five different factors that relate to user requirements: Inputs, Outputs, Logic (or master) files, Inquiries, and Interfaces. Feature Point Size Estimates A derivative of function points, feature points were developed to estimate/measure real-time System software with high algorithmic complexity and generally fewer inputs/outputs than MISs. Algorithms are sets of mathematical rules expressed to solve significant computational problems. For example, a square root extraction routine, or a Julian date conversion routine, are algorithms.

User Interface Design-:

To suggest some general design principles for user interface design To explain different interaction styles To introduce styles of information presentation To introduce usability attributes and system approaches to system evaluation System users often judge a system by its interface rather than its functionality A poorly designed interface can cause a user to make catastrophic errors Poor user interface design is the reason why so many software systems are never used most users of business systems interact with these systems through graphical user interfaces (GUIs)In some cases, legacy text-based interfaces are still used.

Analyse and understand user activities

Produce paperbased design prototype

Evaluate design with end-users

Design prototype

Produce dynamic design prototype

Evaluate design with end-users

Executable prototype

Implement final user interface

UI design principles
User familiarity The interface should be based on user-oriented terms and concepts rather than computer concepts E.g., an office system should use concepts such as letters, documents, folders etc. rather than directories, file identifiers, etc. Consistency The system should display an appropriate level of consistency Commands and menus should have the same format, command punctuation should be similar, etc. Minimal surprise If a command operates in a known way, the user should be able to predict the operation of comparable commands Recoverability The system should provide some resilience to user errors and allow the user to recover from errors This might include an undo facility, confirmation of destructive actions, 'soft' deletes, etc. User guidance Some user guidance such as help systems, on-line manuals, etc. should be supplied

User diversity Interaction facilities for different types of user should be supported E.g., some users have seeing difficulties and so larger text should be available

User Interface Design Models User modela profile of all end users of the System Design modela design realization of the user Model Mental model (system perception)the users mental image of what the interface is Implementation modelthe interface look and feel coupled with supporting information that describe interface syntax and semantics.

Create the Document For Different Type Of Testing-:

Software Testing is the process of executing a program or system with the intent of finding errors.Or, it involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results.Software is not unlike other physical processes where inputs are received and outputs are produced. Where software differs is in the manner in which it fails. Most physical systems fail in a fixed (and reasonably small) set of ways. By contrast, software can fail in many bizarre ways. Detecting all of the different failure modes for software is generally infeasible. Testing is used for

To improve quality. For Verification & Validation (V&V) For reliability estimation

Correctness testing
Correctness is the minimum requirement of software, the essential purpose of testing. Correctness testing will need some type of oracle, to tell the right behavior from the wrong one. The tester may or may not know the inside details of the software module under test, e.g. control flow, data flow, etc. Therefore, either a white-box point of view or black-box point of view can be taken in testing software. We must note that the black-box and white-box ideas are not limited in correctness testing only.

Black-box testing

The black-box approach is a testing method in which test data are derived from the specified functional requirements without regard to the final program structure. It is also termed data driven, input/output driven or requirements-based testing. Because only the functionality of the software

module is of concern, black-box testing also mainly refers to functional testing -- a testing method emphasized on executing the functions and examination of their input and output data.The tester treats the software under test as a black box only the inputs, outputs and specification are visible, and the functionality is determined by observing the outputs to corresponding inputs. In testing, various inputs are exercised and the outputs are compared against specification to validate the correctness. All test cases are derived from the specification. No implementation details of the code are considered. It is obvious that the more we have covered in the input space, the more problems we will find and therefore we will be more confident about the quality of the software. Ideally we would be tempted to exhaustively test the input space. But as stated above, exhaustively testing the combinations of valid inputs will be impossible for most of the programs, let alone considering invalid inputs, timing, sequence, and resource variables. Combinatorial explosion is the major roadblock in functional testing. To make things worse, we can never be sure whether the specification is either correct or complete. Due to limitations of the language used in the specifications (usually natural language), ambiguity is often inevitable. Even if we use some type of formal or restricted language, we may still fail to write down all the possible cases in the specification. Sometimes, the specification itself becomes an intractable problem: it is not possible to specify precisely every situation that can be encountered using limited words. Good partitioning requires knowledge of the software structure. A good testing plan will not only contain black-box testing, but also white-box approaches, and combinations of the two.

White-box testing

Contrary to black-box testing, software is viewed as a white-box, or glass-box in white-box testing, as the structure and flow of the software under test are visible to the tester. Testing plans are made according to the details of the software implementation, such as programming language, logic, and styles. Test cases are derived from the program structure. White-box testing is also called glass-box testing, logic-driven testing or design-based testing. There are many techniques available in white-box testing, because the problem of intractability is eased by specific knowledge and attention on the structure of the software under test. The intention of exhausting some aspect

of the software is still strong in white-box testing, and some degree of exhaustion can be achieved, such as executing each line of code at least once (statement coverage), traverse every branch statements (branch coverage), or cover all the possible combinations of true and false condition predicates (Multiple condition coverage). Control-flow testing, loop testing, and data-flow testing, all maps the corresponding flow structure of the software into a directed graph. Test cases are carefully selected based on the criterion that all the nodes or paths are covered or traversed at least once. By doing so we may discover unnecessary "dead" code -- code that is of no use, or never get executed at all, which can not be discovered by functional testing.

Performance testing
Not all software systems have specifications on performance explicitly. But every system will have implicit performance requirements. The software should not take infinite time or infinite resource to execute. "Performance bugs" sometimes are used to refer to those design problems in software that cause the system performance to degrade. Performance has always been a great concern and a driving force of computer evolution. Performance evaluation of a software system usually includes: resource usage, throughput, stimulus-response time and queue lengths detailing the average or maximum number of tasks waiting to be serviced by selected resources. Typical resources that need to be considered include network bandwidth requirements, CPU cycles, disk space, disk access operations, and memory usage. The goal of performance testing can be performance bottleneck identification, performance comparison and evaluation, etc. The typical method of doing performance testing is using a benchmark -- a program, workload or trace designed to be representative of the typical system usage.

Reliability testing
Software reliability refers to the probability of failure-free operation of a system. It is related to many aspects of software, including the testing process. Directly estimating software reliability by quantifying its related factors can be difficult. Testing is an effective sampling method to measure software reliability. Guided by the operational profile, software testing (usually black-

box testing) can be used to obtain failure data, and an estimation model can be further used to analyze the data to estimate the present reliability and predict future reliability. Therefore, based on the estimation, the developers can decide whether to release the software, and the users can decide whether to adopt and use the software. Security testing Software quality, reliability and security are tightly coupled. Flaws in software can be exploited by intruders to open security holes. With the development of the Internet, software security problems are becoming even more severe. Many critical software applications and services have integrated security measures against malicious attacks. The purpose of security testing of these systems include identifying and removing software flaws that may potentially lead to security violations, and validating the effectiveness of security measures. Simulated security attacks can be performed to find vulnerabilities. Testing automation Software testing can be very costly. Automation is a good way to cut down time and cost. Software testing tools and techniques usually suffer from a lack of generic applicability and scalability. The reason is straight-forward. In order to automate the process, we have to have some ways to generate oracles from the specification, and generate test cases to test the target software against the oracles to decide their correctness. Today we still don't have a fullscale system that has achieved this goal. In general, significant amount of human intervention is still needed in testing. The degree of automation remains at the automated test script level. Beta testing Testing typically done by end-users or others. Final testing before releasing application for commercial purpose. The development process involves various types of testing. Each test type addresses a specific testing requirement. The most common types of testing involved in the development process are: Unit Test. System Test

 Integration Test Functional Test Performance Test Beta Test Acceptance Test. Unit Test The first test in the development process is the unit test. The source code is normally divided into modules, which in turn are divided into smaller units called units. These units have specific behavior. The test done on these units of code is called unit test. Unit test depends upon the language on which the project is developed. Unit tests ensure that each unique path of the project performs accurately to the documented specifications and contains clearly defined inputs and expected results. System Test Several modules constitute a project. If the project is long-term project, several developers write the modules. Once all the modules are integrated, several errors may arise. The testing done at this stage is called system test. Functional Test Functional test can be defined as testing two or more modules together with the intent of finding defects, demonstrating that defects are not present, verifying that the module performs its intended functions as stated in the specification and establishing confidence that a program does what it is supposed to do.

Technical metrics for Software-:

Software metrics are numerical data related to software development. Metrics strongly support software project management activities. They relate to the four functions of management as follows: Planning Metrics serve as a basis of cost estimating, training planning, resource planning, scheduling, and budgeting. Organizing Size and schedule metrics influence a project's organization. Controlling Metrics are used to status and track software development activities for compliance to plans.

Measure
quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process.e.g., Number of errors Indicator The term indicator is used to denote a representation of metric data that provides insight into an ongoing software development project or process improvement activity. Indicators are metrics in a form suitable for assessing project behavior or process improvement. Indicators are used in conjunction with one another to provide a more complete picture of project or organization behavior. For example, a progress indicator is related to requirements and size indicators. All three indicators should be used and interpreted together.

 Metrics Set
The metrics to be collected provide indicators that track ongoing project progress, software products, and software development processes. defined indicators are consistent with the Software Engineering Institute's Capability Maturity Model (CMM). Table 1 shows the indicator categories, the management insight provided, and the specific indicators for recommended metrics. Depending upon the nature of the project, specific contractual requirements, or management preference, a project may choose to collect additional metrics or to tailor the recommended set. Metric Classification Products Explicit results of software development activities Deliverables, documentation, by products Processes Activities related to production of software Resources Inputs into the software development activities hardware, knowledge, people Process Metrics Insights of process paradigm, software engineering tasks, work product, or milestones Lead to long term process improvement Product Metrics Assesses the state of the project Track potential risks Uncover problem areas Adjust workflow or tasks Evaluate teams ability to control quality Types of Measures Direct Measures (internal attributes) Cost, effort, LOC, speed, memory Indirect Measures (external attributes) Functionality, quality, complexity, maintainability

efficiency,

reliability,

Size-Oriented Metrics Size of the software produced LOC - Lines Of Code KLOC - 1000 Lines Of Code SLOC Statement Lines of Code (ignore whitespace) Typical Measures: Errors/KLOC, Defects/KLOC, Cost/LOC, Pages/KLOC

Documentation