DEPARTMENT OF BCA

III YEAR
SOFTWARE ENGINEERING

Unit-1:
Introduction to Software Engineering Some definition – Some size factors
– Quality and productivity factors – Managerial issue. Planning a Software
Project: Defining the problem – Developing a solution strategy – planning the
development process – planning an organization structure – other planning
activities.

Unit-2:
Software Cost Estimation: Software – Cost factors – Software cost
estimation techniques – specification techniques – level estimation – estimating
software maintenance costs.

Unit-3:
Software requirements definition: The software requirements specification
– formal languages and processors for requirements specification.

Unit-4:
Software Design: Fundamental Design concepts – Modules and
modularizing Criteria – Design Notations – Design Techniques – Detailed
Design Consideration – Real time and distributed system design – Test plan –
Mile stones walk through and inspection – Design guide lines.

Unit-5:
Verification and validation techniques: Quality assurance – Static analysis
– symbolic exception – Unit testing and Debugging – System testing – Formal
verification.

Software maintenance: Enhancing maintainability during development –

Managua aspects of software maintenance – Configuration management –
source code metrics – other maintenance tools and techniques.
 UNIT I
2 MARKS
1. What are large projects?(A11,N15)
 No. of Programmers : 5 to 20
 Duration : 2 to 3years
 Product Size: 50,000 to 1 lakh source lines.
 Packaged in several sub systems.
 Examples: Compilers, Small time sharing systems, database packages, graphic packages and
real time control systems.
2. Define robustness.(A11,N15)
 Time to restart after failure.
 Percentage of events causing failure.
 Probability of data corruption on failure.
3. Define Software Reliability.( N11,N13,A14)
 The ability of a program to perform a required function and their stated conditions for a
stated period of time.
4. List down any four factors to consider in setting project goals. ( N11)
 New capabilities to be provided
 Old capabilities to be enhanced
 Efficiency requirements
 Reliability requirements
 Portability requirements
 Likely modifications
5. Write a note on: Hierarchical Team Structure. ( N11,N14,A15)
 In combines the aspects of the democratic team and chief programmer team.
 Each team should be limited to not more than 5 or 17 members for effective coordination
and communication.
6. Define Project Plan. (A12,N12)
 Contains lifecycle model to be used.
 Organizational structure.
 Basic development schedule, resource estimate, staffing requirements, tools and techniques
to be used.
 Time and cost are basically calculated because it is not possible to estimate exactly without
doing basic design.
7. What are the layers of software engineering?(A12,N12,A13)
 Tools.
 Methods.
 Process.
 A Quality focus.
8. Mention any two important general skills of a good software engineer.(A13)
 Good Communications.
 Knowledge of application area.
 Problem solving skills.
 Inter personnel communication skill.
9. Define : Project Scheduling.(A13)
 Software project scheduling distributes estimated effort across the planned project duration
by allocating the effort to specific tasks.
 During early stages of project planning, a macroscopic schedule is developed identifying all
major process framework activities and the product functions to which they apply.
 Later, each task is refined into a detailed schedule where specific software tasks are
identified and scheduled.
10. What are Small Projects?(N13)
 No. of programmers : 1
 Duration : 1 to 6 months
  Product Size : 1000 to 2000 source lines
 Packaged in 25 to 50 subroutines.
 Example: Scientific applications written by engineers to solve numerical problems.
11. What are Utility Programs?(N13)
 It includes compilers, Assemblers, linkage Editors and loaders.
 They may be written in high level language or Assembly language.
12. List any FOUR factors that influence quality and productivity.(A14)
 Individual ability
 Team communication.
 Product complexity
 Change control
 Level of Technology.
13. What are Democratic Teams?(N14)
 This team was first described as egoless team.
 Group leadership rotates from member to member based on the task to be performed and the
differing abilities of the team members.
14. Define : Software Engineering.(N14,A15,A16)
Software engineering is the technology and managerial discipline concerned with systematic
production and maintenance of software products that are developed and modified on time and
within cost estimates.
15. What is meant by portability?(N14,A16)
Effort required porting an application from one system to another.
16. List the Project Size Categories. (A16).
 Trivial Project
 Small Project
 Medium Size Projects
 Large Size Projects
 Very Large Projects
 Extremely Large Projects.

5 MARKS
1. Discuss about some factors to consider in project planning.(A11,A12,N14)
 Estimations techniques to be used accuracy required.
 Life-cycle model, control functions and reviews.
 Organizational structure.
 Level of formality in specification, test plans, etc.
 Level of verification and validation.
 Level of configuration management requirement.
 Level of quality assurance requirement.
 Follow on maintenance responsibilities.
 Tools to be developed and used.
 Personnel recruitment and training.

2. Write a short note on programming team structure.(A11,N15,A16)

Every programming team must have an internal structure. Team structure depends on the
nature of the Project and the product. Basic team structure includes: Democratic Team, Chief programmer
Team and Hierarchical Team.

(i)Democratic team
This team was first described as egoless team.
Group leadership rotates from member to member based on the task to be performed and the
differing abilities of the team members.
A Democratic team differs from an egoless team is that one team members is designated as team
leader and occupies the position of first among equals.
 This is because a team functions best when one individual is responsible for coordinating team
activities and for making final decision.
Advantages:
Opportunities for each team members to contribute to
decision.
To learn from one another.
Increased job satisfaction.
Non-threatening work environment.

Disadvantages:
Week of individual and authority.
(ii)The chief programmer team:
These teams are highly structured.
The chief programmer -design the product.
Implement critical parts of the product.
Makes all the major technical decision.
Work is allocated to the individual programmer by the chief programmers.
A program librarian maintains program listing, design documents, test plans etc., in a central
location.
The chief programmer is assisted by an administrative
program manager.

Advantages:
Centralized decision making.
Reduced communication paths.
Chief programmer is assisted and supported by other team
members.
Ex: doctors, surgeon.
(iii)Hierarchical team:
In combines the aspects of the democratic team and chief programmer team.
Each team should be limited to not more than 5 or 17 members for effective coordination and
communication.
This structure occupies a middle position between the extremes of Democratic teams and chief
programmer teams.
The Project needed assigns, task, attends, reviews, detects problem areas, balances the word load
the participate in technical activities.
This structure limits the number of
communication paths in the Project.

Disadvantages:
The most technical competent programmer
tends to be promoted in to management positions.
Promotion of the best programmer has the
two negative effects.
Losing a good programmer.
Creating a poor manager.

3. Discuss about the size categories for software products. (N11,A13,A14,A15,A16)

CATEGORY NO. OF PROGRAMMERS DURATION PRODUCT SIZE
Trivial 1 1-4 wks 500 source line

Small 1 1-6 mon 1K-2K

Medium 2-5 1-2 yrs 5K-50K

 Large 5-20 2-3 yrs 50K-100K

Very Large 100-1000 4-5 yrs 1M

Extremely Large 2000-5000 5-10 yrs 1M-10M

Trivial Project:
No. of programmers: 1
Duration: for a few days, few weeks
Product Size: 500 source line
Packaged in: 10 to 20 subroutines
 These Programs are often personal software.
 Developed exclusively for the use of the programmer.
 Small amount of formal analysis, elaborate design documentation, extensive test planning or
