1

CONTENTS

S. No Name of the Experiment Page No

1 Project Planning 9

2 Software Requirement Analysis 13

3 Data Modeling and Implementation 18

4 Software Testing 26

5 Software Debugging 32

6 Database design

7 Screen Shots

2

List of Experiments

1) Project Planning

2) Software Requirement Analysis

3) Data Modeling and Implementation

4) Software Testing

5) Software Debugging

3

An Overview of Software Engineering

Definition of software engineering:

Software Engineering is the field of computer science dealing with the building of

software systems, which are so large or so complex that they are build by a team or teams of engineers. Software Engineering can be defined as “the application of engineering to

software”. IEEE definition:

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

The role of software engineering in system design:

A software system is often a component of a much large system. Therefore, the software engineering activity is a part of a much large system design activity.

o For example, a telephone-switching system. It consists of computers, telephone lines and cables, telephones, software to control the various components, and so on.

Software is being increasingly embedded in various systems.o The software engineer is required to participate in developing the requirements for the whole system.o The software engineer is required to understand the application area before thinking of developing software.

The relationship of software engineering to other area of computerScience:

Programming languageo Central tools used in software developmento Having influenced how well we can achieve our software engineering

goals Operating systems

o Software should usually run on a specific operating system.o Need to consider if the software can work well with a specific operating

System. Database

o Databases allow applications to be written that use data without worrying about the underlying representation of the data.o Allow database systems to be used as components of large software Systems.

4

Artificial intelligenceo Some researchers have been trying to apply artificial-intelligence Techniques.o To improve software engineering.

Theoretical modelso A number of models developed by theoretical computer science have become useful tool in software engineering.

The software life cycle: Software is said to have a life cycle composed of several phases. Traditional life cycle:

o waterfall model Each phase has well-defined starting and ending points, with clearly identifiable deliverables to the next phase

A sample waterfall life cycle model:o Requirements analysis and specification:

Usually the first phase of a large-scale software development Project.

Purpose of this phase is to identify and document the exact requirements for the system

o System design and specification: Software engineers design a software system to meet requirements. Sometime split into two sub-phases.

Architectural design: entails defining the overall organization of the system in terms of high-level components and interactions.

Detailed design: components are decomposed into lower level modules with precisely defined interfaces.

o Coding and module testing: The engineer produces the actual code that will be delivered to the

customer as the running system Individual modules developed in the coding phase are tested before being delivered to the next phase.

o Integration and system testing: All the modules having been developed before and tested

individually are put together-integrated-in this phase and are tested as a whole system.

o Delivery and maintenance: Once the system passes all

the tests, it is delivered to the customer and enters the maintenance phase. All modifications made to the

system after the initial delivery are usually attributed to this phase.

5

• Evolutionary models: Evolutionary model divides the development cycle into smaller,

incremental waterfall models in which users are able to get access to the product at the end of each cycle.

The users provide feedbacks on the product for the planning stage of the next cycle and the development team responds according to these feedbacks. Benefits:

o From a business perspective Significantly reducing the risk in software projects

by breaking the project into smaller, manageable pieces and by increasing the visibility of the management team in the project.

6

Spiral Modelo The goal of spiral model is to provide a framework for designing such processes, guided by the risk levels in the project at hando It can accommodate any process development model. By using it as a reference, one can choose any model that is the most appropriate, for example,waterfall model. The principal behind such a choice is the level of risk.o The main characteristic is that it is cycle each cycle consists of

four stages:

o The main characteristic is that it is cycleo Each cycle consists of four stages:

7

Stage 1:o Identifying the objectives of the portion of the product under consideration, in terms of qualities to achieveo Identifying alternatives, for example: if to buy or to reuse any softwareo Identifying constraints on the application of the alternatives

Stage 2:o Evaluating the alternatives identified in stage 1.o Identifying and dealing with the potential risk areas.

Stage 3:o Developing and verifying the next-level product.

Stage 4:o Reviewing the results of the stages traversed so far and planning for the next iteration of the spiral.

1 PROJECT PLANNING

Objective:

To gain understanding of plan and learn how to prepare them.

Background: Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality.

Study:

Project planning is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment.

Project Work PlanPrepare a list of all tasks in the work breakdown structure, plus:

Duration of task. Current task status. Task dependencies. Key milestone dates.

Tracking Progress: Gantt Chart:

o Bar chart format.o Useful to monitor project status at any point in time.

PERT Chart:

8

o Flowchart format.o Illustrate task dependencies and critical path.

Risk Management: Risk management is concerned with identifying risks and drawing up plans to

minimize their effect on a project. A risk is a probability that some adverse circumstance will occur. Project risks which affect schedule or resources. Product risks which affect the quality or performance of the software being

developed. Business risks which affect the organization developing the software.

