BCS 051 Introduction to Software Engineering Study Notes PDF

Preview

Summary

Contents Block 1 – Development of SRS..................................................................................................................... Unit 1 – Characteristics of SRS................................................................................................................. ...

Description

Contents Block 1 – Development of SRS.....................................................................................................................3 Unit 1 – Characteristics of SRS.................................................................................................................3 SRS – Page 5.........................................................................................................................................3 Benefits of SRS – Page 6.......................................................................................................................3 SRS Characteristics – Page 7.................................................................................................................4 IEEE SRS Format – Pages 8-11..............................................................................................................4 Unit 2 – Function Oriented Modeling......................................................................................................6 Process of Developing an ERD – Page 23.............................................................................................6 Structure Chart – Pages 23-25.............................................................................................................6 Data Dictionaries – Page 26.................................................................................................................7 Contents of Data Dictionary – Page 27................................................................................................7 Components of Data Dictionary with Explanations – Page 27-28........................................................7 Unit 3 – Object Oriented Modeling..........................................................................................................9 Use Case Approach – Page 32..............................................................................................................9 Use Case Diagram – Pages 32-34.........................................................................................................9 Class Diagram – Pages 34-46..............................................................................................................10 Block 2 – Design and Testing......................................................................................................................12 Unit 1 – Function Oriented Design.........................................................................................................12 Function Oriented Design – Pages 5-6...............................................................................................12 Cohesion & Coupling and their types – Pages 11-13..........................................................................13 Unit 2 – Object Oriented Design............................................................................................................15 Object Oriented Design – Pages 15-17...............................................................................................15 Motivating Factors for using Object-Oriented Concepts – Pages 15-16.............................................15 Application Logic Objects – Pages 20-21............................................................................................16 Unit 3 – Software Testing Techniques....................................................................................................17 Difference between white box and black box testing – Pages 28-30 & Block 3 Page 18....................17 Difference Between Unit & Integration Testing – Pages 30-34 Unit 4 Page 47...................................17 Module Testing with example – Page 31-32......................................................................................17 Regression Testing – Page 34.............................................................................................................17

Acceptance Testing – Page 37-38.......................................................................................................18 Alpha and Beta Testing – Page 38......................................................................................................18 Unit 4 – Development and Execution of Test Cases...............................................................................20 Debugging Strategies – Page 44.........................................................................................................20 Definition of Test Case – Page 48.......................................................................................................20 Test Case for Functional Testing – Page 49.........................................................................................20 Block 3 – Software Engineering Concepts..................................................................................................22 Unit 1 – Software Engineering and its Models.......................................................................................22 Waterfall Model, Advantages-Disadvantages – Page 9......................................................................22 Prototyping Model – Page 10............................................................................................................22 Spiral Model – Pages 10-11................................................................................................................23 Spiral Model Advantages – Pages 11..................................................................................................23 SEI Capability Maturity Models Levels – Pages 12-13........................................................................23 Problems related to software development – Page 19......................................................................24 Unit 2 – Software Project Management................................................................................................25 Software Project Management – Pages 21-22...................................................................................25 Software Project Cycle with Flow Chart – Pages 26-27......................................................................26 PERT Chart – Pages 33-35..................................................................................................................27 GANTT Chart – Page 35-37................................................................................................................28 Unit 3 – Software Engineering Fundamentals........................................................................................29 Software Configuration Management and its significance – Pages 39-42..........................................29 SCM Activities – Pages 42-43.............................................................................................................30 Types of Software Maintenance – Pages 44-45.................................................................................30 Re-Engineering – Page 49..................................................................................................................31 Calculating Cost Using COCOMO – Page 50.......................................................................................31 Software Quality Assurance – Pages 50-51........................................................................................31 McCall’s Quality Factors – Page 52.....................................................................................................32