supporting documents are needed.
Small Project:
No. of programmers: 1
Duration: 1 to 6 months
Product Size: 1000 to 2000 source lines
Packaged in 25 to 50 subroutines
Small Programs usually have no interactions with other programs.
 Scientific applications written by engineers to solve numerical problems.
 Students Projects written in compiler and Operating System.
 Small Project requires little interactions between programmers and customers.
 Standardized techniques and notations, standardized documents and systematic project
reviews should be used in small projects.
Medium Size Projects:
No. of Programmers: 2 to 5
Duration: 1 to 2 years
Product Size: 10,000 to 15,000 source lines
Packaged in 250 to 1000 routines.
 Medium size projects include assemblers, Compilers, Small management information
system, inventory system and Process control applications.
 To develop such programs, interaction among programmers and Customers is required.
 A certain degree of formality is required in planning, documents and project reviews.
 Most application programs and System programs are developed in 2 years or less by 5.
Larger Size Projects:
No. of Programmers: 5 to 20
Duration: 2 to 3years
Product Size: 50,000 to 1 lakhs source lines.
Packaged in several sub systems.
Large programs have significant interactions with other programs and subsystems.
 Compilers, Small time sharing systems, database packages, graphic packages and real time
control systems.
 Communications among programmers, managers, customers are needed.
 The larger project requires more than 1 programming team.
 Example, three teams of 5 persons each.
 It involves more than 1 level of management.
 Systematic process standardized documents and formal reviews are essential.
Very Large Projects:
No. of Programmers: 100 to 1000
Duration: 4 to 5 years
Product Size: 1 million source lines
 It consists of several major subsystems each of which forms a large system.
 The subsystem has complex, interactions with one another and with other separate we
developed system.
 Telecommunication and multitasking.
  It includes large OS, large database system and military command or/and control system.
Extremely large Projects:
No. of Programmers: 2000 to 5000
Duration: 5 to 10 years
Product Size: 1 million to 10 million source lines
 It consists of several very large subsystems.
 It involves real time processing, telecommunications, multitasking and distributed
processing.
Example: Air traffic control, military command or control system.

4. Write a note on Project structure. (N11, N13, N14)

a. Project format
It involves assuming a team of programmers. Project team members do
1. Product definition
2. Design the product
3. Implement it
4. Test it
5. Conducts Project review
6. Preparing supporting document.
Project Team members typically work on a project for 1 to 3 years and are assigned to
new projects on completion of the current one.
b. Functional format:
 In this approach a different team of programmers perform each phase of the
Project.
 The work products pass from team to team as they evolved.
 Functional format involves 3 teams
 An analysis team.
 A design team and implementation team.
 Test formatting and maintenance team.
c. Matrix format
 In this format each of the functions has its own management team.
 This format involves a group of specialist personnel concerned only with that
function.
 Each development project has a project manager concerned only with that Project.
 The Project manager generates and reviews documents.
 Each functional group participates in each Project.
 Ex: software development team members belongs to the development function
similarly testing belong the testing function.

5. What are the quality and productivity factors or Explain 8 factors of quality and
productivity (N12, A11, N14, A16).
Development and maintenance of software product are complex task.
There is a fundamental difference between writing a small program for PC and developing or
modifying a software product.
Software Quality and programmer productivity can be improved by improving the process used
to develop and maintain software products.
Individual Ability:
Production and maintenance of software products are labor intensive activities.
Productivity and Quality are direct functions of individual ability and effort.
There are two aspects of ability: (i) General competition of the individual
(ii) Familiarity of the individual with the particular application area.
Team communication:
Programming has regarded as an individual and private activity.
Programmers are rarely preceded as public documents and they rarely discuss the exact details
of the work in a systematic manner.
There are 3 levels of product complexity:
 1. Application Programs
2. Utility Programs.
3. System level Programs.
Appropriate Notations:
In software engineer the representation schemes have fundamental importance, programming
languages provides compact notations for the implementation phase of software development.
Systematic Approaches:
In every field there are certain accepted procedures and techniques
A Single approach to software development and maintenance will not be adequate to cover all
situations.
Change Control:
The flexibility of software is a great strength and also a great source of difficulty in software
engineering.
Level of Technology:
It includes factors such as programming language.
Machine Environment.
The Programming Practices Software tools
Level of Reliability:
Every software product must possess basic level of reliability.
Both human and machine resources are required to obtain increased reliability.
Problem Understanding:
Failures to understand the true nature of the problem to be solved is a common and difficult
issue.
Often the customer does not truly understand nature of the problem.
Available Time:
Determining optimum staff in levels and proper elapsed times for various activities in software
product development is an important and difficult aspect of cost and resource estimation.
Required Skill:
Software Engineering requires a vast range of skills.
Good Communications
Knowledge of application area.
Facilities and Resources:
Work related factors such as good machine access and quiet place to work are more important.
Software project managers must be effective in dealing with the factors that motivate the
programmers to maintain high product quality, high programmer productivity and high job
satisfaction.
Adequacy of Training:
Express oneself clearly in English.
Develop and Validate software requirements and design specifications.
Management Skills:
Many of the problems in software project management are unique.
Managers experienced in management of computer hardware projects find software project
management to be difficult.
Appropriate Goals:
Primary Goal of software engineering is to development of software products for their intended
use.
Every software product must provide optimal level of: 1. Generality
2. Reliability
3. Efficiency
Raising Expectations:
There are two interrelated aspects of raising expectations
1. How much functionality, reliability and performance can be provided by a given amount of
development effort.
2. Issues of fundamental limitations of software technology.

6. What is meant by solution strategy? How to develop it?(N13)

  A solution strategy is not a detailed solution plan, but rather a general statement
concerning the nature of possible solutions.
 Strategy factors include considerations such as batch or time-sharing; database or file
system; graphics or text; and real-time or off-line processing.
 One or more solution strategies must be chosen by the planners in order to perform
feasibility studies and prepare preliminary cost estimates.
 The best strategy is a composite of ideas from several different approaches.
 The feasibility of each proposed solution strategy can be established by examining
solution constraints; the constraints prescribe the boundaries of the solution space.
 A solution strategy is feasible if the project goals and requirements can be satisfied.
 Techniques for determining the feasibility of a solution strategy include case studies,
worst-case analysis, simulation and construction of prototypes.
 When rejecting the other strategies need to document the reason for it.
 A solution strategy should include a priority list of product features.

7. Discuss briefly on: Managerial Issues. (N15).

Success of Software project involves
Technical Activities
Managerial Activities
Managers Control
1. Resources
2. Environment
Important manager’s responsibility:
 Software product delivered on time.
 Software working according to customer’s wish.
 Software within cost estimates.
Other managerial responsibility:
 Business Plans.
 Recruiting customers.
 Developing Marketing Strategies.
 Recruiting and training employees.