Risk Management Process: Risk identification: identify project, product and business risks. Risk analysis: assess the likelihood and consequences of these risks. Risk planning: draw up plans to avoid or minimize the effects of the risk. Risk monitoring: monitor the risks throughout the project.

Project Planning A Step by Step :

Step 1: Project Goal:

A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project.

Step 2: Project Deliverables:

Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered.

Step 3: Project Schedule:

Create a list of tasks that need to be carried out for each deliverable identified in step2. For each task identify the following:

The amount of effort (hours or days) required to complete the task The resource who will carryout the task

Step 4 :Supporting Plans

Human Resource Plan

Identify by name the individuals and organisations with a leading role in the project. For each describe their roles and responsibilities on the project.

Communications Plan:

Create a document showing who needs to be kept informed about the project and how they will receive the information.

9

Risk Management Plan

Risk management is an important part of project management. Although often overlooked, it is important to identify as many risks to your project as possible and be prepared if something bad happens.

Inputs:

The following are the inputs for the project plan, Start or ending dates. List of tasks that need to be completed. Sub tasks and links for them. Create any links between major tasks. Specific amount time for each task. Assign resources for each task. Create task information for each item you put into the list.

Deliverables:

A complete plan for the entire project.

Example for project plan:

S.NOMILESTONE /

DELIVERABLE NAMEMILESTONE / DELIVERABLE

DESCRIPTION

TIMELINE(hrs)

01 Planing:Requirement definition document

The customer must be interviewed to understand & clearly record requirements

3

02Requirement analysis:Software requirement specification & test plan

Function, non-functional software & requirements are clearly recorded

5

03Design:High Level Deign

The flow of information between different modules is represented using DFD’, UML diagram & sequence diagram

4

04Data design:Database design

Select the database. Create the tables and define the fields in the appropriate tables.

1

05Interface design:User Interface Design

Using the selected language design the user interface so that it is conveniently used by all users

1

06 Implementation The code is written for the identified 10

10

functional requirements and linked with GUI and database. This must also be traceable to DFD’s and SRS.

07Testing:Unit Testing

Individual modules are tested by the programmer to verify the functionality.

3

08 Integration & System Testing

Integrate the tested individual modules and test if any errors have occurred and finally validation testing is done against the SRS

3

09 Document and help manualThe help manual is prepared in English for the beginners using the software

3

Viva Questions:

1) What is a project plan?

A. Project planning is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment.

2) What is risk management?

A. Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project.

3) What is called a milestone?

A. A milestone is the end of a stage that marks the completion of a work package or

phase, typically marked by a high level event such as completion, endorsement or signing

of a deliverable, document or a high level review meeting.

4)Give some examples for project risks.

A. Time and cost estimates too optimistic Customer review and feedback cycle too slow Unexpected budget cuts Unclear roles and responsibilities.

5) What is a project schedule?

A. A schedule consists of a list of a project's terminal elements with intended start and

finish dates. Terminal elements are the lowest element in a schedule, which is not further

11

subdivided. Those items are often estimated in terms of resource requirements, budget

and duration, linked by dependencies and scheduled.

12

2 SOFTWARE REQUIREMENT ANALYSISObjective:

To gain a deeper understanding of the Software Requirement Specification phase and to review the requirements engineering process.

Background A requirement is a statement of a behavior or attribute that a system must possess

for the system to be acceptable to a stakeholder.

Software Requirement Specification (SRS) is a document that describes the requirements of a computer system from the user's point of view.

Study:

Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.

Requirements analysis is critical to the success of a development project. Requirements must be documented, actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements can be functional and non-functional.

Requirements analysis includes three types of activity:

Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.

Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.

Recording requirements: Requirements might be documented in various forms, such as natural-language documents,use cases,user stories, or process specifications.

13

Requirements Engineering Process:Requirements engineering process consists of four phases:

Requirements elicitation: getting the customers to state exactly what the requirements are.

Requirements analysis: making qualitative judgments and checking for consistency and feasibility of requirements.

Requirements validation: demonstrating that the requirements define the system that the customer really wants.

Requirements management: the process of managing changing requirements during the requirements engineering process and system development, and identifying missing and extra requirements.

Writing Requirements: Requirements always need to be correct, unambiguous, complete, consistent, and testable.

Recommendations When Writing Requirements Never assume: others do now know what you have in mind. Use meaningful words; avoid words like: process, manage, perform, handle, and

support. State requirements not features:

o Feature: general, tested only for existence.o Requirement: specific, testable, measurable.

Avoid: o Conjunctions: ask yourself whether the requirement should it be split into

two requirements.o Conditionals: if, else, but, except, although.o Possibilities: may, might, probably, usually.

Writing Specifications:Specification is a description of operations and attributes of a system. It can be a document, set of documents, a database of design information, a prototype, diagrams or any combination of these things.

