Computer Science Engineering : Software engineering & web technology, THE GATE ACADEMY

Software Engineering

&

Web Technology

For

Computer Science

&

Information Technology

By

www.thegateacademy.com

http://www.thegateacademy.com/

Syllabus SE & WT

THE GATE ACADEMY PVT.LTD. H.O.: #74, Keshava Krupa (third Floor), 30th Cross, 10th Main, Jayanagar 4th Block, Bangalore-11 : 080-65700750, [email protected] © Copyright reserved. Web: www.thegateacademy.com

Syllabus for Software Engineering and Web Technology

Information gathering, requirement and feasibility analysis, data flow diagrams, process

specifications, input/output design, process life cycle, planning and managing the project,

design, coding, testing, implementation, maintenance. HTML, XML, basic concepts of client-

server computing.

Analysis of GATE Papers

(Software Engineering and Web Technology)

Year Percentage of marks Overall Percentage

2013 3.00%

5.63 %

2012 0.00%

2011 7.00%

2010 4.00%

2009 6.0%

2008 9%

2007 5%

2006 4%

2005 7%

2004 16%

2003 1%

Contents SE & WT

THE GATE ACADEMY PVT.LTD. H.O.: #74, KeshavaKrupa (third Floor), 30th Cross, 10th Main, Jayanagar 4th Block, Bangalore-11 : 080-65700750, [email protected] © Copyright reserved. Web: www.thegateacademy.com Page i

C O N T E N T S

Chapters

Page No.

#1 Introduction to Software and Software Engineering 1 – 16

Software Development 1 – 4

Software Development Life Cycle (SDLC) 4 – 5

The Software Requirements Document 5 – 7

Capability Maturity Model (CMM) 7 – 8

Qualities and Principles 8 – 12

Assignment 1 13 – 14

Assignment 2 14

Answer Keys 15

Explanations 15 – 16

#2 Process Modeling 17 – 43

Process Models 17 – 22

Design 22

Overview of Design 22 – 24

Varieties of Architecture 24 – 27

Module Design 27 – 28

Design Notations 28

Design Strategies 28 – 32

Object Oriented Design 32 – 38

Functional or Object Oriented? 38



Answer Keys 42


Contents SE & WT

THE GATE ACADEMY PVT.LTD. H.O.: #74, KeshavaKrupa (third Floor), 30th Cross, 10th Main, Jayanagar 4th Block, Bangalore-11 : 080-65700750, [email protected] © Copyright reserved. Web: www.thegateacademy.com Page ii

#3 Project Management 44 – 62

Software Project Planning 44

Types of Project Plan 44

SPMP Document 45

Metrics for Project Size Estimation 45 – 47

Project Estimation Techniques 47 – 49

Project Scheduling 50 – 53

Risk 53 – 55

Reliability Metrics 55


Assignment 2 59

Answer Keys 60


#4 Validation and Verification 63 -89

Varieties of Testing 64 – 65

Designing Tests 65 – 71

McCabe’s Cyclomatic Complexity Number 71 – 72

Stages of Testing 72

Testing Strategies 72 – 73

Testing Procedures 73 – 75

Preparing Test Cases 75

Software Maturity Index 76

Coupling Metric 76 – 77

Client-Server Computing 77 – 78

Software Maintenance 78 - 81



Answer Keys 87


Contents SE & WT

THE GATE ACADEMY PVT.LTD. H.O.: #74, KeshavaKrupa (third Floor), 30th Cross, 10th Main, Jayanagar 4th Block, Bangalore-11 : 080-65700750, [email protected] © Copyright reserved. Web: www.thegateacademy.com Page iii

#5 HTML Structure 90 –101

HTML Header 91 – 95

HTML Body 95 – 97


Assignment 2 99

Answer Keys 100


#6 XML and DTDs 102 - 115

Definitions 102

XML Anatomy 102 – 107

Creating a DTD (Document Type Defination) 107 – 109

Validating wih a DTD 109 –110



Answer Keys 114


Module Test 116 -123

Test Questions 116 – 120

Answer 121


Reference Books 124

Chapter 1 SE & WT