Important Problems:
 Planning is poor.
 Selections for project managers are poor (i.e) Procedures and Techniques.
 Description of project is poor.
 Estimation of resources for software project is poor.
 Success criteria are inappropriate.
 Decisions rules are poor (for selecting the proper organizational structure, correct
management techniques).
 Procedures, methods and techniques are not readily available.
Problem Solving:
 Educate and train: Top Management, Project and Software Developers.
 Analyze the data from previous software project to find effective methods.
 Define Objectives, Quality.
 Establish success priority criteria.
 Development cost is accepted by managers and customer.
 Specific Work Assignment to S/W developers.
 Selection of project managers, Technicians and procedure are became careful.

8. How programmers spend their times. (N17)

Bell Lab study (1964, 70 programmers) by Bairdain
Writing Programs 13%
Reading programs and manuals 16%
Job communication 32%
Personal 13%
Miscellaneous 15%
 Training 6%
Mail 5%
But view of Boehm
Major reason for under estimating the cost of software projects are failure to account for the 39%
overhead time for programmers and reading of a programs and manuals.
Approximately 40% of project effort involved activities such as reading, reviewing, meeting and
fixing.
By the conclusion of Boehm programmers spend their times of 60%.

10 MARKS
1. Explain the steps required to plan a s/w project.(N11,A12)
Planning a software product:
Goals can be formulated using concise statement, constraints.
Goals apply to both development process and work product.
It can be either qualitative or quantitative.
Every development process should provide product on time and within cost estimates .
Opportunities for project personnel to learn new skill.
Requirements include:
Functional requirements.
Performance requirements.
Requirements for hardware, software and firmware and user interface.
Development standards and quality assurance standards for both project and product.
Qualified requirements
Phase accuracy shall be within 0.5 degree.
Response to external interrupts shall be 0.25 second maximum.
50KB of primary memory, excluding file buffers.
Full operation 95% of each 24 hour period.
Qualitative requirements
Accuracy shall be efficient.
Provide real-time response.
Efficient use of primary memory.
95% reliable.
Planning the development process: Note: (Explain any one of the s/w lifecycle model)
Software life cycle activities
1. Define
2. Develop
3. Test
4. Deliver
5. Operate
6. Maintain.
Life cycle activities are given above. These activities are change no single life cycle models are
used.
Different models are used for various software products.
A life cycle model that is understood and accepted by all concerned parties improves project
communications and project manageability, resource allocations, cost control and product quality.

2. Plan an organization structure.(N12)

Planning an organizational structure:
Contains various task include
1. Planning
2. Product development
3. Services
4. Publications
5. Quality assurance
6. Support and maintenance
Planning task identifiers:
External customers.
 Internal product needs
Conducts feasibility study.
Development Task Identifiers:
Design.
Implements.
Debug.
Test and integrate the product.
Service task provides:
Automated tools and computer resources for all other task.
Performs configuration.
Product distribution.
Publication task develops:
Users manual.
Installation instruction.
Principles of operation.
Supporting documents.
Quality assurance task provides:
Independent evaluation of source code.
Publications prior to releasing them to customer.
Support task:
Promotes the product.
Trainers user.
Installs the product.
Maintenance task provides:
Error connection.
Enhancement.

Methods for organizing these tasks include:

a. Project format
It involves assuming a team of programmers. Project team members do
1. Product definition
2. Design the product
3. Implement it
4. Test it
5. Conducts Project review
6. Preparing supporting document.
Project Team members typically work on a project for 1 to 3 years and are assigned to
new projects on completion of the current one.

b. Functional format:
 In this approach a different team of programmers perform each phase of the Project.
 The work products pass from team to team as they evolved.
 Functional format involves 3 teams
 An analysis team.
 A design team and implementation team.
 Test formatting and maintenance team.

c. Matrix format
 In this format each of the functions has its own management team.
 This format involves a group of specialist personnel concerned only with that
function.
 Each development project has a project manager concerned only with that Project.
 The Project manager generates and reviews documents.
 Each functional group participates in each Project.
 Ex: software development team members belongs to the development function
similarly testing belong the testing function.
3. Prototype life cycle model(N13, A13)
 Importance to the sources of product request, go/no go decisions points and the use of the
prototypes.
 Prototype is a mock up or model of the Software product.
 A prototype incorporates components of the actual model.
 There are several reasons for developing a prototype.
Important reason:
 It illustrates input data formats, messages, reports and interactive dialogues for the
customer.
 To explore technical problems in the proposed system.
 In situations where phased model of analysis, design, implementation is not appropriate.

4. Explain the Cost model (N15, A13).

This Cost model is used specify the cost of performing various activities in a Software
project.
The cost of conducting a Software project is the sum of the cost involved in conducting each
phase of the project.
The cost involved each phase includes:
The cost of performing the process. Preparing the products of the phase.
Plus the cost of verifying the product of the present phase is complete and consistent with
the previous phase.
Cost of producing system definition and project plan =performing planning functions and
preparing documents+ cost of verifying the system definition and project plan.
Cost of SRS= Cost of requirements definition and document + Cost of modifying system
definition and project plan + Cost of verifying SRS is complete and consistence.
Cost of design= Cost of preparing design specification and test plan+ Cost of modifying and
correcting the system definition, project, SRS(Software requirement specification)+cost of
verifying design.
Cost of product implementation= Cost of implementing documenting, debugging and unit
testing of source code+ Cost of users manual, verification plan, maintenance procedure,
initialization and training instructions+ Cost of modifying and correcting system definition,
project plan, SRS, design specification, verification plan+ the Cost of verifying the
implementation is complete and consistent.
Cost of system test= Cost of planning and conducting the test+ Cost of modifying and
correcting the source code+ Cost of verifying the test.
Cost of maintenance Software= Cost of performing product enhancement +making adaptation to
new processing requirements and fixing bugs.
5. Phased model of life cycle(A14, A13)
The phased lifecycle model:
Series of successive activities.
Requires well defined input, process and results in well-defined output.
Resources are required to complete each phase.
Application of explicit methods, tools and techniques.
Analysis consist of two sub phases
Planning.
Requirements definition.
This phase includes:
Understanding the customer problem.
Performing a feasibility study.
Developing solution strategy
Acceptance criteria
Planning the development process.
The products of planning are
System definitions.
Project plan.
System definitions:
Expressed in English or some other language.
It includes charts, figures, graphs, tables, and equations.
Project plan:
Contains lifecycle model to be used.
Organizational structure.
Basic development schedule, resource estimate, staffing requirements, tools and techniques
to be used.
Time and cost are basically calculated because it is not possible to estimate exactly without
doing basic design.
Requirements definitions:
It includes basic functions of software components in hardware, software, and people
subsystem.
The product of requirements definition:
The product of requirements definition is a specification that describes.
The processing environment.
The required software functions.
Performance constraints on the software.
Exception handling.
Acceptance criteria.
Design phase:
In the phased model, software design follows analysis
Design phase identified software components
1. Functions.
2. Data streams
3. Data stores
It specifies relationship among components.
It specifies software structures.
Maintains a record of design decision.
Blueprint for the implementation phase.
Design phase consist of
1. Architectural design.
2. Detailed design.
Architectural design:
It involves identifying the software components dividing them into software modules and
conceptual data structures, specifying interconnection among components.
Detailed design
It is concerned with the details of “how to”
Package the processing modules.
Implement the processing, algorithm, data structures and interconnection among modules.
Implementation phase:
It involves translation of design specification into source code and debugging,
documentation and unit testing of source code.
 UNIT II