Specifications are different from requirements: specifications are sufficiently complete ─ not only what stakeholders say they want; usually, they have no conflicts; they describe the system as it will be built and resolve any conflicting requirements.

Creating specifications is important. However, you may not create specifications if: You are using a very incremental development process (small changes). You are building research or proof of concept projects. You rebuilding very small projects. It is not cheaper or faster than building the product.

14

Software Requirement Specification (SRS):

An SRS document specifies: The required behavior of a system in terms of: input data, required processing,

output data, operational scenarios and interfaces. The attributes of a system including: performance, security, maintainability,

reliability, availability, safety requirements and design constraints.

Remember that there is no “Perfect SRS”. However, SRS should be:

Correct: each requirement represents something required by the target system. Unambiguous: every requirement in SRS has only one interpretation Complete: everything the target system should do is included in SRS (no sections

are marked TBD-to be determined). Verifiable: there exists some finite process with which a person/machine can

check that the actual as-built software product meets the requirements. Consistent in behavior and terms. Understandable by customers. Modifiable: changes can be made easily, completely and consistently. Design independent: doesn't imply specific software architecture or algorithm. Concise: shorter is better. Organized: requirements in SRS are easy to locate; related requirements are

together. Traceable: each requirement is able to be referenced for later use (by the using

paragraph numbers, one requirement in each paragraph, or by using convention for indication requirements).

Inputs:

Complete problem definition. Clearly identified functional and non-functional requirements.

Project plan with milestones, timelines and deliverables.

Deliverables:

A detailed software requirement specification(SRS) document.

15

SRS document in IEEE format:

1) Introduction 1.1) Purpose 1.2) Scope 1.3)Abbreviations 1.4) References 1.5) Technologies

2) Overall Description 2.01) Product Perspective 2.02) Software Interface 2.03) Hardware Interface 2.04) Communication Interface 2.05) Product Function 2.06) User Characteristics 2.07) Constraints 2.08) Use-Case Model Survey 2.09) Architecture diagram 2.10) Database design 2.11) Assumptions and Dependencies

3) Specific Requirements 3.1) Use-Case Reports 3.2) Supplementary Requirement

Viva Questions:

1) What are the types of requirements?

A. Customer requirements. Functional requirements. Non – functional requirements. Performance requirements Design requirements. Derived requirements. Allocated requirements.

16

2) Differentiate functional and non-functional requirements.

A. Functional requirements explain what has to be done by identifying the

necessary task, action or activity that must be accomplished. Functional

requirements analysis will be used as the top level functions for functional

analysis.

Non-functional requirements are requirements that specify criteria that can be

used to judge the operation of a system, rather than specific behaviors.

3) What are the steps in requirement engineering?

A. Requirements Engineering can be divided into discrete chronological steps:

Requirements elicitation, Requirements analysis and negotiation, Requirements specification, System modeling, Requirements validation, Requirements management.

4) What is requirement management?

A. Requirements Engineering can be divided into discrete chronological steps:

Requirements elicitation, Requirements analysis and negotiation, Requirements specification, System modeling, Requirements validation, Requirements management.

5) Why is requirement management important?

A. Requirements management is important because, by organizing and tracking the

requirements and managing the requirement changes, you improve the chances of

completing the project on time and under budget. Poor change management is a key

cause of project failure.

17

3 DATA MODELING AND IMPLEMENTATION

Objective: To gain a deeper understanding of the data modeling which includes : entity-relationship diagram (ERD) and data flow diagram (DFD).

Background: Modeling consists of building an abstraction of reality. These abstractions are simplifications because they ignore irrelevant details and they only represent the relevant details (what is relevant or irrelevant depends on the purpose of the model).

Study:

Data modeling in software engineering is the process of creating a data model by applying formal data model descriptions using data modeling techniques.

Data modeling is a method used to define and analyze data requirements needed

to support the business processes of an organization. The data requirements are recorded

as a conceptual data model with associated data definitions. Actual implementation of the

conceptual model is called a logical data model. To implement one conceptual data

model may require multiple logical data models. Data modeling defines not just data

elements, but their structures and relationships between them.Data modeling techniques

and methodologies are used to model data in a standard, consistent, predictable manner in

order to manage it as a resource. The use of data modeling standards is strongly

recommended for all projects requiring a standard means of defining and analyzing data

within an organization, eg using data modeling:

to manage data as a resource; for the integration of information systems; for designing databases/data warehouses;

The Elements of the Analysis ModelThe generic analysis model consists of:

An entity-relationship diagram (data model). A data flow diagram (functional model). A state transition diagram (behavioral model).

18

Entity Relationship DiagramAn entity relationship diagram (ERD) is one means of representing the objects and their relationships in the data model for a software product.