THE GATE ACADEMY PVT.LTD. H.O.: #74, Keshava Krupa (third Floor), 30th Cross, 10th Main, Jayanagar 4th Block, Bangalore-11 : 080-65700750, [email protected] © Copyright reserved. Web: www.thegateacademy.com Page 1

CHAPTER 1

Introduction to Software and Software Engineering

A software is a set of computer programs and it’s associated documentation. There are two fundamental types of software products: Generic and Customized.

Generic products: Are stand-alone systems that are produced by a development organization and sold on the open market to any customer who is able to buy them.

Customized products: Are systems which are commissioned by a particular customer.

Software engineering is defined as an engineering discipline that applies sound to scientific, mathematical, management and engineering principles to the successful building of large computer programs (software).

Software engineering includes software requirements analysis; software design; implementation using modern programming methods; testing procedures; verification and validation; software configuration management; software quality assurance; tools for analysis and design; corporate software policies; strategies and goals; project management planning; organizing; staffing; directing and controlling; as well as the foundations of computer science.

Software Development

Good software development organizations normally document all the information regarding the output to be produced at the end of different phases, methodologies to be adopted and so forth, into a coherent frame work called the organization’s software development model. The Waterfall Model

The Waterfall Model (WM) is an early lifecycle model. WM is based on engineering practice; it works well if the requirements are well-understood and does not change — this rarely happens in practice. The Waterfall Model is important in the same sense as Newton’s Theory of Gravity: it’s wrong, but you can’t understand relativistic gravitation if you do not understand Newtonian gravitation. WM is more of a theoretical way of developing software

Classical WM model is structured as follows

Feasibility

Study

Requirement Analysis

and Specification

Design

Coding and

unit testing

Integration and system

testing Maintenance

Chapter 1 SE & WT


(i) Feasibility Study

The main aim of the feasibility study activity is to determine whether it would be financially and technically feasible to develop the product.

Feasibility study involves the analysis of the problem and collection of all relevant information such as

Different data items which would be input to the system The processing required to be carried out on these data The output data required to be the produced by the system Constraints on the behavior of the system.

The collected data is analyzed to:

Obtain an abstract problem definition. Formulate different solution strategies Come out with alternative solution strategies to compare their benefits and short

comings.

(ii) Requirements Analysis and Specification

Write a Software Requirements Document (SRD) that describes in precise detail what the customer wants.

Find out what the client wants. This should include what the software should do and also:

likely and possible enhancements platforms (machines, OS, programming language, etc) cost delivery schedule terms of warranty and maintenance user training

The IEEE standard suggests the following structure for SRD, also known as Software Requirements Specification (SRS)

1. Introduction

1.1 purpose of the requirements document 1.2 Scope of the product 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the remainder of the document.

2. General description

2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constrains 2.5 Assumptions and dependencies.

3. Specific requirements cover functional, non-functional and interface requirements. 4. Appendices

Chapter 1 SE & WT


5. Index

Note: The SRD does not say how the software works.

Major deliverable: SRD.

(iii) Design

The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. In technical terms, during the design phase the software architecture is derived from the SRS document.

Design documentation has three parts: Architecture Document (AD): An overall plan for the components of the system. The AD is sometimes called High-level Design Document (HDD). Module Interface Specifications (MIS): Description of the services provided by each software module. Internal Module Design (IMD): Description of how the module implements the services that it provides. In the AD, each module is a “black box”. The MIS describes each module as a black box. The IMD describes each module as a “clear box”. In a black box, only the input/ output behavior is specified and the internal details are not known.

Each requirement in SRD should be traceable to a feature in the design documents. Depending on the project and the requirements, it may be necessary to create a formal (mathematical) specification. Alternatively, selected critical parts of the system may be formally specified. Major deliverable: AD, MIS and IMD.

(iv) Coding and Unit Testing

Coding and unit testing phase is also known as the implementation phase of software development which is used to translate the software design into source code. The end product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested to determine the correct working of all individual modules. Major deliverable: source code and test results. (v) Integration and System Testing

In this phase, the modules are integrated in a planned manner. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it.