2 MARKS
1. List the major factors that influence software cost. (A11, N11, N12).
 Program ability
 Product complexity
 Product size
 Available time
 Required reliability
 Level of technology

2. Define work breakdown structure. (A11, N11, N14, A16).

A bottom-up estimation tool.
WBS is a hierarchical chart that accounts for the individual parts of the system.

3. What is Project Estimation? (A12,N12)

The size, complexity and stage of the project will impact greatly on the level of accuracy
required, the amount of cost and time the business can commit to project estimation and the level of
understanding and clarity of the scope of the project. It is therefore important to align the project
estimation requirements to the required accuracy and stage of the project.

4. What is meant by Software cost? (N12).

Software cost is the cost for development and maintenance of the software product.
Software costs more to maintain than it does to develop. For systems with a long life, maintenance
costs may be several times development costs.

5. Define Process specification. (N12).

A process specification is a method used to document, analyze and explain the decision-
making logic and formulas used to create output data from process input data. Its objective is to
flow down and specify regulatory/engineering requirements and procedures

6. What is COCOMO? (N14, A15, N15).

 The constructive cost model (COCOMO) is an algorithmic cost model described by
Boehm.
 In COCOMO model the equation calculates the programmer month and
development schedule are used for the program unit based on the number of deliver
source instruction(DSI)

7. Define Top down estimation. (A15).

 It focus on system level cost such as computer resources personnel level required to
develop the system

8. Write a short note on: Expert Judgment. (N15).

 Expert judgment relies on the experience background and business sense of one or
more key people in an organization mode.

5 MARKS
1. Write a short note on staffing – level estimation. (A11, A13, N12).
 STAFFING LEVEL ESTIMATION
 The number of personnel required throughput a software development project is not
constant.
 Planning an analysis is performed by a small group of people.
 Architectural design by a larger or smaller group.
 Detailed design by a larger number of people.
 Implementation and system testing requires the largest number of people.
  In 1958 modern observed that research and development project follows a cycle of
planning, design, prototype development and use with corresponding personnel
utilization.
 RAYLEIGH EQUATION:
 Any particular point on the Rayleigh curve represents the number of fulltime
equivalent personnel required at the instant in time
 Rayleigh curve is specified by two parameters
o td-the time at which the curve reaches its maximum value
o k-the total area under the curve (i.e.,) the total effort required for the
project
 In 1976 Putnam studied 50 army software life cycle using Rayleigh curve.
 From his observation, Rayleigh curve reaches its maximum value td, during
system testing and product release for many software products.
 From Boehm observation: Rayleigh curve is an accurate estimator of personal
requirements for the development cycle from architectural design through
implementation and system testing.
FSP=PM (0.15TDEV+0.7t) - (0.15TDEV+0.7t) ^2
(0.25(TDEV) ^2 0.15(TDEV) ^2

2. Explain how you estimate Software maintenance costs. (N12,N15)

 ESTIMATING SOFTWARE MAINTENANCE COST
Software maintenance cost requires 40 to 60%of the total life cycle devoted to software
product. In some cases it may be 90%.
Maintenance activities include
1. Enhancement to the product.
2. Adapting the product to new processing environment.
3. Correcting problems.
4. Distribution and maintenance activities includes.
Enhancement-60%,
Adaptation-20%
Error correction- 20%
During planning phase of the software project the major concerned about the maintenance are
(i) Estimating the number of maintenance programmers that will be needed.
(ii) Specifying the facilities required for maintenance.
A widely used estimators of maintenance personnel is the number of source lines that can be
maintained by an individual programmers
 LIENTZ AND SWANION OBSERVATION
Maintenance programmers in a business data processing instillations maintains 32K
Full time software personnel needed for software maintenance can be determined by dividing
the estimated number of source instructions to be maintained by the estimated number of instruction
that can be maintained by a maintenance programmer
For example if a maintenance programmer can maintain 32KDSI 2 maintenance programmer
are required to maintain
64KDSI, FSPM= (64KDSI)/ (32KDSI/FSP) =2FSPM
Boehm suggest that maintenance effort can be estimated by use of an activity ratio, which is the
number of source instructions to be added and modified in any given time period divided by the total
number of instructions
Step: 1 ACT= (DSI added + DSI modified)/DSI total)
Step: 2 PM=ACT*MMdev
Step: 3 PMm=ACT*EAF*Mmdev

10 MARK
1. Cost Estimation Techniques. (A12,A14,N15) (OR)
Define work breakdown structure. (A15)
Write any one software cost Estimation Techniques. (A16) (OR)
Discuss in detail COCOMO. (N11, A11, A13) (OR)
Explain about Delphi Cost Estimation Techniques. (N11, N14).
Software cost estimates based on past performance. Historical data are used to identify cost
factors and determine relative factors.
Cost estimates can be either: (I) Top-down cost estimation.
(II) Bottom-up cost estimation.
(I)Top-down cost estimation.
It focus on system level costs, such as computing resources and personnel required
to develop system, Quality assurance training.
(II) Bottom-up cost estimation.
It estimates the cost to develop each module or sub system. It focuses on system
level costs and some of modules developed. Cost estimation techniques are:
1. Expert Judgment.
2. Delphi cost estimation.
3. Work breakdown structure.
4. Algorithmic cost model (COCOMO).
1. Expert Judgment:

Most widely used cost estimation techniques (top down)

Expert judgment relies on the experience background and business sense of one or more key
people in an organization mode. Eg: an expert might arrive at a cost estimate in a following manner.
i) To develop a process control system
ii) It is similar to one that was developed last year in 10 months at a cost of one million
dollar.
iii) It was not a respectable profit.
iv) The new system has same control functions as the previous but 25%more control
activities.
v) So the time and cost is increased by 25%.
vi) The previous system developed was the same.
vii) Same computer and controlling devices and many of the same people are available
to develop the new system therefore 20% of the estimate is reduced.
viii) Resume of the low level code from the previous reduces the time and cost estimates
by 25%.
ix) This results in estimation of eight lakhs $ and eight months.
x) Small margin of safety so eight lakhs 50,000$ and nine months development time.
xi) Advantage: experience.

2. Delphi cost estimation:

This technique was developed at the rand corporation in 1948.

This technique can be adapted to software estimation in the following manner.
1. A co-ordinate was developed at the rand corporation in 1948.
2. Estimators study the document and complete their estimates.
3. They ask questions to the co-ordinate but they won’t discuss with one another.
4. The co-ordinate prepares and distributes a summary of the estimator’s response.
5. The estimators complete another estimate from the previous estimator.
6. The process is iterated for as many as required

3. Work breakdown structure (WBS):

A bottom-up estimation tool

WBS is a hierarchical chart that accounts for the individual parts of the system.
WBS chart can indicate either product hierarchy or process hierarchy.
 It identifies the product components and indicates the manner in which the