Entity Relationship diagram notation:

Steps to create an ERD: Define “objects” by underlining all nouns in the written statement of scope:

producers/consumers of data, places where data are stored, and “composite” data items.

Define “operations” by double underlining all active verbs: processes relevant to the application and data transformations.

Consider other “services” that will be required by the objects. Then you need to define the relationship which indicates “connectedness”: a

"fact" that must be "remembered" by the system and cannot be or is not computed or derived mechanically.

Data Flow Diagram A data flow data diagram is one means of representing the functional model of a software product. DFDs do not represent program logic like flowcharts do.

Data flow diagram notation:

19

Entity

Relationship

External entity

Process

Data flow

Control flow

Data store

Data Flow Diagram Guidelines: All icons must be labeled with meaningful names. Always show external entities at level 0. Always label data flow arrows. Do not represent procedural logic. Each bubble is refined until it does just one thing.

Implementation: Implementation is the realization of an application, or execution of a plan

idea, model, design, specification, standard, algorithm, or policy. In computer science, an implementation is a realization of a technical

specification or algorithm as a program, software component, or other computer system.

Project implementation steps: Prepare the infrastructure. Analyze the problem and select suitable implementation language. Install the required servers and software needed for implementation. Select the appropriate data base Perform final verification Implement new processes and procedures. Monitor the solution.

Inputs:

Data Flow Diagram :

Isolated data objects and grammatical parse to determine operations.

External entities (producers and consumers of data).

Level 0 DFD “Context Diagram” (one single process).

The flow to maintain data flow continuity.

Entity Relationship Diagram:

Objects identified from the problem statement.

Operations that are relevant to the application and data transformations.

Services that will be required by the objects.

Relationship which indicates “connectedness”: a "fact" that must be

"remembered" by the system and cannot be or is not computed or derived

mechanically.

Deliverables:

20

Example for University ER Diagram:

21

Example for Banking DFD Diagram:

Cash Withdrawal:

Implementation Example Source code:

22

Private Sub cmdExit_Click()

    End

End Sub 

Private Sub cmdLogin_Click() 

    flag = True   

    If (txtUsername.Text = "") Then

        MsgBox "Enter a valid Username", vbCritical + vbOKOnly, "Error"

        flag = False

        txtUsername.SetFocus

    ElseIf (txtPassword.Text = "") Then

        MsgBox "Enter a valid Password", vbCritical + vbOKOnly, "Error"

        flag = False

        txtPassword.SetFocus

    End If

    If flag = True Then

        rs.Close

        rs.Open "Select Password from Login where Username = '" & txtUsername.Text & "'", con, adOpenDynamic, adLockOptimistic

       

        If rs.EOF = True Then 'If Search is found

            MsgBox "User not found", vbCritical + vbOKOnly, "Error"

        Else

23

            If (rs.Fields("Password") <> txtPassword.Text) Then

                MsgBox "Invalid Password", vbCritical + vbOKOnly, "Error"

                txtPassword.Text = ""

                txtPassword.SetFocus

            Else

                user = txtUsername.Text

                If (txtUsername.Text = "admin") Then

                    userAdmin = True

                Else

                    userAdmin = False

                End If

                frmMain.Show

                Unload Me

            End If

        End If

    End If 

End Sub 

Private Sub Form_Load() 

    Set con = New ADODB.Connection

    Set rs = New ADODB.Recordset

    con.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=hall.mdb;Persist Security Info=False"

    rs.Open "select * from Login", con, adOpenDynamic, adLockBatchOptimistic

End Sub 

24

Viva Questions:

1. What is Data modeling?

Data modeling in software engineering is the process of creating a data model by applying formal data model descriptions using data modeling techniques.

2. What are the inputs to Data Flow Diagram? Isolated data objects and grammatical parse to determine operations. External entities (producers and consumers of data). Level 0 DFD “Context Diagram” (one single process). The flow to maintain data flow continuity.

3. What are the inputs to ER Diagram?

Objects identified from the problem statement. Operations that are relevant to the application and data transformations. Services that will be required by the objects. Relationship which indicates “connectedness”: a "fact" that must be

"remembered" by the system and cannot be or is not computed or derived mechanically.

4. What are Project Implementation steps? Prepare the infrastructure. Analyze the problem and select suitable implementation language. Install the required servers and software needed for implementation. Select the appropriate data base Perform final verification Implement new processes and procedures. Monitor the solution.

5. What are the steps to create ERD? Define “objects” by underlining all nouns in the written statement of scope:

producers/consumers of data, places where data are stored, and “composite” data items.

Define “operations” by double underlining all active verbs: processes relevant to the application and data transformations.

Consider other “services” that will be required by the objects. Then you need to define the relationship which indicates “connectedness”:

a "fact" that must be "remembered" by the system and cannot be or is not computed or derived mechanically.

