15,16 2 Mark SEQA
15,16 2 Mark SEQA
15,16 2 Mark SEQA
2
2
9. Categorize the project planner estimates in FP based estimation
Inputs, Data files, External interfaces, Critical performance, Code designed for
reuse, Outputs, inquires, back up, recovery, Master files updated on- line, Multiple
installation.
10. What is the purpose of timeline chart?
The purpose of the timeline chart is to emphasize the scope of the individual task.
Hence set of tasks are given as input to the timeline chart
11. How to measure the function point FP?
i. Determine a number of items occurring in the system.
ii.Unadjusted Function count is calculated by UFC=item
i
w
i
iii.Function point FP=UFC * TCF where TCF is Technical complexity factor.
TCF=0.65+0.1f
i
12. Define information flow metric.
Information flow metric is defined as the product of length, fan- in and fan-out.
Information flow= length *(fan-in * fan-out)
2
13. What is EVA?
Earned Value Analysis is a technique of performing quantitative analysis of the
software project. It provides a common value scale for every task of software project. It
acts as a measure for software project progress.
14. Write the advantages of CASE tool.
*Ability of automate manual activities and to improve engineering insight.
*CASE tools help to ensure that quality is designed in before the products are built.
15. What are types of software maintenance?
Corrective maintenance: maintenance for correcting the software faults
Adaptive maintenance: maintenance for adapting the change in environment.
Enhancement maintenance: modifying or enhancing the system to meet the new
requirements
Preventive maintenance: changes made to improve future maintainability.
16. List out few product and process metrics.
Process metrics: Lines of code or function points per module and function, defect
reported for major software function, errors found during formal technical review.
Product metrics: Metrics for testing , maintenance ,quality
17. What are the four categories of CASE tool?
*Business process engineering tool,* Project planning tools,*Risk analysis tools
*Requirements tracing tools.
18. What is meant by Scheduling?
Scheduling is an activity that distributes estimated effort across the planned
project duration by allocating effort to specified software engineering tasks.
19. What are the reasons for software change?
*New requirements emerge when the software is used.* Change in business
environment,*Errors needs to be repaired,* New equipment must be
accommodated,* The performance may have to be improved.
20. What is meant by COCOMO model?
COnstructive COst MOdel is a cost estimation model, which gives the estimate of
number of person per months it will take to develop the software product.
21. What is software cost estimation?
It is the process of predicting the resources required for software development
process.
22. What is meant by direct and indirect metrics?
Direct measures refers to immediately measurable attributes.(eg):lines of code
Indirect measure refers to the aspects that are not immediately measurable. Eg:
Functionality of the program.
23. What are the building blocks of CASE?
CASE has the following components, Environment architecture, Hardware
platform, Operating system, Portability services, Integration frame work, and CASE tools
24. What is the purpose of Zips law?
The purpose of ZIPS studies was to investigate dependencies between
frequencies of some words in a sample of text.ZIPs law can be used to derive a length of
document(n) for a given number of classes of tokens.
25. What is meant by metrics and measurement?
Metrics is the degree to which a system component or processes possesses a given
attribute. The software metrics relate several measures. Eg: average no. of errors found
per review.
Measurement means deriving a numeric value for an attribute of a software product
or process.
UNIT I
1. Explain the system engineering hierarchy in detail.
System Engineering as a consequence of process.
Focus on variety of elements, analyzing, designing & organizing those elements
into a system
System engg Process are:
Requirement gathering &analysis
System design
SubSystem development
System integration
System deployment
System evolution
System decommmisioning
System design:
Organizing requirements
Identification of subsystem
Requirement assignment
Specifying subsystem functionality
Subsystem interfeace defn
System engineering hierarchy diagram
World view WV={D1,D2,,Dn}
Domain view Di={E1,E2,,En}
Element view Ei={C1,C2,,Ck}
Detailed view
System Modeling
To construct a system model the following restraining factors are to be considered:
Assumptions
Simplifications
Limitations
Constraints
Preferences
System Simulation
2. Explain software development life cycle models or software process models.
1.Linear Sequential Model or Classic life cycle model or Waterfall model
Diagram for Waterfall model
The model encompasses the following activities:
1. System/information engineering and modeling
2. Software requirement analysis
3. Design
4. Code generation
5. Testing
6. Support
Advantages and disadvantages
2. Prototyping Model
The prototype can serve as the first system which is a throw away
system.
Diagram for prototyping model
Activities: Listen to customer
Build/Revise Mock-up
Customer test drives Mock-up
3. RAD Model
Rapid Application Development Model is the type of incremental
Model. Diagram
Phases include
1. Business modeling
2. Data modeling
3. Process modeling
4. Application generation.
5. Testing and turnover.
4. Incremental Model
It is an evolutionary software process model.
The first increment is a core product.
Combines the elements of the linear sequential model with
iterative nature of prototyping
Diagram for Incremental model
Activities: analysis,design,code,test
Advantages
5.Spiral Model
It is an evolutionary software process model.
Combines the elements of the linear sequential model with
iterative nature of prototyping
Used for the development of large scale systems and software.
Spiral model diagram
The task regions are:
Customer communication
Planning
Risk analysis.
Engineering.
Construction and release.
Customer evaluation.
6.WIN WIN Spiral Model
It is an evolutionary software process model.
Diagram
The model includes 3 process milestones called anchor points:
Life cycle objectives
Life cycle architecture
Initial Operational Capability
7.Object Oriented Model
Object Oriented Model Process model which define a network of
activities .
Object oriented model diagram.
Phases in object oriented life cycle model.
Requirement phase
Analysis phase
Identification of classes
Identification of objects
Design phase
Designing interfaces between classes
Encapsulation of network
Establishing inheritance and code reusability
Implementation and component based development
Testing
UNIT II
1. Explain the various prototyping approaches or prototyping models in detail.
i. Evolutionary Prototyping
Objective is to deliver a working system to end user
Start with the user requirements which are best understood.
Diagram for Evolutionary prototyping.
Advantages
Accelerated delivery of the system
User engagement with the system
Problems
Management problems
Maintenance problems
Contractual problems
ii. Throw-away Prototyping
Objective is to validate or derive the system requirements.
Diagram for Throw away prototyping
Start with those requirements that are not well understood.
Advantages
Problems
It can be undocumented.
Changes made during the software development proceed may
degrade the system structure.
Sometimes organizational quality standard may not be strictly
applied.
2. Explain the various rapid prototyping techniques or methods
Development techniques which emphasize speed of delivery.
There are 3 techniques
Dynamic high level language development
Definition : These are programming language which include powerful
runtime management facilities.
Advantage: Increased power, reduced cost
Disadvantage: needs large run time support
Database Programming
Definition
4GL(Fourth generation language)
Components of 4GL-Diagram
Data base query language
Interface generator
Spreadsheet/Report generator
Component and application assembly
Diagram-Reusable component composition
Levels:
1.application level
2.Component level
Application linking
3. Explain functional and non-functional requirements.
Functional requirements
Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
Non-functional requirements
Constraints on the services or functions offered by the system.
Different types of non-functional requirements (Diagram) are
o Product requirements
Usability requirement-Performance, space requirement
Efficiency requirement
Reliability requirement
Portability requirement
o Organisational requirements
Delivery requirement
Implementation requirement
Standars requirement
o External requirements
Interoperability requirement
Ethical requirement
Legislative requirement
4. Explain the structure of software requirements document
Requirements document should satisfy six requirements
Specify only external system behavior
Specify constraints on the implementation
Easy to change
Serve as a reference tool for system maintainers
Record forethought about the life cycle of the system.
Characterise acceptable responses to undesired events.
Structure of a requirements documents:
Preface
Introduction
Glossary
User requirements definition
System Architecture
System Requirements Specification
System models
System evolution
Appendices
Index
5. Explain in detail about data modeling
Data modeling makes use of the Entity Relationship Diagram.
Data Objects, Attributes and Relationships
Data object representation of something that has a number of different
properties or attributes,Example
Attributes - name a data object, describe its characteristics, make reference to
another object.
Relationships Indicate the manner in which data objects are connected to
one another. Example diagram
Cardinality and Modality
Cardinality is the specification of the number of occurrences of one object
that can be related to the number of occurrences of another object.
o One-to-one cardinality.
o One-to-many cardinality.
o Many-to-Many cardinality.
Modality of a relation is 0 if there is no explicit relationship or relation is
optional.Modality is 1 if an occurrence of relationship is mandatory.
Entity/Relationship Diagrams
Components of ER Diagram
ER diagram for manufacturer and relationship
6. Explain the requirements engineering tasks in detail.
Requirement engineering process diagram
Four Requirement engineering activities
Feasibility studies
Requirements elicitation and analysis
The activities involved in elicitation and analysis process are:
1. Domain Understanding
2. Requirements Collection
3. Classification
4. Conflict resolution
5. Prioritisation
6. Requirements checking
1. Viewpoint oriented elicitation
A viewpoint is
1. data source or sink
2. A representation frame work
3. A receiver of services
Principal stages of Viewpoint oriented Requirement method are:
1.Viewpoint identification
2.Viewpoint structuring
3.Viewpoint documentation
4.Viewpoint system mapping
2. Scenarios
o Event scenarios
o Use cases
3.Ethnography
Requirements Validation
Different types of checks carried out on the requirement during
validation are:
Validity checks
Consistency
Completeness
Realism checks
Verifiability
Requirement validation techniques are:
Requirement review
Reviewers check for :
o Verifiability
o Comprehensibility
o Traceability
o Adaptability
Prototyping
Test case generation
Automated consistency analysis
Requirements Management
1. Enduring and Volatile requirements
Enduring requirements
Stable requirements related directly to the domain of the
system.
Volatile requirements
Changes during system development or after the system
have been put into operation.
2. Requirements Management Planning
During requirement management stage decide on
Requirements identification
A change management process
Traceability policies
CASE tool support
There are three types of traceability information
Source traceability information
Requirements traceability information
Design traceability information
Requirements management tools is required for:
Requirements Storage
Change Management
Traceability Management
3. Requirements Change Management
There are 3 principal stages to a change management process:
Problem analysis and change specification
Change analysis and costing
Change implementation
7. Explain in detail about Functional Modeling.
This model describes the computations that take place within a system.
This model is useful when the transformation from the inputs to outputs is
complex.
The functional model of a system can be represented by a data Flow
Diagram (DFD).
Data Flow Diagrams/Data Flow Graph/Bubble chart
A DFD is a graphical representation that depicts the information flow and the
transforms that are applied as the data move from input to output.
Level 0 DFD also called as fundamental system model or context model
represents the entire software as a single bubble with input and output indicated by
incoming and outgoing arrows.
Level 1 DFD contains 5 or 6 bubbles. Each bubbles can be refined at Layers to
depict more details.
Extensions to Real Time Systems
Ward and Meller extensions
Data and control flow using ward and mellor extensions-diagram
Hatley and Pirbhai extension.
Relationship between data and control models
UNIT III
1. Explain the design steps for transform mapping.
Review the fundamental system model.
Level0 DFD for safe home-Diagram
Level1 DFD for safe home-Diagram
Review and refine the data flow diagrams for the software.
Level2 DFD for safe home-Diagram
Determine whether the DFD has the transform or transaction flow
Characteristics
Level3 DFD for monitor sensors with flow boundaries-diagram
Isolate the transform center by specifying incoming and outgoing flow
boundaries.
Perform first- level factoring.
first- level factoring-Diagram
Perform second- level factoring.
Second- level factoring-Diagram
First iteration structure for monitor sesors
Refine the first iteration architecture using design heuristics for
improved software quality
2. Explain the design steps in transaction mapping.
Review the fundamental model.
Review and refine the data flow diagrams for the software.
Determine whether the DFD has the transform or transaction flow
Characteristics
Level 2 DFD for user interaction subsystem with flow boundaries-Diagram
Identify transaction center and the flow characteristics along each of the
action paths.
Map the DFD in a program structure amenable to transaction processing.
Factor and refine the transaction structure and the structure of each
action path.
Diagram for first level factoring of user interaction system.
Refine the first iteration architecture using design heuristics for
improved software quality.
Diagram for first iteration structure of user interaction system.
3. Explain in detail the design concepts.
Abstraction
Functional or Procedural abstraction
Data abstraction
Control abstraction
Refinement
Modularity
5 criteria to define a effective modular system
Modular decomposability
Modular composability
Modular Understandability
Modular Continuity
Modular protection
Software Architecture
Control Hierarchy
Structural Partitioning
Horizontal partitioning
Vertical partitioning
Data Structure
Software Procedure
Information Hiding
4. Explain the different architectural styles for software design in detail.
Data-centered architecture
Data- flow architecture
Call and return architectures
o Main program/subprogram architectures
o Remote procedure call architectures
Object oriented architectures
Layered architectures
5. Explain real time system?
Real time system is a software system where the correct functioning of the
system depends on the results produced by the system and the time at which
these results are produced.
Types
Hard real time system
Soft real time system
Real time system modeling
Real time programming
6. Explain the design principles.
The design process should not suffer from tunnel vision.
The design should be traceable to the analysis model.
Design should not reinvent the wheel.
The design should minimize the intellectual distance between the software and
problem as it exists in the real world.
The design should be structured to degrade gently, even when aberrant data,
events or operating conditions are encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is being created, not after
the fact.
The design should be reviewed to minimize conceptual (semantic) errors
7. Explain User interface design process
Diagram
Framework activities for User interface design process
1.User,task,environment analysis and modeling
2.Interface design
3.Interface construction
4.Interface validation
UNIT IV
1. Explain Black Box testing and white box-testing.
White box testing also called as Basis path testing
Flow Graph Notation
Cyclomatic Complexity
Deriving Test cases
o Using the design or code as a foundation draw a corresponding flow
graph
o Determine the cyclomatic complexity of the resultant flow graph
Determine a basis set of linearly independent paths
Prepare test cases that will force execution of each path in the basis set
Graph Matrices
Black Box testing also called as behavioral testing
Graph-Based Testing Methods
Equivalence partitioning
Boundary Value Analysis
Comparison Testing
Orthogonal Array Testing
2. Explain about the software testing strategies.
Verification and Validation. Verification refers to the set of activities that ensure
that software correctly implements a specific function. Validation refers to a
different set of activities that ensure that the software that has been built is
traceable to the customer requirements.
Organizing for software testing
A software testing strategy.
Criteria for completion of testing.
3. Different types of software testing
Unit testing
Unit Test Considerations
Unit Test Procedures
Integration Testing
Top-down Integration
Bottom-up Integration
Regression testing
Smoke Testing
Integration Test Documentation
Validation Testing
Validation Test Criteria
Configuration Review
Alpha and Beta Testing
System Testing
Recovery Testing
Security Testing
Stress Testing
Performance Testing
UNIT V
1. Describe the activities of SCM in detail.
Baselines
Software Configuration Items
SCM Activities
Identification of objects
Version Control
Change control
Configuration audit.
Status reporting
1.Explain the different Software Cost Estimation Models.
Function Point Model
Diagram-function point model-a general scheme
i. Determine a number of items occurring in the system.
ii.Unadjusted Function count is calculated by UFC=item
i
w
i
iii.Function point FP=UFC * TCF where TCF is Technical complexity factor.
TCF=0.65+0.1f
i
COCOMO Model
Constructive Cost Model.
Software cost estimation gives the estimation of how much months a man
take to develop a software product.
Application Composition Model.
Early design stage model
Post-architecture stage model.
COCOMO II application composition uses object points.
OP=(object point)X[100-%reuse)/100]
NOP-New Object Point.
Productivity Rate, PROD=NOP/person-Month.
Delphi Method
Procedure
The co-ordinator presents a specification and estimation form to each expert.
Co-ordinator calls a group meeting in which the experts discuss estimation
issues with the coordinator and each other.
Experts fill out forms anonymously.
Co-ordinator prepares and distributes a summary of the estimates.
The Co-ordinator then calls a group meeting.In this meeting theexperts mainly
discuss the points where their estimates vary widely.
The experts again fill out forms anonymously.
Again co-ordinator edits and summarizes the forms,repeating steps 5
and 6 until the co-ordinator is satisfied with the overall prediction
synthesized from experts.
4. Explain about Architectural Evolution in detail
Reasons to change from centralized to distributed client-server systems are:
o Hardware costs
o User interface expectations
o Distributed access to systems
5 layers of a distributed model
o Presentation layer
o Data Validation layer
o Interaction control layer
o Application service layer
o Database layer
User interface distribution
Two implementation strategies for user interface distribution:
o Use Window management system
o Use WWW browser
5. Discuss about Software maintenance.
Software maintenance
Three different types of software maintenance
Maintenance to repair software faults.
Maintenance to adapt the software to a different operating environment.
Maintenance to add to or modify the systems functionality.
Key factors that lead to higher maintenance cost are:
Team stability
Contractual responsibility
Staff skills
Program age and structure
Maintenance Process
Maintenance Prediction
Metrics useful for assessing maintainability
Number of requests for corrective maintenance
Average time required for impact analysis
Average time taken to implement a change request
Number of outstanding change requests
6. Explain the scheduling of software project
Scheduling is an activity that distributes estimated effort across the planned
project duration by allocating effort to specified software engineering tasks.
Scheduling methods
* Program evolution and review technique (PERT)
*Critical Path Method (CPM)
Timeline chart
Tracking the schedule
Time boxing
7. Explain in detail Earned value analysis(EVA)
A Quantitative technique for assessing progress and percent of completion of the project.
Determine BCWS(Budgeted cost of work scheduled)
Calculate Budget at completion BAC=BCWS
k
Determine Budgeted cost of work performed(BCWP)
Calculate Progress indicators
Schedule performance index SPI=BCWP
BCWS
Schedule variance SV=BCWP-BCWS
Percent scheduled for completion =BCWS/BAC
Percent complete =BCWP/BAC
Determine Actual cost of work performed(ACWP)
Cost performance index CPI=BCWP/ACWP
Cost variance CV=BCWP-ACWP
8. Explain about Halsteads software science measure.
Program length
Estimated Program length N=N
1
+N
2
N
1
-Total number of operands
N
2
-Total number of operands
Actual program length N=
Program volume measure
Potential volume measure
Program level
Effort and time measure
.