components are interconnected.

PRODUCT HIERARCHY:
 Product hierarchy identifies the product components and indicate in which manner
the components are interconnected.
 A WBS chart of process hierarchy identifies the work activities and the relationships
among those activities.
 Using WBS techniques, costs are estimated by assigning costs to each individual
component in the chart and summing costs.
Product

Input Transform Output

System subsystem subsystem

Data Result
Read Parser validator
module computer

PROCESS HIERARCHY:
It identifies the work activity and relationship among those activities.
Using WBS costs are estimated by assigning cost to each individual component in the chart and
summing the cost.
WBS are the most widely used cost estimation techniques.

Process

Project System Services

Dvmt. QA
Mgmt. test

Plan Receive Desig Code Integrat Computer Public

Unit Accept
and Audit n debug Test ions services ation
 4. Algorithmic cost model (COCOMO):

Constructive cost model (COCOMO).

Algorithmic cost estimators compute the estimated cost of software system as the some of
the cost of the module this model is bottom up estimates.
The constructive cost model (COCOMO) is an algorithmic cost model described by Boehm.
In COCOMO model the equation calculates the programmer month and development.
schedule are used for the program unit based on the number of deliver source instruction (DSI).
Effort multipliers are used to adjacent the estimate for product attribute, computer,
customer, and project attribute.
The effort multipliers examine the data from 63project and by using Delphi technic.
The COCOMO equation incorporates a number assumption. For eg. The organic mode
application program equation applied in the following type of situation:
(i) Small to medium size project.
(ii) Familiar application area.
(iii) Stable.
(iv) In house development effort.
(v) Effort multipliers are used to modify this assumption.
It includes cost of documentation and reviews.
It includes cost of program managers and program librarian.
Software project estimated by COCOMO model include the following:
 Careful definition and validation and requirements are performed by a small
number of people.
 The requirements remain the same throughput the project.
 Definition and validation techniques of an architecture design are performed
by a small number of capable people.
 Detailed design, coding and unit testing are performed in similar by a group
of programmers working in teams.
 Interface errors are mostly found by unit testing and by inspection.
 Documentation is performed as a path of development process

Multiplier Range of values

Product attributes:
Required reliability 0.75 to 1.40
Database size 0.94 to 1.16
Product complexity 0.70 to 1.65
Computer attributes:
Execution time constraint 1.00 to 1.66
Main storage constraint 1.00 to 1.56
Virtual machine volatility 0.87 to 1.30
Computer turnaround time 0.87 to 1.15
Personnel attributes:
Analyst capability 1.46 to 0.71
Programmer capability 1.42 to 0.70
Applications experience 1.29 to 0.82
Virtual machine experience 1.21 to 0.90
Programming language experience 1.14 to 0.95
Project attributes:
Use of modern programming 1.24 to 0.82
practices
Use of software tools 1.24 to 0.83
Required development schedule 1.23 to 1.10
2. Cost factors. (N13,N14)
Explain: S/w cost factors. (N12)
Explain briefly the Software Cost and quality. (A12, N13, A14, A16).
They are many cost factors:
Most difficult task in software engineering.
Difficult to make estimate during planning phase.
Series of cost estimation.
Preliminary estimate is prepared during planning.
An improved estimate is presented at the software requirements review.
Final estimate is prepares at the preliminary design view.
MAJOR FACTORS
 Program ability
 Product complexity
 Product size
 Available time
 Required reliability
 Level of technology
 PROGRAM ABILITY
 The goal was to determine relative influence of batch and time shared access on
programmer’s productivity.
 Example: 12 experienced programmers were each given two programming problems to
solve some uses batch facilities and some using time sharing.
 Resulting differences in individual performance among the programmers were much greater
than could be attributed to the relatively small effect of batch or time shared machine
access.
 On very large projects the differences in individual programmer’s ability will tend to
average out.
 But on projects involving 5 or fewer programmers, individual difference in ability can be
significant.
 PRODUCT COMPLEXITY
 There are three categories of software products.
 Application programs-include data processing and scientific programs.
 Utility programs-it includes compilers, assemblers.
 System programs-it includes operating system, DBMS, real time system.
 Application programs are developed in environment provided by the language compilers
such as FORTRAN, Pascal.
 Utility programs are written to provide user processing environment.
 System programs interact directly with the hardware.
 Brook’s states that utility programs are three times as difficult to write as application
programs.
 System programs are three times as difficult to write as utility programs
 Product complexities are 1-3-9 for application, utility, system programs
 Boehm uses three levels of product complexity equations of total programmer month of
effort pm is provided in terms of the number of thousands of delivered source instruction,
KDSI.
 Programmer cost for the software project=the effort in programmer month*cost per
programmer month.
 In this terminology the three levels of product complexity are organic, semidetached,
embedded.
 Organic-application, entity-semidetached, embedded system.
Application program: pm=2.4*(KDSI) **1.05
Utility programs: pm=3.2*(KDSI) **1.12
System programs: pm=3.6*(KDSI) **1.20
Example: for a development of a 60,000 line application programs, utility programs and system
programs the ratio of pm: 1 to 1.7 to 2.8
The development time for a program
 Application program TDEV=2.5*(pm) **0.38
Utility programs TDEV=2.5*(pm) **0.35
System programs TDEV=2.5*(pm) **0.32
Given the total programmer months for a project and the development time the average staffing
level is obtained by
Application program:176.6pm/17.85mo=9.9 programmers
Utility program: 294pm/18.3mo=16 programmers
System program:489.6pm/18.1mo=27 programmers
Failures in estimating the number of source instructions in a software product is to under
estimate the amounts of housekeeping code require.
House Keeping Code:
Position of the source code that handles input, output, interactive user communication, error
checking and error handling.
 PRODUCT SIZE
 A large software product is more expensive to develop than a small one.
 Boehm equation indicates that the rate of increase in required effort grows with number of
source instruction at an exponential.
 Using exponents of 0.91 and 1.83 results in estimates of 1.88 and 3.5 more effort for a
product that is twice as large, and factors of 8.1 and 67.6 for products that are 10 times as
large as known product.
 These estimates differ by factors of 1.86(3.5/1.88) for products that are twice as large and
8.3(76.6/8.1) for products that are 10 times as large.

Effort equation Schedule equation Reference

PM=5.2(KDSI)**0.91 TDEV=2.47(MM)**0.35 (WAL77)
PM=4.9(KDSI)**0.98 TDEV=3.04(MM)**0.36 (NEL78)
PM=1.5(KDSI)**1.02 TDEV=4.38(MM)**0.25 (FRE79)
PM=2.4(KDSI)**1.05 TDEV=2.50(MM)**0.38 (BOE81)
PM=3.0(KDSI)**1.12 TDEV=2.50(MM)**0.35 (BOE81)
PM=3.6(KDSI)**1.40 TDEV=2.50(MM)**0.32 (BOE81)
PM=1.0(KDSI)**1.50 - (JON77)
PM=0.7(KDSI)**1.50 - (HAL77)