25

4 SOFTWARE TESTING

Objective:

To gain a deeper understanding of the Software Testing phase and to detect software failures so that defects may be uncovered and corrected.

Background:

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.

Software testing also provides an objective, independent view of the software to allow the business to appreciate and understand the risks at implementation of the software.

Study:

Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs.

Software testing can also be stated as the process of validating and verifying that a software program/application/product:

1. Meets the business and technical requirements that guided its design and development;

2. Works as expected; and 3. Can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at

any time in the development process. However, most of the test effort occurs after the

requirements have been defined and the coding process has been completed. As such, the

methodology of the test is governed by the software development methodology adopted.

Different software development models will focus the test effort at different points in

the development process. Newer development models, such as Agile, often employ test

driven development and place an increased portion of the testing in the hands of the

developer, before it reaches a formal team of testers. In a more traditional model, most of

the test execution occurs after the requirements have been defined and the coding process

has been completed.

26

Functional vs non-functional testing

Functional testing refers to tests that verify a specific action or function of the code found in the code requirements documentation, development methodologies work from use cases or user stories.

Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or security. Non-functional testing tends to answer such questions as "how many people can log in at once".

Defects and failures

One common source of expensive defects is caused by requirement gaps, A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security.

Software faults occur through the following processes. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure.. A defect can turn into a failure when the environment is changed.

Static vs. dynamic testing

Reviews, walkthroughs, or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing.

Software verification and validation

Software testing is used in association with verification and validation:

Verification: Have we built the software right? (i.e., does it match the specification).

Validation: Have we built the right software? (i.e., is this what the customer wants).

The terms verification and validation are commonly used interchangeably in the industry; it is also common to see these two terms incorrectly defined. According to the IEEE Standard Glossary of Software Engineering Terminology:

Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at

the start of that phase. Validation is the process of evaluating a system or component during or at the end

27

of the development process to determine whether it satisfies specified requirements.

Testing methods

White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these.

Black box testing treats the software as a "black box"—without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing.

28

Testing levels

Tests are frequently grouped by where they are added in the software development process, or by the level of specificity of the test.

Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors.

Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. Software components may be integrated in an iterative way or all together.

Regression testing focuses on finding defects after a major code change has occurred. Specifically, it seeks to uncover software regressions, or old bugs that have come back. Such regressions occur whenever software functionality that was previously working correctly stops working as intended.

Acceptance testing can mean one of two things:

1. A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression.

2. Acceptance testing performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing (UAT). Acceptance testing may be performed as part of the hand-off process between any two phases of development

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site.

Beta testing comes after alpha testing The software is released to groups of people so that further testing can ensure the product has few faults or bugs

Non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as error-handling routines

Performance testing is executed to determine how fast a system or sub-system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage.

Load testing operates under a specific load, whether that be large quantities of data or a large number of users. This is generally referred to as software scalability. The related load testing activity of when performed as a non-functional activity is often referred to as endurance testing.

Volume testing is a way to test functionality. Stress testing is a way to test reliability. Load testing is a way to test performance.

29

Stability testing checks to see if the software can continuously function well in or above an acceptable period. This activity of non-functional software testing is often referred to as load (or endurance) testing.

Usability testin g is needed to check if the user interface is easy to use and understand.

Security testing is essential for software that processes confidential data to prevent system intrusion by hackers.

Inputs:

Software testing process can produce several artifacts.

Test plan  A test specification is called a test plan. The developers are well aware what test plans will be executed and this information is made available to management and the developers. Some companies have a higher-level document called a test strategy.

Traceability matrix  A traceability matrix is a table that correlates requirements or design documents to test documents. It is used to change tests when the source documents are changed, or to verify that the test results are correct.

Test case  A test case normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps (also known as actions) to follow, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected

Test script  The test script is the combination of a test case, test procedure, and test data. Initially the term was derived from the product of work created by automated regression test tools.

Test suite  The most common term for a collection of test cases is a test suite. The test suite often also contains more detailed instructions or goals for each collection of test cases. It definitely contains a section where the tester identifies the system configuration used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests.

Test data  In most cases, multiple sets of values or data are used to test the same functionality of a particular feature. All the test values and changeable environmental components are collected in separate files and stored as test data. It is also useful to provide this data to the client and with the product or a project.

Test harness  The software, tools, samples of data input and output, and configurations are all referred to collectively as a test harness.

30

Deliverables:

Completely tested source code without any errors. The various errors which are encountered during the testing must be clearly Documented.

Viva Questions:

1. What is a test plan?A test specification is called a test plan. The developers are well aware

what test plans will be executed and this information is made available to management and the developers. Some companies have a higher-level document called a test strategy.

2. What is a test data?In most cases, multiple sets of values or data are used to test the same