Block 1 – Development of SRS Unit 1 – Characteristics of SRS SRS – Page 5 - A Software Requirements Specification (SRS) is a specification of the software system which provides complete and structured description of the system’s requirements, behavior, interfaces including all functional test use cases and non-functional requirements. - Functional use cases provide detailed description of various functionalities that need to be supported by the software system from user’s point-of-view. - Non-functional requirements specify the requirements for performance, scalability, availability, accessibility, portability, etc. - Organizations create SRS documents to provide the complete requirements for vendors to implement the software system. - Or in case of in-house development, SRS captures user requirements in a structured fashion to aid software implementation. - SRS communicates all detailed requirements from end-user/customer to the software development team. Benefits of SRS – Page 6 - Forms the basis of agreement between customers and suppliers about the software functionality: o Serves as a structured contract between these parties specifying functionalities along with constraints o End user can verify if the software meets the requirements specified in the document - Optimizes the development effort: o As all requirements are specified beforehand, the development team can reduce the efforts in re-design, re-work, re-testing and defect-fixing. - Forms basis for cost and schedule implementation: o Using the functional and non-functional requirements, the project management team can better estimate the overall project cost and schedule and make informed decisions about risk identification and mitigation - Forms basis for verification and validation: o QA team can design the validation and testing strategy including various test cases based on the requirements specified in the SRS - Helps software portability and installation: o Software usability information in SRS helps to transfer the software across various locations - Helps in enhancement: o As all requirements are specified in the SRS, it is easier to assess the impact of any planned enhancement

SRS Characteristics – Page 7 - Correct: o Should specify functionality correctly from all aspects -

-

-

-

-

-

Unambiguous: o Since it is written in natural language, it is possible to misinterpret the SRS. o So, it should define things in the most unambiguous fashion as possible. Precise: o The description should not contain any fizzy words Complete: o Should provide all details required by the software designers for the design and implementation of the intended software. Consistent: o The terminologies, definitions and others used throughout the SRS should be consistent Verifiable: o All requirements should be quantified with exact and verifiable numbers. o “The home page should load quickly” not verifiable o “Home page should load within 2 seconds in the North America region” verifiable Modifiable: o Requirements should be detailed only once in the document so it is easier to modify and maintain the document in the long run Traceable: o SRS should map the requirements to other business/user requirement documents so that it is possible to trace the requirements Ranked for importance/stability o Requirements should be ranked on its deemed business/user importance

IEEE SRS Format – Pages 8-11 1. Introduction a. Purpose of the Software Requirement Specification b. Scope of the Product c. Definition, Acronyms and Abbreviations d. References e. Overview of the Rest of the Software Requirement Specification 2. General Description a. Product Perspective i. System Interface ii. User Interface iii. Hardware Interface iv. Software Interface v. Communication Interface vi. Operations b. Product Functions

c. User Characteristics d. General Constraints e. Assumptions and Dependencies 3. Specific Requirements a. External interface requirements b. Functional requirements c. Performance requirements d. Design constraints i. Standards compliance e. Logical database requirement f. Software system attributes i. Reliability ii. Availability iii. Security iv. Maintainability Appendices

Unit 2 – Function Oriented Modeling Process of Developing an ERD – Page 23 The following are the main steps in building an ERD: 1. Identify the nouns in the database domain which depict objects. These objects become entities in ERD 2. Identify all the properties which are required and used in the current domain. The properties become the attributes for an entity. 3. Identify the relationship between entities. 4. Refine entities and remove any redundant entities or relationships. Example on Page 23

Structure Chart – Pages 23-25 - A structure chart (SC) decomposes the high level system into multiple, executable tasks. - It essentially describes the list of functions, sub-functions along with their relationship that constitute a system along with data and control flow - SC is the next step after DFD during design and implementation as it provides more details - SC serves the following purposes: o Breaks the system into smaller and executable functional tasks o Depicts the complexity and size of the system -

Elements of SC: o Module depicts a function or a sub-function Module o

Condition decides which module is to be invoked based on the condition

o

Loop indicates repetition of one or more modules Main Module

Sub Module 1

Sub Module 2

o o

Data couple Control flow

o

Devices such as peripheral devices and external interfaces

Interface o

Software infrastructure and connections to external systems, databases, ERP systems

Connection

Data Dictionaries – Page 26 - Data dictionary is the repository of information about data items such as origin of data, data structure, data usage and other metadata information related to data elements - It is used as system of record for structure chart and for other references. - They help to organize and document the information related to data flows, data processes and data elements in a structured fashion Contents of Data Dictionary – Page 27 - Data dictionaries contain information about following high level elements: - Data element/item details - Data structure and definition - Data process - Data stores Components of Data Dictionary with Explanations – Page 27-28 - Data Element/Item Details o Most primitive and smallest information about data o Multiple data elements combine to form a data record o The following information about data element is stored in data dictionary:

-

-

-

 Unique ID  Name Alias  Default Value  Length  Description  Data Type  Input Format  Output Format  Comments  Validation Criteria Data Store Details o Specifies the storage format of data element such as flat file or database record o Also provides details like volume of data stored and frequency of data storage o If data storage is file system, then file name, file path, etc. will be mentioned. o In case of database storage, information related to table, schema name, etc. will be mentioned Data process details: Dictionary contains information related to data process such as: o Process Name o Process inputs o Process Output o Type of the processes o Logic executed in process Data Structure and Definition: Complex data elements are described using following symbols: o “composed” denoted by “equals” o “and” denoted by “+” o “or” denoted by “/” o o o

“optional” denoted by “()” “repetition” denoted by “{}” Example: Book Record = Book ID + Book Name + Author Name + Publisher Name + (Publication Date)

Unit 3 – Object Oriented Modeling Use Case Approach – Page 32 - This is used to represent the system pictorially - It is a combination of text and images to understand the requirements of system clearly - In this approach, we mainly use three terms: o Use cases are templates for the description of user requirements and written in English language point wise o Use case scenario is unstructured description of user requirements o Use case diagrams are pictorial representation of system Use Case Diagram – Pages 32-34 - It shows the relation between the user and the system and creates the boundary of the system - This diagram is used to: o Understand the requirements clearly o Enable users to understand the system o Generate test case to validate the system o Build project schedule -

In use case diagram, seven symbols are used. They are: o System: Shows the boundary of a system

o

Actor: Represents the user or people or device which interacts with the system. Gives input to the system.

o

Use Case: Shows desired function of the system. Actors give input to use case and use case provides output for given input

Generate Report

o

Association: Structural relationship that describes a set of links Employee Employer

o o

Dependency: Used to show relation between use cases Generalization: Shows inheritance among use cases and actors

o

Realization: It is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.

Class Diagram – Pages 34-46 - Class diagram shows the static view of the system by showing the classes and their relationships. - A class integrates the data and behavior into one unit - Example on page 35 - Class specifies the visibility values which include public (+), private (-), protected (#) and package (~). - Three types of relations can exist between classes in the class diagram. o Association:  Relates a class A to class B and is shown as a link between classes  Diagram on page 35 o Generalization:  Is shown by is-a relationship  The classes between which is-a relationship is identified are called superclass and subclass  Diagram on page 36 o Aggregation: It is a special type of association which supports building complex objects out of existing objects

Block 2 – Design and Testing Unit 1 – Function Oriented Design Function Oriented Design – Pages 5-6 - A typical procedural software system consists of multiple functions that share the same state and interact. - Function oriented design essentially deals with creating functions to convert input into the desired output. - The key elements of function oriented design: o Function:  Unit of code consisting of a sequence of instructions required to perform a specific task  Often referred to as method or routine o Function state:  The data on which a function operates  E.g., getEmployeeDetails function would require the employee state  In a FOD, the state is centrally stored and is accessible to all functions o Sub Function: The main function can be further broken down into smaller re-usable units of code or sub-functions  E.g., getEmployeeDetails can invoke getEmployeeContactDetails and getEmployeePersonalDetails sub-routines Key features of function oriented design o Top down decomposition:  A software system consists of functions each performing a unique personality  Once the high-level functions are identified, each of them is further decomposed into modular sub-functions  E.g., High level function such as “UpdatePerson” can be broken down into:  UpdatePerssonPersonalDetails  UpdatePersonAddressDetails  UpdatePersonContactDetails o Function association:  Multiple functions are often related for interaction and data sharing  E.g., in the above example, UpdatePerson invokes UpdatePersonPersonalDetails with person ID which can uniquely identify the person o Function state sharing:  State of the system is shared among various functions 

-



E.g., in the above example, the state of the person’s details is shared among all the sub-functions including UpdatePersonPersonalDetails, UpdatePersonAddressDetails, etc.

Cohesion & Coupling and their types – Pages 11-13 Cohesion -

Cohesion is the measure of how well the internal elements of a module or a function are connected to each other. The function should a single task Variables and logic in the function should perform a single activity only This enables a strong internal relationship between the internal elements of a function Types of Cohesion o Coincidental cohesion: o o

o

 Internal functions in a given module are loosely correlated Communication cohesion:  The functions within the module update ...