Depending on the exponent used we can easily be off by a factor of 2 in estimating effort for
a product twice the size of a known product and by a factor of 10 for a product 10 times the size of
known product, even if all other factors that influence cost remain constant.

 AVAILABLE TIME
Total project effort is sensitive to the calendar time available for project competition.
Software projects require more total effort, if development time is compressed or
expanded from the optional time.
According to Putnam, project effort is inversely proportional to the fourth power of the
development time E=k/(TD**4).
This formula predicts zero effort for infinite development time.
Putnam also states that the development schedule cannot be compressed below about
86%of the nominal schedule regardless of the number of people or resources utilized.
Boehm states that “there is a limit beyond which a software project cannot reduce its
schedule by buying more personnel and equipment “.
 REQUIRED LEVEL OF RELIABILITY
The ability of a program to perform a required function under stated conditions for a stated
period of time
 Accuracy
 Robustness
 Completeness
 Consistency
These characteristics can be built in to a software product.
 There is a cost associated with different has to ensure high reliability.
Product failure may cause slightly inconvenience to the user.
While failure of other products may incur high financial loss or risk to human life.
Development effort multipliers for software reliability.

Category Effect of failure Effort

multiplier
Very low Slight inconvenience 0.75
Low Losses easily recovered 0.88
Nominal Moderately difficult to recover loses 1.00
High High financial loss 1.15
Very high Risk to human life 1.40

 LEVEL OF TECHNOLOGY
In a software development required project is reflected by
1. Programming language
2. Abstract machine
3. Programming practices
4. Software tools used
Modern programming languages provides additional features to improve programmer productivity
and software reliability
These features include
1. Strong type checking
2. Data abstraction
3. Separate computation
4. Exception handling
Productivity will suffer if programmers must learn a new machine environment as part of the
development process
Modern programming practices include the use of
a) Systematic analysis and design technique
b) Structure designed notations
c) Inspection
d) Structured coding
e) Systematic testing
f) Program development library
Software tools range from elementary tools such as assemblers compilers, interactive text editors
and DBMs.
 UNIT III
2 MARKS:-
1. Write note on: petri nets. (Nov 11)
 Petri nets were invented in the 1960s by Carl Petri at the University of Bonn, West
Germany.
 They provide a graphical representation technique and systematic and systematic methods.
 It was invented to overcome the limitations of finite state mechanism.
 A petri net is represented as a bipartite directed graph.
 The two types of nodes are places and transitions.

2. What is PSL? (Nov 11)

 Problem statement language
 It was developed by proff. Daniel Teichrow at the University of Michigan.
 The problem statement analyzer (PSA) is the PSL processor.
 This model describes a system as a set of objects and each object have properties and each
property have their own values.

3. What are implicit equations? (April 11)

 It states the properties of a solution without stating a solution method.
E.g. Matrix inversion M*M’=I+E
 Matrix inversion is specified such that matrix product of the original matrix M and the
inverse of M, M yields the identity matrix I+ the error matrix e (computation error).
 Complete specification of matrix inversion must include items such as matrix size, type of
data elements etc.
 Given a complete functional specification for matrix inversion, design involves specifying a
data structure, an algorithm for computing the inverse.

4. What is PSL/ PSA.(April 11)

PSL:-
 Problem statement language
 It was developed by proff. Daniel Teichrow at the University of Michigan.
 The problem statement analyzer (PSA) is the PSL processor.
 This model describes a system as a set of objects and each object have properties and each
property have their own values.

PSA:-
 The problem statement analyzer is an automated analyzer for processing requirements stated
in PSL.
 PSA operate on a database of information collected from PSL description.
 PSA provide 4 types of categories: data-base modification reports, reference reports,
summary reports and analysis report.

5. What is requirement analysis? (Nov 12)

 The analysis phase of software development involves project planning and software
requirement definitions.
 The software requirement specification records the outcome of the software requirements
definition activity.
 SRS is a technical specification of requirements for the software products.
6. How can you elicit the software requirements? (April 12)
Format of a software requirements specification:
Section1: Product overview and summary
Section2: Development, operating, and maintenance environments
Section3: External interfaces and data flow
Section4: Functional requirements
Section5: Performance requirements
Section6: Exception handling
Section7: Early subsets and implementation priorities
Section8: Foreseeable modifications and enhancements
Section9: Acceptance criteria
Section10: design Hints and Guidelines
Section11:cross-reference index
Section12: Glossary of terms

7. Write note on: GIST. (Nov 13, Apr 14)

 GIST is a formal specification language developed at the USC/Information Science
Institute by R. Balzar and colleagues.
 GIST is a textual language based on a relation model of objects and attributes.
 A specification is composed of three parts:
1. A specification of objects types and relationships between these types.
2. A specification of actions and demons which define transition between
possible states.
3. A specification of constraints on states and state transitions.

8. What is Goals of requirements management? (April 13)

The software requirement specification is a technical specification of requirements
for the software product.
The goal of software requirements definition is to completely and consistently
specify the technical requirements for the software product in a concise and unambiguous
manner, using formal notations as appropriate.

9. What are Transition Tables? ( Apr 14)

 It is used to specify changes in the state of a system.
 Given the correct state and the current condition the next state results.
F (Ci,Sj)= Sk
Sk=next state
Ci=current condition
Sj=current state
 Given current state S1 and current input b the system will go to state S0.
 F (S1, b) =S0
 In transition diagrams state becomes nodes. In a directed craft.
 Transitions are represented as arcs between nodes.

10. List the describe properties of SRS. (Apr 14)

 A requirements for document should be:
 Correct
 Complete
 Consistent
 Unambiguous
 Functional
  Verifiable
 Traceable
 Easily changed

11. Define: Data Flow diagrams. (Nov 14)

Data flow diagram is similar to SADT actigram, but they do not indicate mechanism and control.
The data flow diagram for a software system consisting of a set of process interconnected by data
streams.
Data streams are specified using regular expressions.
Process can be described using transition table.

12. What are decision tables? (Nov 14)

It provides decision logic. The decision table is segmented into 4 quadrants:
1. Condition stub
2. Condition entries
3. Action stub
4. Action entries

13. What is RSL/REVS? (Nov 14)

The Requirements Statement Language (RSL) is developed for real-time control systems.
RSL also uses basic concepts such as elements (describe objects), attributes (describe
features of elements), relationships (describe relations between elements), and structures (consist of
nodes and processing steps).
Flow specified in RSL as required network (R-NETS). R-NETs have both graphical and
textual representation.
The requirements engineering validation system (REVS) process and analyses RSL
statements.

14. Write the goals of SRS? (Nov 15)

 The software requirement specification is a technical specification of requirements for the
software product.
 The goal of software requirements definition is to completely and consistently specify the
technical requirements for the software product in a concise and unambiguous manner,
using formal notations as appropriate.

15. What are regular expressions? (Nov 15)

Atoms: the basic symbols in the alphabet of interest from regular expression.
Alternation: if R1 and R2 are regular expression, then (R1 R2) is a regular expression.
Composition: if R1 and R2 are regular expression, then (R1 R2) is a regular expression.
Closure: if R1 is a regular expression, then (R1)*is a regular expression.
Completeness: nothing else is a regular expression.