functionality of a particular feature. All the test values and changeable environmental components are collected in separate files and stored as test data. It is also useful to provide this data to the client and with the product or a project.

3. Differentiate white box and black box testing.

White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these.

Black box testing treats the software as a "black box"—without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing.

4. What is a software verification?

Verification: Have we built the software right? (i.e., does it match the specification).

5. What is software Validation?

Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements

31

5 SOFTWARE DEBUGGINGObjectives :

To gain a deeper understanding of software debugging.

Background:

Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware, thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. Many entire books have been written about debugging (see below: Further reading), as it involves numerous aspects, including: interactive debugging, control flow, integration testing, log files, monitoring, memory dumps, Statistical Process Control, and special design tactics to improve detection while simplifying changes.

Study:

As software and electronic systems have become generally more complex, the various common debugging techniques have expanded with more methods to detect anomalies, assess impact, and schedule software patches or full updates to a system.

The words "anomaly" and "discrepancy" can be used, as being more neutral terms, to avoid the words "error" and "defect" or "bug" where there might be an implication that all so-called errors, defects or bugs must be fixed. Instead, an impact assessment can be made to determine if changes to remove an anomaly would be cost-effective for the system, or perhaps a scheduled new release might render the change(s) unnecessary.

Not all issues are life-critical or mission-critical in a system. Also, it is important to avoid the situation where a change might be more upsetting to users, long-term, than living with the known problem(s). Basing decisions of the acceptability of some anomalies can avoid a culture of a "zero-defects" mandate, where people might be tempted to deny the existence of problems so that the result would appear as zero defects.

Various debugging techniques:

Print debugging is the act of watching (live or recorded) trace statements, or print Statements, that indicate the flow of execution of a process.

Remote debugging is the process of debugging a program running on a system Different than the debugger. To start remote debugging, debugger connects to a Remote system over a network. Once connected, debugger can control the execution of the program on the remote system and retrieve information about its state.

32

Post-mortem debugging is the act of debugging the memory dump (or core of a process. The dump of the process space could be obtained automatically by the system, or by a programmer-inserted instruction, or manually by the interactive user. Crash dumps (core dumps) are often generated after a process has terminated due to an unhandled exception.

Steps involved in debugging process:

Unlike software development, debugging is inherently iterative. (I mean development in general, realizing that in complex projects development can and should be iterative, too). Debugging, in general, consists of three main stages:

1. Describe the bug.Maybe this isn't part of debugging itself, but it's so important that I include it here. You should get as much detail from the user as possible: product version, OS version, all conditions needed to reproduce the bug.

2. Get the program snapshot when the bug 'appears'.Try to reproduce the bug and catch the state (variables, registers, files, etc.) and action (what the program is doing at the moment, which function is running). Sometime this is simple: e.g. the program crashes and you can just switch to your debugger to see the problem. But in other cases you have to perform many iterations to catch the snapshot. You maybe even have to return to 1 in some cases. In other cases you will return here from the next step.

3. Analyze the snapshot (state/action) and search for the cause of the bug.It is possible that the state and action might be wrong, so a substep in this stage is to determine whether they are correct or not. The following state/action combination classification can be useful in guiding further analysis ('+' & '-' indicate 'correct' & 'wrong', respectively ):

o +/+ : unreproducible bug;You have an incorrect description or different environments (OS, etc.)

o +/- : a simply found bug;You have to add some checking (NULL pointer, divide by zero, etc.) or additional implementation of something

o -/+ : a bug requiring a search for its source, origin;Methods you can use include

tracing from previous moments, tracing of places where the state components are used/changed tracing with different input data your experience may indicate key places in the program (e.g., the

start of user input processing) o -/- : same as -/+ plus additional difficulty, but due to the difficulty of

situation in some cases some work-around may be enough decision, i.e. making action correct (+).

33

4. Fix the bug.Ideas about bug fixing may occur at any stage of the debugging process, but only one may be implemented, which 1) fixes the class of bugs which the described one belongs to, and doesn’t introduce other bugs in other places and/or with other input data.

Inputs:

The following test cases are the inputs for the debugging phase.

34

Deliverables:

A text document which contains the errors traced out during the debugging and the corresponding measures to be taken.

Viva Questions:

1. What is print debugging?

Print debugging is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process.

2. What are Debuggers?

Debuggers are software tools which enable the programmer to monitor the execution of a program, stop it, re-start it, set breakpoints, change values in memory and even, in some cases, go back in time. The term debugger can also refer to the person who is doing the debugging.

3. What is remote debugging?

Remote debugging is the process of debugging a program running on a system different than the debugger. To start remote debugging, debugger connects to a remote system over a network. Once connected, debugger can control the execution of the program on the remote system and retrieve information about its state.

4. What is anti-debugging?

