• Save
Software Engineering
Upcoming SlideShare
Loading in...5
×
 

Software Engineering

on

  • 2,923 views

 

Statistics

Views

Total Views
2,923
Views on SlideShare
2,915
Embed Views
8

Actions

Likes
1
Downloads
0
Comments
1

1 Embed 8

http://www.slideshare.net 8

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Software Engineering Software Engineering Presentation Transcript

  • An Evaluation Of Requirements Engineering Process Performance Measures POONAM SHARMA PARUL MATHUR ANIL BHALLA
  • INTRODUCTION POONAM SHARMA
  • REQUIREMENTS ENGINEERING
    • Requirements Engineering produces one large document, written in a natural language, contains a description of what the system will do without describing how it will do
    View slide
  • Problem Stmt SRS Requirements Elicitation Requirements Analysis Requirements Documentation Requirements Review Reqt Engg View slide
  • Crucial Process Steps of Requirements Engineering
    • Requirements Elicitation
    • Requirements Documentation
    • Requirements Review
    • Requirements Analysis
  • Requirements Elicitation
    • Interviews
    • FAST
    • Use Cases
    • Brainstorming Sessions
  • Use Case
    • Uses combination of text and pictures
    • Only give functional view of the system
    • Use case , Use case scenario and use case diagrams
  • Use Case Diagrams
    • Components of Use Case Diagrams
    Actor Use Case Relationship
  • Admin Reservation Clerk Passenger Update Train Info Login View Reservation Status Reserve Seat Cancellations
  • Draw the context diagram Develop prototypes (optional) Model the requirements Finalize the requirements Requirement Analysis Steps
  • Requirements Documentation 1 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms & Abbreviations 1.4 References 1.5 Overview 2 The Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 Assumptions & Dependencies 2.5 Constraints
  • Cont.. 3. Specific Requirements 3.1 External Interfaces 3.2 Performance Requirements 3.3 Logical Database Requirements 3.4 Design Constraints 3.5 Functions 3.6 Additional Comments 4. Change Management Process 5. Document Approvals 6. Supporting Information
  • Measure & Metrics Measure : A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attributes of a product or process Metrics : A quantitative measure of the degree to which a system, component, or process possesses a given attribute
  • METHODS OF REQUIREMENTS ENGINEERING PARUL MATHUR
    • Size Estimation
    • Cyclomatic Complexity
    • Software Science Measures
    Methods are :
    • Time
    • Functionality
    • Cost
    Performance Measures
    • Quality
  • Size Estimation
    • Estimation of Size is very critical
    • Difficult to identify the size of the system
  • Lines of Code (LOC)
    • Easily recognizable
    • First measurement attempted
    • No general agreement about what constitutes
    • LOC
  • This is not a line count, but a statement count. It is possible to put several statements on one line by using the colon ":" or writing single-line If..Then statements. Statements Two or more lines joined with the line continuation character "_" are counted as one logical line. Logical lines of code Counts lines but excludes empty lines and comments. Also referred as the source lines of code (sLOC) metric. Physical lines of code Counts physical lines, but excludes classic VB form definitions and attributes. Physical lines Counts all lines in source files. Simple line count Description Metric
  • } 18 return 0; 17 } 16 } 15 x[j]=save; 14 x[i]=x[j]; 13 save=x[i]; 12 { 11 if(x[i]<x[j]) 10 for(j=1;j<=im1;j++) 9 im1=i-1; 8 { 7 for(i=2;i<=n;i++) 6 if (n<2) return 1; 5 /*this function sort array x in ascending order*/ 4 int i, j, save, im1; 3 { 2 int sort(int x[],int n) 1
  • Function Count
    • Measures functionality from users point of view
    • Deals with functionality being delivered & not
    • with LOC, source modules, files etc
  • Five Functional Units
    • Inputs
    • Outputs
    • Enquiries
    • Internal logical files
    • External interface files
  • Counting Function Points
    • Functional units are ranked according to their complexity
    • Unadjusted Function Points (UFP) are calculated using predefined weights for each function type
    5 3 UFP = ∑ ∑ Z ij W ij i=1 j=1 i & j : rows & columns resp W ij : entry of i^th row & j^th column Z ij : count of number of function units of i corresponding to j
  • Weighting Factor 9 8 4 Interfaces 14 12 10 Files 9 7 3 Enquires 7 6 5 External Outputs 4 3 2 External Inputs Complex Average Simple Function Specifications
    • Complexity Adjustment Factor (CAF) is determined by considering 14 aspects of processing complexity
    FP = UFP * CAF CAF = [ 0.65 + 0.01 * ∑ F i ] Counting Function Points
    • Does the system require reliable backup & recovery?
    • Are data communications required ?
    • Are there distributed processing functions ?
    • Is performance critical ?
    • Will the system run in an existing, heavily utilized operational environment ?
    • Does the system require online data entry ?
    0 1 2 3 4 5 No Influence Incidental Moderate Average Significance Essential
    • Does the on-line data entry require the input transaction to be built over multiple screens or operations ?
    • Are the master files updated on-line ?
    • Are the inputs, outputs, files or inquiries complex ?
    • Is the internal processing complex ?
    • Is the code designed to be reusable ?
    • Are conversion and installation included in the design ?
    • Is the system designed for multiple installations in different organizations ?
    • Is the application designed to facilitate change and ease of use by the user ?
    Cont..
  • Special Features of Function Points
    • Independent of the language, tools, or methodologies
    • Estimated from requirement specification
    • Directly linked to statement of requirements
  • Evaluation Emphasis is more on quantity than quality Quality Depend on time & LOC Cost More time is required; depending upon functionality & complexity Time Dependent on system capabilities Functionality Effect Measure
  • METHODS OF REQUIREMENTS ENGINEERING ANIL BHALLA
  • Software Science Measures & Cyclomatic Complexity
  • Software Science Measures
    • Means of determining quantitative measure of complexity
    • A program is considered to be a series of tokens
    • All the software science measures are functions of the counts of these tokens
  • Four scalar numbers derived directly from a program's source code Total number of operands N2 Total number of operators N1 Number of distinct operands n2 Number of distinct operators n1 Description Symbol
  • Five measures are derived E= D * V E Effort D= (n1/2) * (N2/n2) D Difficulty V= N * (LOG2 n) V Volume n= n1 + n2 n Program vocabulary N= N1 + N2 N Program length Formula Symbol Measure
  • Terminologies used
    • Tokens: Classified as either operators or operands
    • Operators: Any symbol or key word in program
    • Operand: Symbol used to represent data
    • Vocabulary: Number of unique tokens used to build a program
    • Length of Program: Total number of tokens used in program
    • Volume: It is the number of mental comparisons needed to write a program
    • Program Level: L=V*/V
    • where V* is potential volume of program &
    • V is given volume of program
    • The value of l ranges between 0 & 1, with L=1 representing highest possible level ( i.e. minimum size)
    • Difficulty: as volume of an implementation of a program increases the program level decreases & difficulty increases
    • Effort: The effort required to implement a program increases as the size of the program increases
  • Evaluation Cost will fluctuate Cost Depends on computational complexity Functionality Quality decreases upon increase in conditions Quality Time increases according to difficulty of program Time Effect Measures
  • Cyclomatic Complexity ( CC )
    • It provide quantitative measure of the logical complexity of a program
    • Value computed for CC defines number of independent paths in the basic program
    • It provide upper bound for number of tests that must be conducted to ensure that all statements have been executed at least once
  • 3 ways to compute CC
    • Number of regions of the flow graph
    • CC, V(G), for the flow graph G, is defined as
    • V(G) = E – N + 2
    • where E is number of edges in flow graph
    • N is number of nodes in flow graph
    • CC, V(G), for the flow graph G, is defined as
    • V(G) = P + 1
    • where P is number of predicate nodes
  • Terminologies
    • Independent Path: Any path through the program that introduces at least one new set of processing statements or new condition
    • Edges: Represent flow control in program
    • Nodes: Represents procedural statements
    • Regions: Area bounded by edges & nodes
    • Predicate Node: Node that contains a condition
  • Flow Chart 1 3 6 4 5 7 8 2 9 10 11
  • Flow Graph 1 2,3 6 7 8 9 10 4,5 11 Edges Nodes R1 R2 R3 R4 Regions
  • CC for Flow Graph
    • The flow graph has 4 regions
    • V(G) = 11 edges – 9 nodes + 2 = 4
    • V(G) = 3 predicate nodes +1 =4
    • Therefore CC for this graph = 4
  • Evaluation Depends on time, quality & functionality of program Cost Provide basis for planning tests for program Functionality Gives logical complexity Quality Time required is more than size estimation Time Effect Measures
  • THANK YOU !!!
  • ANY QUERIES ??