When all the modules have been successfully integrated and tested, system testing is to ensure that the developed system conforms to its requirements laid out in the SRS document. There are three different kinds of testing activities:

∝ - testing: It is the system testing performed by the development team β – testing: It is the system testing performed by a friendly set of customers Acceptance testing: It is the system testing performed by the customer himself after the

product delivery to determine whether to accept or reject the delivered product.

Chapter 1 SE & WT


A system test plan document is to perform the system testing. It lists all the test cases and its expected outputs.

(vi) Delivery and Maintenance

The product consists of all the documentation generated and well-commented source code. Maintenance includes Correcting: Removing errors that were not discovered during the production development phase. This is called corrective maintenance Adapting: for a new processor or OS or to new client requirements. This is called adaptive maintenance Perfecting: improving performance with respect to speed or space. This is called perfective maintenance. Maintenance taken up 60% to 80% of the total budget for typical industrial software. This implies the need for high quality work in the early stages. Good documentation and good coding practice make maintenance easier, cheaper and faster. Reverse engineering is a rapidly growing field. Many companies have MLOCs of legacy code developed 20 or 30 years ago in old languages (e.g. COBOL, FORTRAN, PL/I) with little supporting documentation. Tools are used to determine how it works. Delivery also includes customer assistance in the form of manuals, tutorials, training sessions, response to complaints. The requirements of high quality product are the same as the requirements for maintainability. Maintenance is the solution, not the problem. (vii) Software Tools Software tools are an important part of software development. The larger the project, the more important it is to use tools in its development.

Editor. Compiler and Linker Version control system (VCS) Software measurement (DATRIX) Specification checkers (OBJ3, Larch Prover) Test generators Graph editors for DFDs and other diagrams CASE tools for integrated development Browsers, library managers, etc.

Software Development Life Cycle (SDLC) SDLC is a model of a detailed plan on how to correct, develop, implement and eventually fold the software. It’s a complete plan outlining how the software will be born, raised and eventually be retired and from its function.

SDLC is often combined a subset of system development life cycle. There are several models for such processer, each describing approaches to a variety of tasks or activities that takes place during the process. Each phase of SDLC produces deliverable required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that

Chapter 1 SE & WT


is driven by the design. Testing verifies the deliverable of the implementation phase against requirements. The various models will be discussed in the next chapter.

The Software Requirements Document

The SRD has a number of important functions. It provides the basis for:

agreement between customer and supplier. There may be other components of the agreement, such as legal documents.

costing and scheduling. validation and verification. You cannot test software unless you know what it is

supposed to do. all forms of maintenance.

A well-written SRD will reduce development effort by avoiding (expensive) changes later, in design and implementation phases.

Notation: ■= good, ○ = bad.

Nature of SRS

1. Functionality: What the S/W is supposed to do? 2. External interfaces: How does the S/W interface with people, systems hardware and other

software 3. Performance: what is the speed, availability, response time and recovery time etc of various

S/W functions? 4. Attributes: what are the considerations for portability, correctness, maintainability, security

and reliability etc. since the SRC has a specific role to play in the S/W development process. SRS writer should be careful not to go beyond the bound of that role.

Characteristics of a good SRD 1. The SRD should define all of the software requirements but no more. In particular, the SRD

should not describe any design, verification or project management details. o “The table is ordered for binary search.” o “The table is organized for efficient search.” “The search must be completed in time O(log N).”

2. Correct: An SRS is correct if and only if, every requirement stated there in is one that S/W

shall meet. E.g. If the S/W stated that within 10 seconds, then the SRS is incorrect.

3. The SRD must be unambiguous. There should be exactly one interpretation of each sentence. Special words should be defined. Some SRDs use a special notation for words used in a

specific way: !cursor!. Avoid “variety” — good English style, but not good SRD style. Careful usage. o “The checksum is read from the last record.”

Does “last” mean (a) at end of file, (b) most recently read, or (c) previous? “. . . from the final record of the input file.” “. . . from the record most recently processed.”

Computer Science Engineering : Software engineering & web technology, THE GATE ACADEMY

Education

software maintenance

software project planning

software requirements

software maturity index

design strategies

answer keys

module design

engineering principles