Anti-debugging is "the implementation of one or more techniques within computer code that hinders attempts at reverse engineering or debugging a target process".The types of technique are:

API-based: check for the existence of a debugger using system information Exception-based: check to see if exceptions are interfered with Process and thread blocks: check whether process and thread blocks have been

manipulated Modified code: check for code modifications made by a debugger handling

software breakpoints Hardware- and register-based: check for hardware breakpoints and CPU registers Timing and latency: check the time taken for the execution of instructions.

35

5. What are the steps to improve debugging? Build smarter debugging tools. Since these tools would be used in almost all

stages of debugging, it would be useful to “teach” them the program and the program itself should help debuggers.

Create a system/DB of key documentation about the program useful in debugging, for example "If there is a problem in aspect A, then look (set breakpoints, etc.) in key places A1, A2, … ". The DB should support searching.

DOCUMENTATION AND USER MANUALS

Documentation:

Software documentation is the written record of facts about a software system recorded with the intent to convey purpose, content and clarity. The recording process usually begins when the need for the system is conceived and continues until the system no longer in use.

Types:

User documentation System documentation

User documentation:

It refers to those documents,containing descriptions of the functions of a system without reference to how these functionsare implemented.

S.No Document Function1. System overview Provides general description of system’s functions2. Installation guide Describes how to set up the system, customize it to

local hardware needs and configure it to particular hardware and other software resources.

3. Beginner’s guide Provides simple explanations of how to start using the system.

4. Reference guide Provides in-depth description of each system facility and how it can be used.

5. Enhancement Booklet contains a summary of new features.6. Quick reference card Servers as a factual lookup7. System administration Provides information on services such as net-working,

security and upgrading.

System documentation:

36

It refers those documentation containing all facets of system, including analysis, specification, design, implementation, testing, security, etc.

User manual:

A user guide or user's guide, also commonly known as a manual, is a technical communication document intended to give assistance to people using a particular system.It is usually written by a technical writer, although user guides are written by programmers, product or project managers, or other technical staff, particularly in smaller companies.

User guides are most commonly associated with electronic goods, computer hardware and software.

Most user guides contain both a written guide and the associated images. In the case of computer applications, it is usual to include screenshots of how the program should look, and hardware manuals often include clear, simplified diagrams. The language used is matched to the intended audience, with jargon kept to a minimum or explained thoroughly.

As the name implies, User Guides are written to help people understand an software application or IT system. They are also called User Manuals. When writing a User Guide, use simple language with short sentences. This writing style helps the user understand the application.

User Guides are the first port of call when something needs to be read. As many people read user guides when frustrated and after having lost patience with the software, you need to write your material to address their concerns quickly.

User Guides are often written for non-technical individuals. The level of content and terminology differs considerably from, for example, a System Administration Guide, which is more detailed and complex.

This rest of article offers some guidelines to consider when writing your User Guide, such as:

Identifying your audience

Writing sections

Defining style guide and standards

Delivery formats

Identifying Your Audience

37

As with all types of writing, the first step is to define your TARGET AUDIENCE. Your target audience are the people who will user your document. As different readers have different requirements, you need to consider their specific requirements

Identify the target audience

Identify their level of technical knowledge

Identify how they will use the guide

Audience Definitions

In the planning process, develop an audience definition that identifies:

The user

The system

The tasks

Software is used to do specific things. Users want to know what the software can do for them, for example, how to print a page in landscape.

They are generally not interested in the nitty-gritty technical details; they want to click a button and get a result. The User Guide is to teach them how the software helps them to do something.

Depending on the guide in question, you may need to address several audiences. For example:

Programmers who will troubleshoot the program

IT Managers who want to know the resources the program requires

Project Managers who want to confirm that the original requirements were met.

If you are writing for more than one audience, develop an audience definition for each one. Examine the definitions and see if you can address all audience types with one document. In many situations, you may need to write a number of documents, of which the users guide is only one.

When planning, use the audience definition to focus your decisions.

38

When writing, the audience definition serves as a guide for the documentation team and as a benchmark for evaluating the results.

Here are some questions that will help define your audience's needs:

Where will they use the document, for example, in the office, at home, in their car?

How much experience have they of using your application?

Is this guide an upgrade to an existing application?

Is your application new? If so, you may want to include a Getting Started document to introduce the software.

How will they use the user guide?

Will they install the software by themselves or do so over the internet?

What level of detail is required?

Will graphics help their understanding of how to use your product?

Writing the User Guide

Each user guide is comprised of front page, body sections, and a back page. The following section describes what each of these needs to contain.

Front Page (cover pages)

Include a cover page, table of contents, and a preface, if necessary.

Cover and Title Page

If the user guide is copyrighted, include a copyright notice.

Copyright © 2003 The Name Of Your Company.