16. What is SSA? (Nov 15)

STRUCTURED SYSTEM ANALYSIS (SSA)
 Two similar several of SSA was described by Game and Sarson and by Demarco.
 SSA is used to traditional data processing environment.
 SSA uses a graphical language to build models of systems.
 SSA incorporates databases concept.
There are 4 basic features of SSA.
 Data flow diagram
 Data Dictionaries.
 Procedure Logic Representations
 Data Store Techniques.
 5 MARKS
1. Explain the format of a software requirement specification. (April 12, April 13, April 14,
April 16, Nov 14).

Format of a software requirements specification

Section1: Product overview and summary
Section2: Development, operating, and maintenance environments
Section3: External interfaces and data flow
Section4: Functional requirements
Section5: Performance requirements
Section6: Exception handling
Section7: Early subsets and implementation priorities
Section8: Foreseeable modifications and enhancements
Section9: Acceptance criteria
Section10: design Hints and Guidelines
Section11:cross-reference index
Section12: Glossary of terms

Section 1 and 2:
It presents an overview of product features and the processing environments.
Section 3:
It includes
1. User displays
2. Report formats
3. Dataflow diagrams
4. Data dictionary
Dataflow diagram specify
 Data sources
 Data stores
 Transformations to be performed on the data.
 Flow of data
 Data stores
Data store is a conceptual data structure that is logical characteristics of data or given importance on
a dataflow diagrams.
Data stores and data sinks are depicted by shaded rectangles.
Transformations by ordinary rectangles.
Data stores by open ended rectangles
The arcs specify the dataflow.
Dataflow diagrams are not concerned with decision structure or algorithmic details like flowchart.
A data dictionary
Entries include the name of the data item and its attributes.
Section 4:
A SRS specifies the functional requirements for an software product.
It specifies the relationship among inputs, actions and outputs.
Section 5:
Specifies the performance requirements such as
1. Response time for various activities.
2. Processing time for various processes.
3. Memory constraints.
Section 6:
Specifies the exception handling.
It includes actions to be taken and the messages to be display in response to undesired situations or
events.
Possible exceptions include
1. Temporary resource failure.
2. Permanent resource failure
 3. Incorrect
4. Inconsistent
5. out of range input data and parameters.
6. Internal values.
7. Parameters.
8. Violations of capacity limits (overflow).
9. Violations of restrictions (divide by zero).
Section 7:
Specifies early subset an implementation priorities for the system under development.
Section 8:
Specifies the modification and enhancement.
Section 9:
Specifies the acceptance criteria (various test).
Section 10:
Contains design hints and guide lines.
Section 11:
Specifies cross reference index.
A cross reference directory should be provided to index to find the specific paragraph numbers in
SRS.
Section 12:
Provides definition of terms that are unfamiliar to the customers and the product developers.

2. What are the formal specification techniques? (April 13, April 14, April 15, April 16, Nov 12,
Nov 13, Nov 15).

FORMAL SPECIFICATION TECNIQUQES:-

 Functional characteristics of an software product are one of the most important activities to
be then during the requirement analysis.
 The advantage of formal notation is concise and ambiguous.
 They provide the basis for verification of the resulting software product.
 Two nations are used to specify the functional characteristics.
1. Relational Notations
Implicit equations
Recurrence relations
Algebraic axioms
Regular expressions
2. State oriented Notations
Decision tables
Event tables
Transition tables
Finite state mechanisms

RELATIONAL NOTATIONS:-
 Implicit equations
 It states the properties of a solution without stating a solution method.
E.g. Matrix inversion M*M’=I+E
 Matrix inversion is specified such that matrix product of the original matrix M
and the inverse of M (M’), yields the identity matrix I+the error matrix e
(computation error).
 Complete specification of matrix inversion must include items such as matrix
size, type of data elements etc.
 
Given a complete functional specification for matrix inversion, design involves
specifying a data structure, an algorithm for computing the inverse.
 Recurrence relations
 A Recurrence relation consist of an initial part called the basis and one or more
recursive parts.
 The recursive part describes the desired value of a function in terms of other values
of the function.

Eg. Fibonacci’s number,F1(0)=0,F1(1)=1,F1(n)=F1(N-1) belongs to F1(N*2) for all

n>1.
 Recurrence relation is easily transformed into recursive programs.
 Algebraic axioms
 Mathematical system is defined by axioms.
 The axioms specify fundamental properties of a system and provide a basis for
deriving additional properties that are implied by the axioms.
 There properties are called theorems.
 To establish a valid mathematical system, the set of axioms must be complete and
consistent.
 Regular expressions
 Regular expression can be used to specify the syntactic structure of symbol strings.
 Because many software products involve processing of symbol strings, regular
expressions provide a powerful and widely used notation in software engineering.
 Rules are:

i. Atoms: the basic symbols in the alphabet of interest from regular expression.
ii. Alternation: if R1 and R2 are regular expression, then (R1 R2) is a regular
expression.
iii. Composition: if R1 and R2 are regular expression, then (R1 R2) is a regular
expression.
iv. Closure: if R1 is a regular expression, then (R1)*is a regular expression.
v. Completeness: nothing else is a regular expression.

STATE ORIENTED NOTATIONS:-

 Decision tables
It provides a mechanism for recording complex decision logic. Decision table is
segmented into four quadrants
1. Condition stub
It contains all of the conditions being examined.
2. Condition entry
It is used to combine conditions into decision rules.
3. Action stub
It describes the actions to be taken in response to a decision rules.
4. Action entry
It relates decision rules to actions.
 Orders are approved if the credit limit is not exceeded or if the credit limit is
exceeded but past experience is good or if a special arrangement has made
otherwise the order is rejected.
 The(y, n,-) entries in each column of the condition entry quadrant form a
decision rule.
  Ambiguous pairs of decision rules that specify identical actions are said to be
redundant

 Event tables
 Event tables specify actions to be taken when events occur under different sets of
conditions.
 A two-dimensional event table relates actions to two variables.
f (M,E)=A
M denote the current set of operating conditions
E is the event of interest.
A is the action to be taken.
 Tables of higher dimension can be used to incorporate more independent variables.

 Transition tables
 Transition tables are used to specify changes in the state of a system as a function of
driving forces.
 The state of a system summaries the status of all entries in the system in a particular
time.

 Given the correct state and the current condition the next state results.
F (Si,Cj)= Sk
Sk=next state
Si=current condition
Cj=current state
 Given current state S1 and current input b the system will go to state S0.
 F (S1, b) =S0
 In transition diagrams state becomes nodes. In a directed craft.
 Transitions are represented as arcs between nodes.

 Finite state mechanisms

 Data flow diagrams, regular expressions, transition tables are combined in finite
state mechanism.
 The data flow diagram for a software system consisting of a set of process
interconnected by data streams.
 Data streams are specified using regular expressions.
 Process can be described using transition table.
 Processes split states in initial state so and wait for input D3.
 In state S2 split writes zero or more D12 messages to F7, then on receipt of the