Place the copyright notice on the cover (and also the title page).

Disclaimer

Include a standard disclaimer inside the front cover that outlines the Terms and Conditions for using this guide.

Preface

39

Use this section to reference other documents related to the software. Make sure you refer to the correct release number for all software and documents that you refer to. If necessary, include a section on "How to use this guide" as an introduction.

Contents

You must include a table of contents. the only exception is if your guide is less than ten pages, in which case you should probably refer to it as a Getting Started guide or Reference Guide.

If this user guide is more than twenty pages, include an index at the end of the document.

Body of the guide

This is the heart of the guide. In the main body, separate the procedures (also called instructions) from reference materials. This will help the user navigate their way through the guide much faster.

Procedures

Procedures help the user perform specific tasks. They are also known as instructions or tasks. Examples of these may include:

When, why, and how you can perform a task, for example, printing a document, cropping an image, uploading a file. 

What the screen will show after you perform a task, for example, an updated view of your bank balance.

Examples of tasks and program operation.

Writing procedures

Writing procedures involves the following tasks:

Identifying the major tasks

Separating each major task into subtasks

Writing a series of steps that walk the user through each subtask

Using an "if-then" approach when explaining decisions that users can make.

Chunking text

40

Breaking large pieces of information into smaller piece of information is called "chunking."

When writing user guides, you can separate information by menu options and their respective consequences, for example, showing the user the results of each action.

Subtasks that need to be performed can be divided into chunks. Each chunk can form a new chapter or section within the guide.

Use a consistent format for each section, for instance:

Introduce each section with an overview of the task to be performed

Describe the inputs and outputs. In other words, what the user must enter into the system and what the system will do as a result. 

Describe the procedures for accomplishing these tasks.

Number your steps

When writing procedures, number each step and use the imperative form of verbs, for example:

Press ENTER

or

Click "Yes" and press ENTER to submit your details.

Using the If-Then Approach

When users are allowed to make decisions, use an If-Then approach to show the different result for each decision they make.

If you choose "Yes," the program will make Firefox your default web browser. If you choose "No," it will set Opera as your default browser.

Use diagrams to illustrate more complicated procedures.

41

Reference Materials

User turn to reference material when they need detailed information on a specific topic, for example, settings or parameters they must enter.

Reference materials can include:

Program options, for example, different menus and buttons that are presented to the user

Keyboard options, for example, hold AltGr and 4 to show the Euro symbol

Error messages that may arise when you use the application

Troubleshooting tips to resolve these issues

Frequently asked questions that the user may have about the software

Back Matter

Add a Glossary of Terms and an Index towards the end of the document.  

Glossary

The glossary should cover all acronyms and industry terms used in the document. Help the user understand your material. Do not alienate them by using jargon and assuming that they know the meaning on these words.

A short glossary can appear at the front before the table of contents

A larger glossary should appear in the back matter.

Highlight glossary terms (by italics, for instance) the first time they appear in text.

Index

Any guide longer than 20 pages benefits from an index. An index helps users locate specific items very fast without having to search through the entire document manually. Large documents without an index are impossible to use efficiently.

42

Establishing Standards

As well as writing the guide, you also need to consider how the document will be delivered, for example, as a book, online or a PDF.

Areas that need consideration include:

Format (the design and layout of the pages)

Style (elements affecting readability, such as font, size, color)

Other requirements that are specific to each delivery format. For example, PDFs may need security settings applied so material cannot be copied; partner logos may need to be added; terms and conditions may need to be updated.

Document Format and Structure

If you are writing a user guide for a client, rather then your own company, check if they use a specific style guide or have a preference for how the document should be presented. Check this with the client during the planning phase.

Use a document map to organize the guide. To do this:

Use headings for organizing information.

Include page numbers and section titles on every page, either in footers or headers.

Consider using dual columns. This lets you put headings in the left-hand column and the text in the right-hand column.

Style

Use an appropriate style. Decide on the technical level of your language, how you address the user, and conventions that are required.

Technical Language

Match the level of technical language with the audience ¯s level of proficiency. Always underestimate the knowledge of your readers rather than overestimate it.

Limit technical terms to those the user will encounter. If you must define a large number of terms, use a glossary to supplement definitions in the text.

43

Addressing the User

When writing procedures, use the active voice (e.g. Click this) and address users directly (write "you" rather than "the user").

When explaining an action, use the "command" form of the verb:

"Choose an option from the menu and press [ENTER]."

Presenting your material

You can improve the readability of your documents by using specific formats to distinguish different types of information.

For example, you can distinguish the user's input from the system's response by:

Indenting text

Using columns to layout text

Providing illustrations or photographs that highlight key areas

Using different fonts and type features (bold, italics and underline)

Nonverbal devices, such as icons or diagrams, help supplement verbal instructions.

44