end of data marker De. Closes F7 and returns to state so to wait for next transmit
ion.
 Limitations
Finite state mechanism is not possible for complex system. Because it
involves large no of states and many combination of input data.

3. Explain about any two Formal Languages and Processors for requirements specification.
(Nov 12,Nov 13, April 15, April 15, April 16,Nov 15, Nov 14, Nov 12).

Special purpose language and processor have been used to perform automated analysis of
requirements specifications. Some specification languages are manually applied and others having
automated processors. There are several types.
 PSL/PSA
 RSL/REVS
  SADT
 SSA
 GIST
i. PSL/PSA
The problem statement language (PSL) was developed by prof. Daniel. The problem statement
analyser is PSL processor. Both were developed as ISDOS projects. This model describes set of
objects, each object has properties, and each property may have property values. Objects may be
inter-connected. These connections are called relationships.
PSL description can be divided into 8 major categories.
 System input/output flow.
 System Structure.
 Data Structure.
 Date Derivation.
 System size and volume.
 System dynamics.
 System Properties.
 Project Management.
 System I/P or O/P deals with interaction between system and its environment.
 System Structure is concerned with hierarchies among objects in system.
 The data structure aspect includes all the relationships that exits among data used and/or
manipulated by a system as seen by the user of system.
 The data derivation an aspect of the system description specifies which data objects are
involved in particular process in system. It describes data relationships that are internal to a
system.
 The system size and volume aspect is concerned with the size of the system and those
factors that volume of processing required.
 The system dynamics aspect of a system description in which the system behaves over time.
 System properties have property value.
 The project management required that project related information. This involves
identification of people involved their responsibilities, Schedule cost estimates etc.
PSA
The PSA can provide 4 reports:
1. Database modification Report.
2. Reference Report.
3. Summary Report.
4. Analysis Report.
Structure of PSA:

i. Data base modification reports list changes that have been made since that last report, together with
warning messages. These reports provide a record of changes for error correction and recovery.
ii. Reference report includes the name list reports, which list all the objects in the database with type
and dates of last change.
iii. Summary Report lists all the total number of objects.
iv. Analysis report compares the similarity between input and output.
 ii. RSL/REVS

The Requirements Statement Language (RSL) is developed for real-time control systems.

RSL also uses basic concepts such as elements (describe objects), attributes (describe features of
elements), relationships (describe relations between elements), and structures (consist of nodes and
processing steps).

Flow specified in RSL as required network (R-NETS). R-NETs have both graphical and textual
representation.

The REquirements Validation System (REVS) processes and analyses the RSL statements. Note
that both RSL and REVS are components of Software Requirements Engineering Methodology
(SREM).
REVS operates on the RSL statements. Generally, RSL comprises the following components.

1. Translator for RSL

2. Abstract system semantic model (ASSM), which is a centralized relational database and similar
to PSL/PSA database
3. A set of automated tools, which is used for processing information in ASSM.
Some examples of automated tools are interactive graphics package, static checker, and automated
simulation package. Interactive graphics package facilitates in describing flow paths, static checker checks
the completeness and consistency of the information within the system, and automated simulation
package generates and executes simulation models of the system.
Note: REVS is a large and complex software tool. Due to this, its use is cost effective only for the
specification of large and complex real-time systems. However, the RSL notation can be applied manually
to describe the characteristics of a real time system.
 iii. SADT

Structured Analysis and Design Technique (SADT) uses a graphical notation, and is generally applied
in information processing systems.

It comprises two parts, namely, Structured Analysis (SA) and Design Technique (DT). SA describes
the requirements with the help of diagrams whereas DT specifies how to interpret the results.

The model of SADT consists of an organized collection of SA diagrams. These diagrams facilitate
software engineers to identify the requirements in a structured manner by following a top-down approach
and decomposing system activities, data, and their relationships. The text embedded in these diagrams is
written in natural language, thus, specification language is a combination of both graphical language and
natural language.

The commonly-used SA diagrams include activity diagram (actigram) and data diagram (datagram).

An activity diagram is shown with nodes and arcs. The nodes represent the activities and the arcs
describe the data-flow between the activities. Four different types of arcs can be connected to each node,
namely, input data, control data, processor, and output data.

Input data is the data that are transformed to output(s).

Control data is the data that constrain the kind or extent of process being described.

Processor describes the mechanism, which is in the form of tools and techniques to perform the
transformation.

Output data is the result produced after sending input, performing control activity, and mechanism in
a system.

A data diagram is shown with nodes and arcs, which are similar to that of an activity diagram.

The nodes describe the data objects and the arcs describe the activities. A data diagram also uses
four different types of arcs.

The arcs on the left side indicate inputs and the arcs on the right side indicate the output.

Here, input is the activity that creates a data object whereas output is the activity that uses the data
object.

The 'control activity' (arcs entering from top) controls the conditions in which the node is activated
The 'storage device' (arcs entering from bottom) indicates the mechanism for storing several
representations of a data object.
 Note: Both the diagrams, controls are provided by the external environment and by the outputs from
other nodes.

iv. SSA

It was described by Gane and Sarson. There are 4 basic features of SSA.
1. Data flow diagram
2. Data Dictionaries.
3. Procedure Logic Representations
4. Data Store Techniques.

Data flow diagram is similar to SADT actigram, but they do not indicate mechanism and
control.

Data Dictionaries is used to define and record data elements and processing logic
representations.

DATA FLOW: ORDER

COMPOSITION
CUSTOMER_IDENTITY
ORDER_DATE
ITEM_ORDER+
CATALOG_NUMBER
ITEM_NAME
UNIT PRICE
QUANTITY
TOTAL_COST

DATA STORES: ORDER_DATE

COMPOSITION
TIME
DAY
 MONTH
YEAR
NOTE: The “+” denote one or more occurrences’ of the field.

Procedure Logic Representations are used to specify processing sequence.

INITIALIZE the program

READ the first record
WHILE there are more order records DO
WHILE there are more item_order field in the order_record DO
EXTRACT the next item_ordered
IF extract item is found then
INCREMENT item occurrence count
ELSE
INSERT the extracted item into ordered table
INCREMENT occurrence count
END IF
INCREMENT item processed count
END WHILE
END WHILE
WRITE order table and item processed counter
TO batch_order file
CLOSE files
TERMINATE the program
Data Store Techniques addition notations is used to show data stores.

v. GIST
GIST is a formal specification language developed at the USC/Information Science Institute
by R. Balzar and colleagues.
GIST is a textual language based on a relation model of objects and attributes.
A specification is composed of three parts:
i. A specification of objects types and relationships between these types.
ii. A specification of actions and demons which define transition between possible
states.
iii. A specification of constraints on states and state transitions.

Preparing a GIST s specification involves several steps:

1. Identify a collection of objects type to manipulate the process.
2. Identify individual objects within values
3. Identify relationship to specify the way in which objects can be related to one another.
4. Identify the relationship can be defined.
5. Identify static constraints on types and relationships.
6. Identify actions that can change state of process.
7. Identify dynamic constraints.
8. Identify active participants in process being specified, and group them into class.