Software Engineering For MSBTE I Scheme (IV - Comp
Software Engineering For MSBTE I Scheme (IV - Comp
MSBTE - I Scheme
S.Y. Diploma Semester - IV
Computer Engineering Group & Information Technology
(CO / CM / IF / CW)
Software Engineering
Anuradha A. Puntambekar
M.E. (Computer)
Formerly Assistant Professor in
P.E.S. Modern College of Engineering,
Pune
Yogesh S. Gunjal
M. Tech (Computer Science and Engineering)
I/C Principal,
JCEI's Jaihind Polytechnic Kuran, Pune
Narendra S. Joshi
M.E. (CSE), Ph.D. (Pursuing),
HOD (Computer Engineering Department),
Assistant Professor,
Sandip Foundation's, Sandip Institute of Polytechnic (SIP),
Nashik
Yogesh B. Patil
M.Tech (I.T.), B.E. (I.T.)
HOD Computer Department,
G.M.Chaudhari Polytechnic, Shahada.
®
TECHNICAL
PUBLICATIONS
SINCE 1993 An Up-Thrust for Knowledge
(i)
Software Engineering
Subject Code : 22413
Published by :
®
TECHNICAL Amit Residency, Office No.1, 412, Shaniwar Peth, Pune - 411030, M.S. INDIA
PUBLICATIONS P h . : + 9 1 - 0 2 0 - 2 4 4 9 5 4 9 6 / 9 7 , Te l e f a x : + 9 1 - 0 2 0 - 2 4 4 9 5 4 9 7
SINCE 1993 An Up-Thrust for Knowledge
Email : [email protected] Website : www.technicalpublications.org
ISBN 978-93-332-0046-2
(iv)
Unit - III 3a. Identify the elements of 3.1 Translating Requirement model into design
Software analysis model for the given model : Data Modelling.
Modelling and software requirements. 3.2 Analysis Modelling : Elements of Analysis
Design 3b. Apply the specified design model.
feature for software 3.3 Design modelling : Fundamental Design
requirements modelling, Concepts (Abstraction, Information hiding,
3c. Represent the specified Structure, Modularity, Concurrency,
problem in the given design Verification, Aesthetics).
notation. 3.4 Design notations : Data Flow Diagram
3d. Explain the given (DFD), Structured Flowcharts, Decision
characteristics of software Tables.
testing. 3.5 Testing - Meaning and purpose, testing
3e. Prepare test cases for the methods - Black Box and White - box,
given module. Level of testing - Unit testing.
3.6 Test Documentation - Test Case Template,
test plan, Introduction to defect report, test
summary report.
Unit - IV 4a. Estimate the size of the 4.1 The management spectrum - 4P's.
Software Project software product using the 4.2 Metrics for Size Estimation : Line of Code
Estimation given method. (LoC), Function Points (FP).
4b. Estimate the cost of the 4.3 Project Cost Estimation Approaches :
software product using the Overview of Heuristic, Analytical, and
given empirical method. Empirical Estimation.
4c. Evaluate the size of the 4.4 COCOMO (Constructive Cost Model),
given software using COCOMO II.
CoCoMo model.
4.5 Risk Management : Risk Identification, Risk
4d. Apply the RMMM strategy Assessment, Risk Containment, RMMM
in Identified risks for the strategy.
given software development
problem.
Unit - V 5a. Use the given scheduling 5.1 Project Scheduling : Basic Principles, Work
Software Quality technique for the identified breakdown structure, Activity network and
Assurance and project. critical path Method, Scheduling tachniques
Security 5b. Draw the activity network (CPM, PERT).
for the given task. 5.2 Project Tracking : Timeline charts, Earned
5c. Prepare the timeline chart / Value Analysis, Gantt Charts.
Gantt chart to track progress 5.3 Software Quality Management vs. Software
of the given project. Quality Assurance
5d. Describe the given Software Phases of Software Quality Assurance :
Quality Assurance (SQA) Planning, Activities, audit, and review.
activity. 5.4 Quality Evaluation standards : Six Sigma,
5e. Describe features of the ISO for software, CMMI : Levels, Process
given software evaluation areas.
standard. 5.5 Software Security, Introduction to DevOps,
Secure software engineering.
(v)
(vi)
Table of Contents
......................................2-1
Unit - I
2.2 Core Principles . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1
Chapter - 1 Software Development Process 2.3 Communication Practices . . . . . . . . . . . . . . . . . 2 - 2
(1 - 1) to (1 - 16)
2.4 Planning Practices. . . . . . . . . . . . . . . . . . . . . . . 2 - 2
1.1 Definition of Software and Software Engineering . . 2.5 Modeling Practices . . . . . . . . . . . . . . . . . . . . . . 2 - 3
......................................1-1
2.6 Construction Practices . . . . . . . . . . . . . . . . . . . 2 - 4
1.2 Software as Layered Approach . . . . . . . . . . . . . 1 - 1
2.7 Software Deployment . . . . . . . . . . . . . . . . . . . . 2 - 5
1.3 Characteristics of Software Engineering . . . . . . 1 - 2
Part II : Requirement Engineering
1.4 Types of Software . . . . . . . . . . . . . . . . . . . . . . . 1 - 3
1.5 Software Development Framework . . . . . . . . . . 1 - 3 2.8 Requirement Gathering and Analysis . . . . . . . . 2 - 5
2.8.1 Inception. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.6 Software Process Framework . . . . . . . . . . . . . . 1 - 4
2.8.2 Elicitation . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7 Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 5
2.8.3 Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1 Perspective Process Model . . . . . . . . . . . . . 1 - 5
2.8.4 Negotiation. . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1.1 Waterfall Model . . . . . . . . . . . . . . . . . 1 - 5
2.8.5 Specification. . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1.2 RAD Model (Incremental Model) . . . 1 - 6
2.8.6 Validation. . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1.3 Spiral Model . . . . . . . . . . . . . . . . . . . 1 - 7
2.8.7 Requirement Management . . . . . . . . . . . . . 2 - 7
1.7.2 Specialized Process Model . . . . . . . . . . . . . 1 - 9
2.9 Types of Requirements . . . . . . . . . . . . . . . . . . 2 - 7
1.7.2.1 Component Based Development . . . . 1 - 9
2.9.1 Functional Requirements . . . . . . . . . . . . . 2 - 7
1.7.2.2 Formal Methods Model . . . . . . . . . . . 1 - 9
2.9.1.1 Problems Associated with Requirements.
1.8 Agile Software Development. . . . . . . . . . . . . . 1 - 10
.................................2-7
1.8.1 Agile Process and its Importance . . . . . . . 1 - 10
2.9.2 Non Functional Requirements . . . . . . . . . . 2 - 8
1.8.2 Extreme Programming . . . . . . . . . . . . . . . 1 - 11
2.9.2.1 Types of Non Functional Requirements
1.8.3 Adaptive Software Development . . . . . . . 1 - 12
.................................2-8
1.8.4 SCRUM. . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 12
2.9.2.2 Domain Requirements . . . . . . . . . . . 2 - 9
1.8.5 Dynamic System Development Method
2.9.3 Difference between Functional and Non
(DSDM) . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 14
Functional Requirements . . . . . . . . . . . . . 2 - 10
1.8.6 Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 14
2.10 Eliciting Requirements . . . . . . . . . . . . . . . . . . 2 - 10
1.9 Selection Criteria for Software Process Model 1 - 15 2.10.1 Collaborative Requirements Gathering . . 2 - 10
®
(vi)- An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
(vii)
Part III : Software Requirement Specification 4.2 Metrics for Size Estimation . . . . . . . . . . . . . . . 4 - 2
4.2.1 LOC based Estimation . . . . . . . . . . . . . . . . . 4 - 2
®
TM
1.1
1 Software Development Process
1.3 Characteristics of Software Engineering 6) Thus the failure curve looks like a spike. Thus
MSBTE : Winter-15, 17, Summer-16, 18, Marks 8 frequent changes in software cause it to
· Software is engineered, not manufactured deteriorate.
1) Software development and hardware 7) Another issue with software is that there are no
development are two different activities. spare parts for software. If hardware component
wears out it can be replaced by another
2) A good design is a backbone for both the
component but it is not possible in case of
activities. software.
3) Quality problems that occur in hardware 8) Therefore software maintenance is more difficult
manufacturing phase cannot be removed easily. than the hardware maintenance.
On the other hand, during software development · Most software is custom built rather than being
process such problems can be rectified. assembled from components
4) In both the activities, developers are responsible 1) While developing any hardware product firstly
for producing qualitative product. the circuit design with desired functioning
· Software does not ware out properties is created. Then required hardware
components such as ICs, capacitors and registers
1) In early stage of hardware development process
are assembled according to the design, but this is
the failure rate is very high because of
not done while developing software product.
manufacturing defects. But after correcting such
defects the failure rate gets reduced. 2) Most of the software is custom built.
3) However, now the software development
2) The failure rate remains constant for some period
approach is getting changed and we look for
of time and again it starts increasing because of
reusability of software components.
environmental maladies (extreme temperature,
dusts, and vibrations). 4) It is practiced to reuse algorithms and data
structures.
3) On the other hand software does not get affected
5) Today software industry is trying to make library
from such environmental maladies. Hence ideally
of reusable components. For example : In today’s
it should have an “idealized curve”. But due to
software, GUI is built using the reusable
some undiscovered errors the failure rate is high components such as message windows, pull
and drops down as soon as the errors get down menus and many more such components.
corrected. Hence in failure rating of software the
6) The approach is getting developed to use in-built
“actual curve” is as shown below :
components in the software. This stream of
Failure curves software is popularly known as component
(Bath tub curves)
engineering.
Failure
3. Design : The model of the software system is · Construction - The software design is mapped into
prepared in this phase. a code by :
4. Coding or implementation : Using the software n Code generation
design the coding is done in this phase. Thus the Testing
n
implementation model is prepared. · Deployment - The software delivered for customer
5. Testing and maintenance : The code is tested and evaluation and feedback is obtained.
modified if required. Task sets - The task set defines the actual work done
in order to achieve the software objective. The task
1.6 Software Process Framework set is used to adopt the framework activities and
MSBTE : Winter-15, 16, Summer-15, 17, Marks 4 project team requirements using :
· The process framework is required for representing n Collection of software engineering work tasks
the common process activities.
n Project milestones
· As shown in Fig. 1.6.1, the software process is
n Software quality assurance points
characterized by process framework activities, task
Umbrella activities - The umbrella activities occur
sets and umbrella activities.
throughout the process. They focus on project
management, tracking and control. The umbrella
Software Process
activities are
Process Framework 1. Software project tracking and control - This is
an activity in which software team can assess
Umbrella Activities
progress and take corrective action to maintain
Acttivity 1 schedule.
Tasksets Work Task
2. Risk management - The risks that may affect
Milestone
SQA Points project outcomes or quality can be analyzed.
3. Software quality assurance - These are activities
Acttivity n required to maintain software quality.
Tasksets Work Task
4. Formal technical reviews - It is required to
Milestone
SQA Points assess engineering work products to uncover
and remove errors before they propagate to next
activity.
5. Software configuration management - Managing
of configuration process when any change in the
Fig. 1.6.1 Software process framework
software occurs.
Process framework activities 6. Work product preparation and production - The
· Communication activities to create models, documents, logs,
forms and lists are carried out.
By
n communicating customer requirement
gathering is done. 7. Reusability management - It defines criteria for
· Planning - Establishes engineering work plan, work product reuse.
describes technical risks, lists resource requirements, 8. Measurement - In this activity, the process can
work products produced and defines work be defined and collected. Also project and
schedule. product measures are used to assist the software
· Modeling - The software model is prepared by : team in delivering the required software.
n Analysis of requirements
n Design
®
TM
Perspective Specialized the system is installed and put in practical use then
process model process model error may get introduced, correcting such errors and
putting it in use is the major purpose of
Waterfall model Component based model
maintenance activity. Similarly, enhancing system’s
RAD model Formal methods model
services as new requirements are discovered is
Spiral model
again maintenance of the system.
Fig. 1.7.1 Types of process models
Advantages of waterfall model
1.7.1 Perspective Process Model
1. The waterfall model is simple to implement.
1.7.1.1 Waterfall Model 2. For implementation of small systems waterfall
· The waterfall model is also called as model is useful.
‘linear-sequential model’ or ‘classic life cycle model’.
Requirement
gathering and analysis
Design
Coding
Testing
Maintenance
Team#n
Design
Team#2
Build
Requirements Design
gathering
D
Build e
Team#1 p
l
Analysis o
Design
and planning y
Build
60 to 90 days period
2
large-scale systems and software. Because customer
There is no customer After each increment, the
interaction until the customer can take a and developer better understand the problem
last phase of the review of the product statement at each evolutionary level. Also risks can
waterfall model. generated so far.
be identified or rectified at each such level.
3 Depending upon the Less human resource is · In the initial pass, product specification is built and
requirements of the required.
project, the human in subsequent passes around the spiral the
resource is required. prototype gets developed and then more improved
4 Risk of failure of Risk of failure of project versions of software gets developed.
project is high. is low.
Customer
communication
Engineering
Concept
development
Project entry projects
point axis
New
product
development
projects
Product
enhancement
projects
Product
maintenance
projects
Customer evaluation Construction
and feedback and release
· During planning phase, the cost and schedule of 2. Requirement changes can be made at every stage
software can be planned and adjusted based on of new version.
feedback obtained from customer evaluation.
3. Risks can be identified and reduced before they
· In spiral model, project entry point axis is defined.
get problematic.
This axis represents starting point for different
types of projects. 4. The working model is available to the customer
at certain stage of iteration.
· For instance, concept development project will start
at core of spiral and will continue along the spiral
path. If the concept has to be developed into actual Disadvantages of spiral model
project then at entry point 2 the product 1. This model is based on customer communication.
development process starts. Hence entry point 2 is If the communication is not proper then the
called product development project entry point. The product being developed is not up to the mark.
development of the project can be carried out in
2. It demands considerable risk assessment. If the
iterations.
risk assessment is done properly then only
· The task regions can be described as :
successful product can be obtained.
i) Customer communication - In this region, it is
suggested to establish customer communication. Sr. No. Waterfall model Spiral model
ii) Planning - All planning activities are carried out 1 It requires well It is developed in
in order to define resources time line and other understanding of iterations. Hence the
project related activities. requirements and requirements can be
familiar technology. identified at new
iii) Risk analysis - The tasks required to calculate iterations.
technical and management risks are carried out. 2 Difficult to The required changes
iv) Engineering - In this task region, tasks required accommodate changes can be made at every
after the process has stage of new version.
to build one or more representations of started.
applications are carried out.
3 Can accommodate It is iterative model.
v) Construct and release - All the necessary tasks iteration but indirectly.
required to construct, test, install the application 4 Risks can be identified Risks can be
are conducted. Some tasks that are required to at the end which may identified and
provide user support are also carried out in this cause failure to the reduced before they
product. get problematic.
task region.
5 The customer can see The customer can see
vi) Customer evaluation - Customer’s feedback is
the working model of the working product
obtained and based on customer evaluation the project only at the at certain stages of
required tasks are performed and implemented at end. After reviewing of iterations.
the working model; if
installation stage.
the customer gets
· In each region, number of work tasks are carried dissatisfied then it
out depending upon the characteristics of project. causes serious
problems.
For a small project relatively small number of work
tasks are adopted but for a complex project large 6 Customers prefer this Developers prefer this
number of work tasks can be carried out. model. model.
· In spiral model, the software engineering team 7 This model is good for This model is good
small systems. for large systems.
moves around the spiral in a clockwise direction
beginning at the core. 8 It has sequential nature. It has evolutionary
nature.
Advantages of spiral model
1. This model has iterative nature. Hence
requirements can be identified at new iteration.
®
TM
System High
User Architectural Formal
requirement level
requirements definition design specification
specification design
· The formal methods model offers defect-free software. However there are some drawbacks of this
model which resists it from getting used widely. These drawbacks are
· The formal methods model is time consuming and expensive.
®
TM
· For using this model, the developers need the late in the software development process, the
strong mathematical background or some extensive agile process should help to accommodate them.
training. 3. Deliver working software quite often. Within the
· If this model is chosen for development then the shorter time span deliver the working unit.
communication with customer becomes very 4. Business people and developers must work
difficult. together throughput the project.
Characteristics of agile process are - 2) The project can easily get off the track if customer
1. Agile processes must be adaptable to technical is not clear about his requirements.
and environmental changes. That means if any
technological changes occur, then the agile Difference between Prescriptive Process Model
and Agile Process Model
process must accommodate it.
2. The development of agile processes must be Prescriptive process
Sr. No. Agile process model
incremental. That means, in each development model
the increment should contain some functionality 1 It is a traditional It is a modern
that can be tested and verified by customer. approach of software approach of software
development. development.
3. The customer feedback must be used to create
the next increment of the process. 2 It is product oriented It is people oriented
process model process model.
4. The software increment must be delivered in
3 Sometimes it is It is easy to adapt the
short span of time.
difficult to adapt changes during
5. It must be iterative, so that each increment can changes during the software
software development.
be evaluated regularly.
development.
· Customer specifies and priorities the system · The life cycle of ASD consists of three phases of
requirements. Customer becomes one of the software development and those are -
important members of development team. The 1. Speculation 2. Collaboration 3. Learning.
developer and customer together prepare a
1. Speculation : This is an initial phase of the
story-card in which customer needs are mentioned.
adaptive software development process. In this
· The developer team then aims to implement the
phase the adaptive cycle planning is conducted.
scenarios in the story-card.
In this cycle planning mainly three types of
· After developing the story-card the development information is used such as - Customer's mission
team breaks down the total work in small tasks. statement, project constraints (delivery date, user
The efforts and the estimated resources required for description, budgets and so on) and basic
these tasks are estimated. requirements of the project.
· The customer priorities the stories for 2. Collaboration : The motivated people work in
implementation. If the requirement changes then collaboration to develop the desired software
sometimes unimplemented stories have to be product. In this phase collaboration among the
discarded. Then release the complete software in members of development team is a key factor.
small and frequent releases. For successful collaboration and coordination it is
· For accommodating new changes, new story-card necessary to have following qualities in every
must be developed. individual -
· Evaluate the system along with the customer. ¡ Assist each other without resentment
This process is demonstrated by the following ¡ Work hard.
Fig. 1.8.1. ¡ Posses the required skill set.
Create small ¡ Communicate problems and
Prepare Plan for
tasks from
story card release
story card help each other to accomplish
the given task.
¡ Criticize without any hate.
Perform software 3. Learning : As the team members go on
Evaluate
Release software integration
system performance developing the components, the emphasize is on
and testing
learning new skills and techniques. There are
Fig. 1.8.1 Extreme programming release cycle
three ways by which the team members learn -
1.8.3 Adaptive Software Development ¡ Focus groups : The feedback from the end-users
· The adaptive software development approach was
is obtained about the software component being
developed. Thus direct feedback about the
proposed by Jim Highsmith. This approach is useful
developed component can be obtained.
in building the complex software systems using
¡ Formal technical review : This review for
iterative apporach
software components is conducted for better
· The focus of this method is on working in
quality.
collaboration and team self organization.
¡ Postmortems : The team analyses its own
Speculation performance and makes appropriate
improvements.
Release
or Collaboration
software
1.8.4 SCRUM
increment
· SCRUM is an agile process model which is used
Learning for developing the complex software systems.
5. During the product building the constant testing ii) What are the issues (obstacles) that team is
facing ?
and documentation must be conducted.
iii) What are the next activities that are planned ?
6. The SCRUM process must produce the working
4. Demo : During this phase, the software
model of the product whenever demanded or increment is delivered to the customer. The
required. implemented functionality which is demonstrated
· Various development activities (requirements to the customer. Note that demo focuses on only
analysis, design, evolution and delivery) are guided implemented functionalities and not all the
by SCRUM principles. planned functionalities (and yet to get
implemented) of the software product.
15 min daily
meeting
1. What are
activities ?
2. Obstacles ?
24 Hour 3. Next meeting
plan ?
30 Days
Software
Sprint backlog
increment
Product backlog with
specific
functionality
1.8.5 Dynamic System Development Method · The primary goal of this method is to deliver useful
(DSDM) and working software.
In this agile method, the project deadline is met using · In this model, a set of methodologies are defined
the incremental prototyping approach. This is an which contains the core elements that are common
iterative development process. to all. These methodologies also contain roles,
The Dynamic System Development Method (DSDM) process patterns, work products and practice that
consortium has defined an agile process model called are unique to each.
DSDM life cycle. · Thus the crystal family is actually a set of agile
Various phases in this life cycle model are as processes that are useful for different types of
follows - projects. The agile team has to select the memebers
of the crustal family that is most approapriate for
1. Feasibility study : By analyzing the business
requirements and constraints the viability of thee their ongoing project and environment.
application is determined in this phase.
Board Questions
2. Business study : The functional and 1. Describe Agile process models in detail.
informational requirements are identified and
MSBTE : Summer-15, Marks 4
then the business value of the application is
determined. The basic application architecture is 2. Explain the features of Agile software development
decided in this phase. approach. MSBTE : Winter-15, 16, Marks 4
®
TM
®
TM
Notes
®
TM
2 Software Requirement
Engineering
Principle 1. Reason it all Exists : The software
Part I : Software Engineering Practices
system that you are going to develop must give
value to its users. If your development is not going
2.1 Software Engineering Practices and its to add any value to its users then don't develop such
Importance system.
Definition : Software engineering practices includes -
concepts, principles, methods and tools that must be Principle 2. Keep it Simple, Stupid (KISS) : The
considered for planning and development of software software design must be simple, easy for
system. understanding and easy to maintain.
2) The software engineering practices - provide Principle 4. What you will Produce, others will
detailed insight for software development Consume : The software system that you develop
process. will be used by users, software designers,
3) It acknowledges the software engineer about the programmers, testers and so on. So whenever you
principles that must be used during the software develop the system, develop in such a way that your
development. job will be easier for them to handle.
· David Hooker proposed seven core principles for Principle 7. Think : Think about the system that you
software engineering practice. These are as follows - are going to develop and acquire the required
®
(2 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 2-2 Software Requirement Engineering
knowledge. Thoughtfully, apply above six principles deciding the goals of the software system being
during the software development process. developed.
2. List core principle of Software Engineering. the communication focused and must make every
MSBTE : Summer-15, 17, Winter-17, Marks 4 topic modular. The modular discussion means leave
one topic only after resolving the issues within in it
2.3 Communication Practices and then only switch to another topic.
MSBTE : Winter-15,16,17, Marks 4
Principle 8 - Make pictorial representation : If
· Communication is carried out in order to something is unclear, then make a drawing or sketch
understand the customer requirements. Following
of it for understanding.
are the principles that are used to make the
communication effective - Principle 9 - Move on : During the communication
just move on by resolving the issues and by
Principle 1 - Listen : It is important to listen the
understanding the things.
customer carefully. Ask for the clarifications
appropriately. Never interrupt him/her annoyingly Principle 10 - Negotiate : There are times when the
during the narration. developers and customer need to negotiate on some
of the issues such as some functionalities, delivery
Principle 2 - Prepare for communication : Do some
date, features priorities and so on.
research to understand the business domain. If you
are conducting the meeting, then prepare the agenda Board Questions
before the meeting. 1. Briefly describe the principles of communication.
Principle 3 - Have facilitator for communication : MSBTE : Winter-15, Marks 4
The facilitator or a leader is required for the 2. State and describe six principles of communication
communication for three reasons. Firstly to move the practices. MSBTE : Winter-16, Marks 4
Principle 5 - Consider risk while defining the plan : Following are analysis modeling principles -
The project plan must be flexible enough to 1. The information domain of the problem must
accommodate one or more risks. be represented and understood : The
information domain represents the data that
Principle 6 - Be realistic : Software development can flows in and out of the system. For designing the
not be 100 % perfect, there can be more or less analysis model it is necessary to understand this
ambiguities and omissions, budgets and schedule data flow.
may vary, developers may make mistakes and so on. 2. The functionality of the software must be
performed : There are various types off the
Such things might occur during the planning of the
functionality that must be present in the system.
system. Some functions can be directly beneficial to the
Principle 7 - Adjust granularity according to plan : user. Some functions are control functions, some
functions are for transforming the data and so
Granularity means how much detailed is your project
on.
plan. The fine granularity plan provides more work
3. The behavior of the software must be
plan details planed relatively short time increment.
represented by the model : By creating
On the other hand, the coarse granular plan provide appropriate model the behavior of the computer
broader work task planed over long period. The plan system for the input submitted by the user,
must be flexible enough for making the adjustments interaction of the system with the external system
are represented by the software.
about the granularity of the project.
4. The model should be created in such a way that
Principle 8 - Ensure the quality : The plan must it represents the details of the software in
help the software team to induce quality in their layered or hierarchical manner : Software
development. systems are usually created to solve the complex
problems. The large and complex problems are
Principle 9 - Describe the accommodated changes : solved using divide and conquer strategy. These
The plan must help the software team to induce sub-problems are relatively easy to understand.
required changes in their development. This process of dividing the problems into
smaller sub-problems is called partitioning.
Principle 10 - Track the plan frequently and make
the changes as per the requirements : The project 5. The analysis task must move from basic
plan must be adjusted frequently. information to the implementation of the
concept : Before creating the analysis model the
information gathered is from users' point of
®
TM
view. This information should be transformed in such systems become difficult. This denotes low
such a way that the implementation of the coupling property of design.
concept using the computer based system. 8. Design representations must be easy to
understand : The software design is used to
(2) Design Modeling Principles
generate the code. Hence it must be easy to
Following are design modeling principles - understand so that implementation of the system
1. Analysis model must be used to create design can be effectively done.
model : The analysis model describes the 9. Design development must be iterative : The
information domain, system behavior, user iterative development of the design model will
visible functionalities and so on. The design refine the work and errors can be corrected in
model translates this information into the system each iteration. But each after each iteration it
architecture. Hence the elements of design model becomes difficult to keep the software design
should be traceable to analysis model. simple.
2. Consider the architecture of the system to be
built : The skeleton of the system should be Board Question
prepared before creating the actual design of the 1. Explain modeling practice in software engineering
system. For creating such architecture the with principles. MSBTE : Winter-17, Marks 4
information present in the analysis model is
used. 2.6 Construction Practices
3. Design of data is an important activity : The MSBTE : Summer-16, Marks 4
data design is an important element of the · The construction practices are based on -
architectural design. It represents the flow of Preparation principles, coding principles and
information. validation principles.
4. Interfaces must be designed carefully : The (1) Preparation principles
interfaces are important for communication of
These are some important principles that software
two components and communication with the
developers must follow before writing the code.
external environment. Hence these need to be
designed carefully. 1. Firstly, understand the problem for which the
system is designed.
5. User interface designs must be as per the
needs : User interfaces basically assist the users 2. Know the basic design principles and concepts.
to interact with the system via user interfaces. 3. Choose appropriate programming language for
Hence the design of user interface must be by coding.
considering the users needs.
4. Select such a programming environment which is
6. Component level design must be functionally convenient to work.
independent : Functional independence is a
5. Prepare the set of unit tests for each component
quality that indicates the single mindedness of
of the code.
software component. Ideally every component
must focus on one functionality at a time. This is (2) Coding principles
called cohesiveness of the components. During
These are some important principles that software
component level design high cohesiveness
developers must follow while writing the code.
(functionally independence) is required.
7. Components must be loosely coupled : If the 1. Adopt structured or modular programming
components are tightly coupled then error approach for the algorithm.
propagation might get increased. The maintaining 2. Choose the appropriate data structures.
®
TM
Validation
2.8.4 Negotiation
and errors are identified then those are corrected or 2.9 Types of Requirements
modified during the validation.
· The most commonly used requirement validation Functional and Non-Functional Requirements
mechanism is Formal Technical Review (FTR). In · Software system requirements can be classified as
FTR, the review team validates the software functional and non functional requirements.
requirements. The review team consists of
2.9.1 Functional Requirements
requirement engineers, customers, end users,
marketing person and so on. This review team · Purpose : Functional requirements should describe
basically identifies conflicting requirements, all the required functionality or system services.
inconstancies or unrealistic requirements. · The customer should provide statement of service.
It should be clear how the system should react to
2.8.7 Requirement Management particular inputs and how a particular system
Definition : Requirements management is the process should behave in particular situation.
of managing changing requirements during the · Functional requirements are heavily dependent
requirements engineering process and system upon the type of software, expected users and the
development. type of system where the software is used.
· Functional user requirements may be high-level
Why requirements get change ? statements of what the system should do but
· Requirements are always incomplete and functional system requirements should describe the
inconsistent. New requirements occur during the system services in detail.
process as business needs change and a better · For example : Consider a library system in which
understanding of the system is developed. there is a single interface provided to multiple
· System customers may specify the requirements databases. These databases are collection of articles
from business perspective that can conflict with end from different libraries. A user can search for,
user requirements. download and print these articles for a personal
study.
· During the development of the system, its business
· From this example we can obtain functional
and the technical environment may get changed.
requirements as,
Board Questions 1. The user shall be able to search either all of the
1. List seven tasks of requirement engineering. initial set of databases or select a subset from it.
MSBTE : Summer-15, Marks 4 2. The system shall provide appropriate viewers
2. With reference to requirement engineering, explain for the user to read documents in the document
i) Inception and ii) Elicitation store.
MSBTE : Winter-15, Marks 4 3. A unique identifier (ORDER_ID) should be
3. Explain following requirements engineering tasks : allocated to every order. This identifier can be
copied by the user to the account's permanent
i) Negotiation ii) Specification
storage area.
MSBTE : Summer-17, Marks 4
4. What are major tasks of requirement engineering ? 2.9.1.1 Problems Associated with Requirements
MSBTE : Winter-17, Marks 8 · Requirements imprecision
5. Explain following requirements of engineering 1. Problems arise when requirements are not
tasks : i) Negotiation ii) Validation precisely stated.
MSBTE : Summer-18, Marks 4 2. Ambiguous requirements may be interpreted in
different ways by developers and users.
3. Consider meaning of term 'appropriate viewers'
®
TM
· User intention - Special purpose viewer for each 2.9.2.1 Types of Non Functional Requirements
different document type; · The classification of non functional requirements is
· Developer interpretation - Provide a text viewer as given in Fig. 2.9.1.
that shows the contents of the document.
Product requirements
· Requirements completeness and consistency - · These requirements specify how a delivered product
The requirements should be both complete and should behave in a particular way. For instance:
consistent. Complete means they should include execution speed, reliability.
descriptions of all facilities required. Consistent
Organizational requirements
means there should be no conflicts or
· The requirements which are consequences of
contradictions in the descriptions of the system
organizational policies and procedures come under
facilities.
this category. For instance : Process standards used
Actually in practice, it is impossible to produce a implementation requirements.
complete and consistent requirements document.
External requirements
2.9.2 Non Functional Requirements · These requirements arise due to the factors that are
external to the system and its development process.
· Purpose : The non functional requirements define
For instance : Interoperability requirements,
system properties and constraints.
legislative requirements.
Various properties of a system can be : Reliability,
response time, storage requirements. And Performance requirements
· These requirements specify the performance or
constraints of the system can be : Input and output
durability of its functioning. For instance : Response
device capability, system representations etc.
to various events at particular instance.
· Process requirements may also specify programming · In short, non functional requirements arise through
language or development method. i) User needs
· Non functional requirements are more critical than ii) Because of budget constraints
functional requirements. If the non functional iii) Organizational policies
requirements do not meet then the complete system
iv) The need for interoperability with other
is of no use. software or hardware systems
Non functional
requirement
v) Because of external factors such as safety 13. The system should be efficient.
regulations.
· Metrics used for specifying the non functional Non functional requirements
requirements 1. Each of the transaction should be made within 60
seconds. If the time limit is exceeded, then cancel
Property Metric the transaction automatically.
Speed Events per response time processed 2. If there is no response from the bank computer
transactions per second. after request is made within the minutes then the
card is rejected with error message.
Size Kilobytes.
3. The bank dispenses money only after the
Reliability Mean time to failure. Rate of failure.
processing of withdrawal from the bank. That
Occurrence availability.
means if sufficient fund is available in user's
Robustness Time to restart after failure. Probability of account then only the withdrawal request is
events causing failure.
processed.
Portability Number of target statements. 4. Each bank should process the transactions from
several ATM centers at the same time.
Ex. 2.9.1 : Enlist various functional and non functional
5. The machine should be loaded with sufficient
requirements for the Bank ATM system.
fund in it.
Sol. : Functional requirements
2.9.2.2 Domain Requirements
1. There should be the facility for the customer to
· Domain requirements are derived from the
insert a card.
application domain of the system instead of specific
2. The system should first validate card and PIN. user needs.
3. The system should allow the customer to deposit · These requirements make use of domain
amount in the bank. terminologies specific to the existing domain
4. The system should dispense the cash on concept.
withdrawal. · The domain requirements may be in the form of
5. The system should provide the printout for the new functional requirements, constraints on existing
transaction. functional requirement or guidance on how to carry
out certain computation.
6. The system should make the record of the
transactions made by particular customer. · These are the specialised requirements and hence
software engineers find it difficult to co-relate the
7. On invalid PIN entry for three times the card
domain requirements with the system requirements.
should be retained by the system.
· It is important to specify the domain requirements
8. The cash withdrawal is allowed in multiple of
otherwise the system will not work properly.
100.
· Example : Domain requirements for the library
9. The cash deposition is allowed in multiple of system.
100.
· There should be user interface for handling the
10. The customer is allowed to transfer amount databases. These interfaces should be according to
between the two accounts. some international standard.
11. The customer is allowed to know the balance · If there is copyright restriction on some document
enquiry. then it should get printed locally on the server. The
12. The customer is allowed to get the printout for copies of such document should not get created.
desired transaction.
®
TM
2.9.3 Difference between Functional and Non Guideline for FAST approach -
Functional Requirements 1. A meeting should be conducted and attended by
Non functional both software engineers and customers. The place
Functional requirements of meeting should be a neutral site.
requirements
The functional The non functional 2. Rules for preparation and participation must be
requirements specify the requirements specify the prepared.
features of the software properties of the software
system. system. 3. An agenda should be prepared in such a way
that it covers all the important point as well as it
Functional requirements Non functional
allows all the new innovative ideas.
describe what the product requirements describe how
must do. the product should 4. A facilitator controls the meeting. He could be
perform.
customer, developer or outsider.
The functional The non functional
5. A definition mechanism is used. The mechanism
requirements specify the requirements specify the
actions with which the experience of the user can be work sheets, flip charts, wall stickers,
work is concerned. while using the system. electronic bulletin board, chart room, virtual
Example : For a library Example : For a library forum.
management system, management system, for a 6. The goal is to identify the problem, decide the
allowing user to read the user who wishes to read
article online is a the article online must be elements of solution, negotiate different
functional requirement. authenticated first. approaches and specify the preliminary set of
solution requirements.
· In FAST meeting each FAST attendee is asked to
2.10 Eliciting Requirements
MSBTE : Summer-16, Marks 4 prepare - a list of objects, list of services and a list
of constraints.
· Questioning is useful only at inception of the
project but for detailed requirement elicitation it is · The list of objects consists of all the objects used in
not sufficient. During requirement elicitation certain the system, the objects that are produced by the
activities such as problem solving, elaboration, system and the objects that surround the system.
negotiation and specification must be carried out. · The list of services contain all the required
Various ways by which the requirement elicitation functionalities that manipulate or interact with the
can be done are - objects.
1. Collaborative requirement gathering · The list of constraints consists of all the constraints
2. Quality function deployment of the system such as cost, rules, memory
requirement, speed accuracy etc.
3. Use scenarios
· As the FAST meeting begins, the very first issue of
4. Elicitation work product
discussion is the need and justification for the new
Let us discuss these aspects of requirement product. Once everyone agrees upon the fact that
elicitation in detail - the product is justified, each participant has to
present his lists.
2.10.1 Collaborative Requirements Gathering
· These lists are then discussed, manipulated and
· Collaborative requirement gathering is done using these modified or refined lists are combined by a
collaborative, team-oriented approach. group.
· Facility Application Specification Technique (FAST) · The combined list eliminates redundant entries adds
is an approach in which joint team of customers new ideas that come up during the discussion. The
and developers work together to identify the combined list is refined in such a way that it helps
problem, propose elements of solution, negotiate in building the system.
different approaches and prepare a specification for
preliminary set of solution requirements.
®
TM
· The combined list should be prepared in such a customer needs and wants into technical
way that a "consensus lists" can be prepared, for requirements. This technique was introduced in
object, services and constraints. Japan.
· A team is divided into subteams. Each subteam · Under quality function deployment three types of
develops a minispecification from each consensus requirements can be defined -
list.
Normal requirements
· Finally a complete draft specification is developed.
· Qualityfunction deployment is a quality · Task deployment : The task associated with each
management technique which translates the function must be identified.
®
TM
· Value analysis : Identify the priorities of · A list of various stakeholders such as customer,
requirements. The technique of QFD requires proper end-users, technical persons, and many others who
interaction with customer. participate during requirement elicitation.
· During requirement gathering overall vision for · A list of requirements and constraints.
systems functions and features get developed. · A set of usage scenarios along with operating
· In order to understand how these functions and conditions.
features are used by different classes of end users, · The prototype that may get developed for defining
developers and users create a set of scenarios. This
the requirements in better manner.
set identifies the usefulness of the system to be
These work products are then reviewed by all the
constructed. This set is normally called as use-cases.
people who participate in requirement elicitation.
· The use-cases provide a description of how the
system will be used.
Board Question
2.10.4 Elicitation Work Product 1. What is requirements elicitation ? What are the
problems faced in eliciting requirements ?
Following are some work products that get produced
MSBTE : Summer-16, Marks 4
during requirement elicitation -
· A statement of feasibility study performed in order
2.11 Developing Use Cases
to find the need of the project. MSBTE : Summer-16, 18, Marks 4
Sol. :
Banking System
Logging in
Deposit Amount
Withdrawal of
Amount
Customer Bank
Get Account
Balance
Transfer of
Amount
Fig. 2.11.1
®
TM
Sol. :
Song Unavailable
<<extend>>
By artist
View songs
By title
Start play
By Album
User <<include>>
Play a library Play Song
<<include>>
Destroy <<include>>
Library
Destroy a song
<<include>>
Delete Library
Add a Song
<<include>>
Create Library
CD
Create CD
Rip CD
Stop Play
Fig. 2.11.2
Ex. 2.11.3 : Draw the use case diagram for taking "photocopy of ans books from msbte" website.
MSBTE : Summer-18, Marks 4
®
TM
Sol. :
Enroll
Authenticate
<<extend>> User
Login
Fill up Form
Submit Form
Apply for
<<extend>> Revaluation
Student
Get Photocopy
Change
Password
logout
Fig. 2.11.3
Ex. 2.11.4 : Draw use case diagram for railway ticket reservation system.
Sol. :
ViewSchedule
Reserve a Seat
<<include>> <<include>>
PaysFare
<<include>>
Cancel reservation
CardValidation
Payment validation System
Fig. 2.11.4
®
TM
Ex. 2.11.5 : Consider an automated soda machine that gives cool drinks. Draw use case model of the soda machine.
Sol. :
<<include>> Insufficient
Amount
<<extend>>
Verify Amount
Dispense
Change
Fig. 2.11.5
· Requirement analysis is an intermediate phase between system engineering and software design.
· Requirement analysis produces a software
specification. Analysis Design
model model
How is requirement analysis helpful ?
· Analyst - The requirement analysis helps the
'analyst' to refine software allocation. Using
requirement analysis various models such as
data model, functional model and behavioral
model can be defined.
· Designer - After requirement analysis, the
designer can design for data, architectural System Requirement Software
engineering analysis design
interface and component level designs.
· Developer - Using requirements specification
Fig. 2.12.1 Requirement analysis : An intermediate step
and design the software can be developed.
1. Problem recognition
· The requirement analysis is done for understanding the need of the system. The scope of the software
in context of a system must be understood.
®
TM
®
TM
how the software interfaces with other software ... others as appropriate.
products or users for input or output. Examples of
8. Operational Scenarios : This section should
such interfaces include library routines, token
describe a set of scenarios that illustrate, from the
streams, shared memory, data streams and so forth.
user's perspective, what will be experienced when
4.1 User Interfaces : Describes how this product
interfaces with the user. utilizing the system under various situations.
4.1.1 GUI : Describes the graphical user 9. Preliminary Schedule : This section provides an
interface if present. This section should initial version of the project plan, including the major
include a set of screen dumps to illustrate tasks to be accomplished, their interdependencies,
user interface features.
and their tentative start/stop dates.
4.1.2 CLI : Describes the command-line interface
if present. For each command, a 10. Preliminary Budget : This section provides an
description of all arguments and example initial budget for the project.
values and invocations should be provided.
®
TM
®
TM
3
3.1 Translating Requirement Model into
Software Modelling and Design
· The architectural design defines the relationship of software. Because design is the only way that we
between major structural elements of the software. can accurately translate the user requirements into
The architectural styles and design patterns can be the finished software product.
ts Flow · Class-based
m en ori elements
d ele en Component
· Data flow te · Flow-oriented Com-
se · Usecases d level
ba diagram el elements ponent
design
-
em
· Behavioral
na
design
en
ts
· Processing · Scenario-based
· Swimlane Interface
narratives elements
diagram design
Analysis · Flow-oriented Interface
· Class diagram model elements design
· State
· Behavioral
· Analysis diagrams Architectural design
elements
Cla
package · Sequence
diagram · Flow-oriented
sbs
d Data/class diagram
e
ele m
diagrams le elements
me
nts ra le
vio · Class-based Data/ class
Beha elements diagram Design model
· Without design unstable system may get developed. · Roles such as manager, engineer, customer.
Even if some small changes are made then those · Organizational units such as division, departments.
changes will go fail. It will become difficult to test
· Places such as manufacturing floor, workshops.
the product. The quality of the software product can
· Structures such as student records, accounts, file.
not be assessed until late in the software process.
What are attributes ?
3.1.1 Data Modeling Attributes define properties of data object
· Data modelling is the basic step in the analysis Typically there are three types of attributes -
modelling. In data modelling the data objects are
examined independently of processing. 1. Naming attributes - These attributes are used to
name an instance of data object. For example : In
· The data domain is focused. And a model is created
a vehicle data object make and model are naming
at the customer’s level of abstraction.
attributes.
· The data model represents how data objects are
2. Descriptive attributes - These attributes are used
related with one another.
to describe the characteristics or features of the
3.1.1.1 Data Object, Attributes and Relationships data object. For example : In a vehicle data object
What is data object ? color is a descriptive attribute.
· Data object is a set of attributes (data items) that 3. Referential attribute - These are the attributes
will be manipulated within the software (system). that are used in making the reference to another
instance in another table. For example : In a
· Each instance of data object can be identified with
vehicle data object owner is a referential attribute.
the help of unique identifier. For example : A
student can be identified by using his roll number. What is relationship ?
Relationship represents the connection between the
· The system cannot perform without accessing to the
data objects. For example
instances of object.
The relationship between a shopkeeper and a toy is
· Each data object is described by the attributes which
as shown below
themselves are data items.
Here the toy and shopkeeper are two objects that
Data object is a collection of attributes that act as an share following relationships -
aspect, characteristic, quality or descriptor of the object. · Shopkeeper orders toys. · Shopkeeper sells toys.
· Shopkeeper shows toys. · Shopkeeper stocks toys.
Object : Vehicle
3.1.2 Cardinality and Modality
Attributes:
Make Cardinality in data modeling, cardinality specifies how
Model the number of occurrences of one object is related to the
Color number of occurrences of another object.
Owner
Price · One to one (1 : 1) - One object can relate to only
one other object.
Fig. 3.1.2 Object
· One to many (1 : N) - One object can relate to
The vehicle is a data object which can be defined or
many objects.
viewed with the help of set of attributes. · Many to many (M : N) - Some number of
occurrences of an object can relate to some other
Typical data objects are number of occurrences of another object.
· External entities such as printer, user, speakers.
· Things such as reports, displays, signals. Modality indicates whether or not a particular data
object must participate in the relationship.
· Occurrences or events such as interrupts, alarm,
telephone call.
®
TM
Modality : It is optional,
Modality : For purchase action there may not be
customer is must any purchasing
(modality 1) (modality 0)
em
ar
diagram
en
Sc
· Activity diagrams
t
means it should provide a complete picture of
s
· Swim lane software, addressing the data, functional and
diagram behavioural domains from an implementation
The
analysis perspective.
model · State
· Class diagram diagram
· Sequence
3.3.1 Fundamental Design Concepts
· Analysis
diagram
ts
Be
em
· CRC models
ha
or
ed · Collaboration le a
as
ss
b diagrams ent
le m Various issues that must be considered during
Cla s
software design are -
Fig. 3.2.1 Analysis model
(1) Abstraction
Board Questions
1. Write importance of analysis modeling. The abstraction means an ability to cope up with the
MSBTE : Summer-15, 17, Marks 4
complexity. Software design occurs at different levels
of abstraction. At each stage of software design
2. With a neat diagram explain analysis model.
process levels of abstractions should be applied to
MSBTE : Winter-15, Marks 4
refine the software solution. At the higher level of
3. Explain the various elements of analysis modeling abstraction, the solution should be stated in broad
in detail. MSBTE : Winter-15, Marks 6 terms and in the lower level more detailed
4. Describe the terms : Analysis modeling and design description of the solution is given.
modeling. MSBTE : Summer-16, Marks 4
(2) Modularity
5. Describe four principles of analysis modeling.
· The software is divided into separately named
MSBTE : Winter-16, Summer-18, Marks 4
and addressable components that called as
6. Explain analysis modeling. MSBTE : Winter-17, Marks 4 modules.
7. List and explain the elements of analysis model · Monolithic software is hard to grasp for the
with neat labeled diagram. software engineer, hence it has now become a
MSBTE : Summer-18, Marks 8
trend to divide the software into number of
products. But there is a co-relation between the
3.3 Design Modeling
MSBTE : Winter-15, 16,Summer-15, 17, Marks 4 number of modules and overall cost of the
· In architecture various components interact and · Pattern can be used for current work.
the data of the structure is used by various · Pattern can be used to solve similar kind of
components. problem with different functionality.
· In architectural design various system models can (6) Information Hiding
be used and these are - Information hiding is one of the important property
of effective modular design. The term information
Model Functioning hiding means the modules are designed in such a
way that information contained in one module cannot
Structural model Overall architecture of the system
can be represented using this be accessible to the other module (the module which
model. does not require this information). Due to information
hiding only limited amount of information can be
Framework model This model shows the architectural
framework and corresponding passed to other module or to any local data structure
applicability. used by other module.
Dynamic model This model shows the reflection of The advantage of information hiding is basically in
changes on the system due to testing and maintenance. Due to information hiding
external events. some data and procedures of one module can be
Process model The sequence of processes and their hidden from another module. This ultimately avoids
functioning is represented in this introduction of errors module from one module to
model. another. Similarly one can make changes in the
Functional model The functional hierarchy occurring desired module without affecting the other module.
in the system is represented by this (7) Functional Independence
model.
· The functional independence can be achieved by
developing the functional modules with
(4) Refinement single-minded approach.
· Refinement is actually a process of elaboration. · By using functional independence functions may
· Stepwise refinement is a top-down design strategy be compartmentalized and interfaces are
proposed by Niklaus WIRTH. simplified.
· The architecture of a program is developed by · Independent modules are easier to maintain with
successively refining levels of procedural detail. reduced error propagation.
· The process of program refinement is analogous · The major benefit of functional independence is in
to the process of refinement and partitioning that achieving effective modularity.
is used during requirements analysis. · The functional independence is assessed using two
· Abstraction and refinement are complementary
qualitative criteria - Cohesion and coupling.
· Cohesion : A cohesive module performs only "one
concepts. The major difference is that - In the
task" in software procedure with little interaction
abstraction low-level details are suppressed.
with other modules. In other words cohesive
Refinement helps the designer to elaborate
module performs only one thing.
low-level details.
· Coupling : Coupling effectively represents how
(5) Pattern the modules can be "connected" with other
module or with the outside world.Coupling is a
According to Brad Appleton the design pattern can
measure of interconnection among modules in a
be defined as - It is a named nugget (something
program structure.
valuable) of insight which conveys the essence of
proven solution to a recurring problem within a (8) Refactoring
certain context. · It is defined refactoring as "The process of
In other words, design pattern acts as a design changing a software system in such a way that
solution for a particular problem occurring in specific the external behaviour of the design do not get
domain. Using design pattern designer can determine changed, however the internal structure gets
whether- improved".
· Pattern can be reusable.
®
TM
Board Question
1. What are the characteristics of good design ? MSBTE : Summer-15,17,Marks 4
®
TM
Level 0 DFD
0
x
z
Entity A nformation Entity B
y system
Level 1 DFD
1
x
Process
Entity A
P Entity B
y 2 3 z
R Q
Data store Process Process
Process
V W
2.3 2.2
y
Q
T
Process Process
R
Data store
U
Level 3 DFD
S
2.2.1
Process
U
S3
S1
2.2.2 2.2.3
T S2 Q
Process Process
1. Level 0 DFD i.e. Context level DFD should depict the system as a single bubble.
2. Primary input and primary output should be carefully identified.
3. While doing the refinement isolate processes, data objects and data stores to represent the next level.
4. All the bubbles (processes) and arrows should be appropriately named.
5. One bubble at a time should be refined.
6. Information flow continuity must be maintained from level to level.
· A simple and effective approach to expand the level 0 DFD to level 1 is to perform “grammatical
parse” on the problem description. Identify nouns and verbs from it. Typically nouns represent the
external entities, data objects or data stores and verbs represent the processes. Although grammatical
parsing is not a foolproof but we can gather much useful information to create the data flow
diagrams.
1. No process can have only outputs or only inputs. The process must have both outputs and inputs.
xy xy
xy xy
Fig. 3.4.2
2. The verb phrases in the problem description can be identified as processes in the system.
Fig. 3.4.3
®
TM
Fig. 3.4.4
3. There should not be a direct flow between data stores and external entity. This flow should go
through a process.
4. Data store labels should be noun phrases from problem description.
5. No data should move directly between external entities. The data flow should go through a
process.
Fig. 3.4.5
Ex. 3.4.1 : Draw a dataflow diagram level 0 and level 1 for a Book Publishing House. MSBTE : Summer-16, Marks 6
Sol.:
Level 0 DFD :
®
TM
Level 1 DFD :
Get Book
Request for Book Process Information Books
Customer
order Database
Credit Check
Customer Information
Books Order
Database
Assemble Bunch of
Purchase Orders Orders
to send to
Warehouse
Ex. 3.4.2 Draw DFD level 0 and level 1 for Hotel management system. MSBTE : Winter-16, Marks 6
In this level, the system is designed globally with input and output. The input to food ordering system
are -
Level 1 DFD
In this level, the bubble 0.0 is shown in more detail by various processes. The process 1.0 is for
processing an order. And processes 2.0, 3.0 and 4.0 are for housekeeping activities involved in food
ordering system. To create a management report there should be some information of daily sold items.
At the same time inventory data has to be maintained for keep track of 'instock' items. Hence we have
used two data stores in this DFD -
Finally management report can be prepared using daily sold details and daily inventory deplition
amount. This management report is given to restaurant manager.
®
TM
1.0
Processing
of
Order for food Order Food
Customer Kitchen
order
2.0
Sold Inventory
Update items data 3.0
Data base Sold
of sold items Items Update
Inventory
File
Inventory
data Inventory
Info. about
daily 4.0 database
sold items Generate Info. about daily inventory
Management
Report Depletion Amount
Management Restaurant
Report Manager
Sol. : In this DFD the whole system is represented Library information system
with the help of input, processing and output. The The system will produce following outputs -
input can be -
i) The demanded book will be given to student.
i) Student requests for a book hence Book request.
Hence Book will be the output.
ii) To show identity of the student he/she has to
ii) The library information system should display
submit his/her Library card, hence Library card.
demanded book information which can be used
by customer while selecting the book.
0.0
Book request
Library Demanded
Student Library card Information Display of
System book Info Book
Book
Level 1 DFD
Book selves
1.0 k
Boo
Book request
Student Delivery Author (s) List of
Library card
of Book Authors
Title
Book List of
Titles
demanded
Topic Book
Info
List of topics
Topic
Display of
Book request Book
2.0
(By topic)
Demanded
Book Search Book
(Based on topic) by Topic Info
In this level, the system is exposed with more processing details. The processes that need to carried out
are -
i) Delivery of Book.
These processes require certain information such as List of Authors, List of Titles, List of Topics, the
book selves from which books can be located. This kind of information is represented by data store.
Ex. 3.4.4 Draw and explain level 0 and level 1 Dataflow diagram for "Online examination Win17 of form filling on
MSBTE website". MSBTE : Summer-18, Marks 6
Sol. :
0.0
Request Online Icard
Student exam W17 Student
for logging
system
®
TM
0.0 Validate
Request Student
Student Logs in Status
for logging Registration info.
Fills form
1.1
Inputting Form
data to
form fields Validation
Status
Checked
Form
1.2
Entry
Deposit Registration
Exam Fees acknowlege Account
Request
for issueing
Icard
1.3
Icard Issue entry Icard
Icard Student
Register Issue
Ex. 3.4.5 : Draw Level 0 and Level 1 DFD for railway reservation system
Sol. : Problem description : For an online railway reservation system, passenger can make online booking for
the seats, by specifying the requirements. These requirements are - type of reservation A/C coach, non A/C coach,
two tier or three tier number of seats, name of the train, start and destination of journey. The system then checks
for availability of such requirements. If such a reservation is possible then system generates availability of
reservation. The passengers checks for availability and the charges are then calculated for the selected
requirement, and these are acknowledged to the passenger. If the passenger is satisfied then he confirms the
reservation.
The required DFD can be drawn in levels as follows -
0.0
Reservation Online Reservation
Passenger railway Railway
details details reservation details office
system
Fare amount
®
TM
1.0
Reservation Passenger
Passenger Processing Passenger database
details request details
Calculated Ra
ilw
fare amount ay
Sta na
tion me
s s
Sea
t, tim
Cha e
rges
Suitable ava Reservation
Info. ilabilit details
details y
1.1
Confirmation
Reservation of Reservation
details Railway office
reservation details
of reserved
seats
Ex. 3.4.6 : Draw Level 0 and Level 1 DFD for ATM system.
Sol.: The level 0 DFD is the context level DFD in which only inputs and outputs that are interacting with the
system are given.
Accounts database
Customer
keypad Screen
Printout
ATM
dispenser
Control Cash
system dispenser
Card
reader
®
TM
Screen
Verify
Card
pin and
reader Ac. no and AC. No.
PIN On
N
PI validity
a nd of card Control
o
.n system
Ac
Customer Command Display
keypad customer
for service options
selection
Request Checks
availability Update Cash Cash
for withdrawal of amount database dispenser
details
Account
info Account
info
Account database
Fig. 3.4.15
®
TM
· The module uses data and flags. The data is processed by different modules. The flag is used as a
control signal. It can be set or reset.
· For example if we have two modules one for getting the employee detail(subordinate) and another
module is for finding the employee name(superordinate). Then the caller module will sent the data as
employee's ID and using that ID the called module will find the name of employee. If the employee
ID is valid then that message will be given by the called module to a caller module. The use of data
and flag can be as shown below.
Find
employee
name
Calculate total
Calculate fees Calculate total
number of
for one student fees
students
Record
Valid student Total number
is valid Total fees
record of students
Students Field
record Field valid
The decision tables can associate many independent conditions with several actions in an elegant way.
The rules can be shown by numbering them.
“ A nationalised bank gives housing loan to his customers with fixed and floating rate of interset. If
the customer chooses the fixed rate of interest and takes a loan of an amount which is less than one
lakhs then apply scheme A structure to him and if the customer chooses floating rate for a loan
amount less than 1 lakhs then apply scheme B structure to him and at the same time apply monthly
®
TM
4.
2. Sometimes it is difficult to test each and every
This type of testing is This type of testing is
suitable for large projects. suitable for small projects. path of the software and hence many paths may
go untested.
Advantages and disadvantages of black box
3. Maintaining the white box testing is very difficult
testing
because it may use specialized tools like code
Advantages : analyzer and debugging tools are required.
1. The black box testing focuses on fundamental 4. The missing functionality can not be identified.
aspect of system without being concerned for
internal logical structure of the software. 3.5.3 Level of Testing
2. The advantage of conducting black box testing is We begin by ‘testing-in-the-small’ and move toward
to uncover following types of errors. ‘testing-in-the-large’.
Testing Software
strategies development stages
System
testing System engineering
Validation
Requirements
testing
Integration
Design
testing
Unit
testing Code
1. Unit testing - In this type of testing techniques · The various tests that are conducted during the unit
are applied to detect the errors from each test are described as below.
software component individually. 1. Module interfaces are tested for proper
2. Integration testing - It focuses on issues information flow in and out of the program.
associated with verification and program 2. Local data are examined to ensure that integrity
construction as components begin interacting is maintained.
with one another.
3. Boundary conditions are tested to ensure that the
3. Validation testing - It provides assurance that module operates properly at boundaries
the software validation criteria (established established to limit or restrict processing.
during requirements analysis) meets all
4. All the basis (independent) paths are tested for
functional, behavioural and performance
ensuring that all statements in the module have
requirements.
been executed only once.
4. System testing - In system testing all system
5. All error handling paths should be tested.
elements forming the system is tested as a whole.
6. Drivers and stub software need to be developed
3.5.3.1 Unit Testing to test incomplete software. The “driver” is a
· In unit testing the individual components are tested program that accepts the test data and prints the
independently to ensure their quality. relevant results. And the “stub” is a subprogram
that uses the module interfaces and performs the
· The focus is to uncover the errors in design and
implementation.
®
TM
Things to be tested
Source program
Interfaces
Module Local data
to be Generating
structures
Various tested Boundary condition
modules
in program Independent path
Error handling paths
Test
cases
Driver Interface
Local data structures
Boundary conditions
Independent paths
Module Error handling paths
Results
7. The unit testing is simplified when a component with high cohesion (with one function) is designed. In such
a design the number of test cases are less and one can easily predict or uncover errors.
· The testing activity should involve two goals - · Test case specification is the major activity in the
i) Maximize the number of errors detected. testing process. Careful selection of test cases will
help in conducting proper testing.
ii) Minimize the number of test cases.
· The selection of test case should be such that faulty There are two basic reasons why test case
module or program segment must be exercised by specification should be before using them for testing -
at least one test case. Firstly it will assist the tester to reveal as many errors
as possible from the program and secondly the high
· Selection of test cases is determined by some criteria
quality code can be produced.
which is called as test selection criterion. Hence the
test selection criterion T can be defined as the set of 3.5.4.2 Test Plan
conditions that must be satisfied by the set of test
Test plan is not a static document. It gets generated
cases.
during the development. The main purpose of test
· Testing criterion are based on two fundamental planning is to describe the product tests and to
properties - reliability and validity. establish the standards in testing process. The
· A test criterion is reliable if all the test cases detect structure of test plan is as given below.
same set of errors.
1. Testing process
· A test criterion is valid if for any error in the
program there is some set which causes error in the In this section various phases of testing process are
program. described.
· For testing criteria there is an important theorem -
2. Requirements traceability
"if testing criterion is valid and reliable if a set
satisfying testing criterion succeeds then that means Testing should be planned to meet all the
program contains no errors". requirements.
· Generating test cases to satisfy criteria is complex
3. Tested items
task.
The tested products of software are tested.
· The test case specification records the results of the
testing, the conditions used for testing particular
4. Testing schedule
unit. It also specifies the expected test results. It
records the outcome of test cases (Pass/Fail). The It includes testing schedule and resource allocation
sample structure of a test case specification is as for this schedule.
given below -
5. Test recording procedures
Precondition : After running the tests, it is necessary to record those
tests in order to check whether tests are conducted
Test Test steps Test systematically or not.
Test Test case case
Test Defect
case case de- status
priority severity
id name scrip- (Pass/ 6. Hardware and software requirements
tion Step Expected Actual Fail)
The required software tools and hardware utilization
is specified under this section.
1
7. Constraints
2
All the factors affecting the testing process are listed
under this section.
3
®
TM
3.5.4.3 Introduction to Defect Report Assigned to The name of the person who is
Defect report is a document that identifies and assigned to fix the defect.
describes the defects detected by the tester. Status Specify the status of the defect.
The purpose of defect report is to state the problem Fixed build no. Specify the version of the product
as clearly as possible so that the developer can fix it where the defect was fixed.
easily.
3.5.4.4 Test Summary Report
In most of the software companies defect report is
used as a tool in defect management process. · Test summary report is a document which contains
summary of test activities and final test results.
The template of commonly used defect report is as
· After completion of testing cycle, it is very
follows -
important to communicate the test results and
findings to project stakeholders(Stakeholders are
ID Unique identifier given to the defect.
people who take part in developing the software
Project Name of the Project product) so that decisions can be made for the
software release.
Product Name of the product
Template : The IEEE template for Test Summary
Release version Specify the release version of the
Report is as given below -
product.
Module Specify the module name in which Test Summary Report Identifier
defect is detected.
[Enter Some type of unique company generated number to
Build version Specify the build version of the identify this summary report, its level and the level of
product where the defect was
detected. software that it is related to.]
reasons for the variances and the possible impact on 7. Describe white box and black box testing of
the testing staff. software. MSBTE : Winter-16, Marks 4
· Elapsed time versus staff time 9. Explain unit testing. MSBTE : Winter-15,17, Marks 4
· Is staff working excess hours per week 10.What aspects of the software are tested in Unit
· Costs - planned versus actual Testing ? MSBTE : Summer-16, Marks 4
· Variances and the reasons for the change such as - 11.Describe in brief four level testing process in test
change in project scope, requirements changes, execution. MSBTE : Winter-16, 17, Marks 4
newly introduced defects, and so on.] 12.Draw stub and driver mechanism of unit testing
Approvals and enlist various types of errors detected by unit
The undersigned acknowledge they have reviewed testing. MSBTE : Summer-18, Marks 4
the <Project Name> Test Summary Report and agree
13.Explain test case design in detail.
with the approach it presents. Changes to this Test
MSBTE : Summer-17, Marks 4
Summary Report will be coordinated with and
approved by the undersigned or their designated 14.List various testing characteristics.
representatives. MSBTE : Summer-17, Marks 4
[List the individuals whose signatures are desired. 15.What do you mean by good test ?
Examples of such individuals are Quality Manager or MSBTE : Winter-17, Marks 4
4
4.1 Management Spectrum
Software Project Estimation
®
(4 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 4-2 Software Project Estimation
5. The technological changes are quite often. PQR 20,000 60 300 1000 129 32 6
®
TM
Disadvantages
Weighting factor
Domain Characteristics Count Count
Simple Average Complex
Number of files X 7 10 15
Count Total
®
TM
· The count table can be computed with the help of n Quality = Number of faults/FP
above given table. n Cost = $/FP
· Now the software complexity can be computed by
n Documentation = Pages of documentation/FP.
answering following questions. These are
complexity adjustment values. Advantages
1. Does the system need reliable backup and 1. This method is independent of programming
recovery ? languages.
2. Are data communications required ? 2. It is based on the data which can be obtained in
early stage of project .
3. Are there distributed processing functions ?
4. Is performance of the system critical ? Disadvantages
5. Will the system run in an existing, heavily 1) This method is more suitable for business
utilized operational environment ? systems and can be developed for that domain.
6. Does the system require on-line data entry ? 2) Many aspects of this method are not validated.
7. Does the on-line data entry require the input 3) The functional point has no significant meaning.
transaction to be built over multiple screens It is just a numerical value.
or operations ?
Comparison between size oriented and function
8. Are the master files updated on-line ? oriented metrics
10. Is the internal processing complex ? 1. Size oriented software Function oriented
metrics is by metrics use a measure
11. Is the code which is designed being reusable ? considering the size of functionality
of the software that delivered by the
12. Are conversion and installation included in
has been produced. software.
the design ?
2. For a size oriented Most widely used
13. Is the system designed for multiple metric the software function oriented
installations in different organizations ? organization metric is the function
maintains simple point (FP)
14. Is the application designed to facilitate change records in tabular computation of the
form. The typical function point is
and ease of use by the user ? table entries are : based on
· Rate each of the above factors according to the Project name, LOC, characteristics of
Effort, Pages of software’s information
following scale : documents, errors, domain and
· Function Points (FP) = Count total x (0.65 + defects, total number complexity.
of people working on
(0.01 x Sum(Fi)) project.
®
TM
10 Outputs
6 inquiries
17 files
4 external interfaces
Average complexity for inputs and external interfaces. Low complexity for remaining parameters.
Weighting factor
Measurement
Count
parameters
X Simple Average complex
Number of 7 X 4 28
user inputs.
Number of 10 X 4 40
user
outputs.
Number of 6 X 3 18
user
inquiries.
Number of 17 X 7 119
files
Number of 4 X 7 28
external
interfaces.
= 233 ´ 0.97
FP = 226.01
®
TM
· This method makes use of previous project's The co-ordinator must be talented enough to
estimated cost. synthesize the diverse and wide ranging statements.
· This method is successful for technical forecasting.
· This method assumes the relationships among the
different project parameters. These parameters are Analytical Estimation
then correlated using suitable mathematical
In analytical estimation technique, the results are
expressions.
derived by making certain basic assumptions about
· Once the basic parameters are known, the other
the project. Hence analytical estimation technique
parameters can be easily determined by substituting have some scientific basis. Halstead's software
the value of basic parameters in mathematical science is based on analytical estimation model.
expression.
· COCOMO model is an example of Heuristic 4.3.2.1 Halstead's Software Science
technique. Halstead's complexity measurement was developed to
measure a program module’s complexity directly
4.3.2 Analytical and Empirical Estimation from source code, with emphasis on computational
complexity.
Empirical Estimation
· In empirical estimation technique an educated guess The Halstead's measures are based on four scalar
of project parameters is made. Hence empirical numbers derived directly from a program’s source
estimation model is based on common sense. code :
· However as there are many activities involved in n 1 is number of distinct operators,
empirical estimation techniques, this technique is
formalized. n 2 is number of distinct operands,
®
TM
Halstead's uses certain measures such as program 5. The reserve words, return, default, continue,
length, program vocabulary, volume, difficulty and break, sizeof are all operators.
effort for the given algorithm. By this Halstead's is 6. The brackets, commas, semicolons are operators.
trying to show that the program length can be
7. The unary and binary operators are considered
calculated, volume of the algorithm can be estimated.
as operators. The & is considered as operator.
The above given table shows how actually these
measures can be obtained. 8. In arrays, array name and index are considered
as operands and [ ] is considered as operator.
The Halstead's measures are applicable to operational
systems and to development efforts once the code has 9. All hash directives can be ignored.
been written. Thus using Halstead's measurement 10. Comments are not considered.
experimental verification can be performed in 11. In Goto statement, goto is considered as operator
software science. and label as operand.
Program length
Ex. 4.3.1 Obtain Halstead's length and volume measure
The length of a program is total usage of operators for following C function.
and operands in the program. void swap (int a [ ], int i)
{
Length = N 1 + N 2 int temp ;
temp = a[i] ;
Program vocabulary a[i] = a[i+1] ;
The program vocabulary is the number of unique a[i+1] = temp ;
operators and operands used in the program. }
Sol. : We will first find out the operands and
Vocabulary × n = n 1 + n 2 operators from above function along with their
occurrences.
Program volume
Operands Occurrences Operators Occurrences
The program volume can be defined as minimum
swap 1 () 1
number of bits needed to encode the program.
a 5 {} 1
V = N log 2 n
i 5 void 1
1 2 [] 5
N = n 1 log 2 n 1 + n 2 log 2 n 2
, 1
Volume = N ´ log 2 n KLOC means kilo line of code for the project.
Consider a software project using semi-detached mode with 30,000 lines of code. We will obtain
estimation for this project as follows -
i) Effort estimation
E = a b (KLOC) bb
E = 135 person-month
D = C b (E) d b
= 2.5 (135) 0. 35
D = 14 months
P = E/D
= 135/14
P = 10 persons approximately
2) Intermediate Model
This is an extension of Basic COCOMO model. This estimation model makes use of set of "Cost driver
attributes" to compute the cost of software.
Now these 15 attributes get a 6-point scale ranging from "very low" to "extra high". These ratings can
be viewed as
The effort multipliers for each cost driver attribute is as given in following table. The product of all
effort multipliers result in "Effort Adjustment Factor" (EAF).
Ratings
Cost drivers
Very low Low Nominal High Very high Extra high
Product attributes
Hardware attributes
®
TM
Personnel attributes
Software project ai bi
Table 4.4.3
The duration and person estimate is same as in basic COCOMO model. i.e.
D = c b (E) d b months i.e. use values of cb and db coefficients that are in Table 4.4.1
P = E/D persons
1. This model can be applied to almost entire software product for easy and rough cost estimation
during early stage.
2. It can also be applied at the software product component level for obtaining more accurate cost
estimation.
Consider a project having 30,000 lines of code which is an embedded software with critical area hence
realiability is high. The estimation can be
®
TM
As reliability is high, EAF = 1.15 (product attribute) COCOMO II is applied for modern software
a i = 2.8 ü development practices addressed for the projects in
ý for embedded software
b i = 1.20þ 1990’s and 2000’s.
\ E = 2 . 8 (30) 1.20 * 1.15 The sub-models of COCOMO II model are –
= 191 person-month
1. Application composition model
db
D = c b (E) ) 0. 32
= 2 . 5 (191 · For estimating the efforts required for the
prototyping projects and the projects in which the
= 13 months approximately
existing software components are used
P = E/D application-composition model is introduced.
· The estimation in this model is based on the
= 191/13
number of application points. The application points
P = 15 persons approximately are similar to the object points.
3) Detailed COCOMO Model · This estimation is based on the level of difficulty of
object points.
The detailed model uses the same equations for
Boehm has suggested the object point productivity
estimation as the Intermediate Model. But detailed
in the following manner.
model can estimate the effort (E), duration (D) and
persons (P) of each of development phases, Developers Very Low Nominal High Very
subsystems, modules. experience low high
and capability
The experimentation with different development
strategies is allowed in this model. CASE Very Low Nominal High Very
maturity low high
Four phases used in detailed COCOMO model are -
Productivity 4 7 13 25 50
1. Requirements planning and product design (RPD) (NOP/Month)
®
TM
®
TM
®
TM
That means this project can be completed within 21 Different types of risk
months by 14 persons, approximately, 1. Project risk
4) Given that, System = Organic Project risks arise in the software development
Lines of code = 10 lakh = 1000 KLOC process then they basically affect budget,
schedule, staffing, resources, and requirements.
\ E = a b (KLOC) bb When project risks become severe then the total
cost of project gets increased.
= 2.4 (1000) 1.05
2. Technical risk
» 3390 person - month
These risks affect quality and timeliness of the
D = c b (E) d b
project. If technical risks become reality then
» 2.5 (3390) 0.38 potential design implementation, interface,
verification and maintenance problems gets
» 55 months created. Technical risks occur when problem
\ P = E/D becomes harder to solve.
4. Risk mitigation, monitoring and management. v) Budget risk - Losing the overall budget of the
project is called budget risk.
4.6.1 Software Risks
There are two characteristics of the risks
1. The risk may or may not happen. It shows the
uncertainty of the risks.
2. When risks occur, unwanted consequences or
losses will occur.
®
TM
Strategic risk
Sales risk
Management risk
Budget risk
Known risks are those risk that are identified after Risk identification can be defined as the efforts
evaluating the project plan. These risks can also be taken to specify threats to the project plan. Risks
identified from other sources such as environment in identification can be done by identifying the known
which the product gets developed, unrealistic dead and predictable risks.
lines, poor requirement specification and software
scope. There are two types of known risks - The risk identification is based on two approaches
predictable and unpredictable risks. 1. Generic risk identification - It includes potential
threat identification to software project.
Predictable risks
2. Product-specific risk identification - It includes
product specific threat identification by
Known risks understanding people, technology and working
environment in which the product gets built.
Normally the risk identification is done by the project
Unpredictable risks
manager who follows following steps -
Fig. 4.6.2
Step 1 : Preparation of risk item check list
Predictable risks are those risks that can be identified
in advance based on past project experience. For The risk items can be identified using following
example : Experienced and skilled staff leaving in known and predictable components
between or improper communication with customer i) Product size - The risk items based on overall
resulting in poor requirement specification. size of the software product is identified.
Unpredictable risks are those risks that can not be ii) Business impact - Risk items related to the
guessed earlier. marketplace or management can be predicted.
For example certain changes in Government policies iii) Customer characteristics - Risks associated with
may affect the business project. customer-developer communication can be
identified.
iv) Process definition - Risks that get raised with the
definition of software process. This category
exposes important risks items because whichever
®
TM
is the process definition made, is then followed These steps help to prioritize the risks. Once the risks
by the whole team. are prioritized then it becomes easy to allocate the
v) Development environment - The risks associated resources for handling them.
with the technology and tool being used for
4.6.4 Risk Assessment
developing the product.
· Risk assessment is done during the project
vi) Staff size and experience - Once the technology
planning.
and tool related risks items are identified it is
· In this phase the risks are identified, analysed and
essential to identify the risk associated with
sufficient highly experienced and skilled staff then prioritized on the basis of analysis.
who will do the development. · The risk assessment is done throughout the project.
It is most needed at the starting phases of project.
vii) Technology to be built - complexity of the system
should be understood and related risk items · The goal of the risk assessment is to prioritize the
needs to be identified. risks that require an attention.
The project planner, technical staff, project manager 2. Unrealistic schedule Detailed schedule and
or budget. cost estimation, Software
performs following steps to perform following steps reuse.
for risk projection -
3. Developing wrong Making user survey,
· Establish a scale that indicates the probability of functions. understanding the
risk being real. concepts, adopting
prototyping techniques.
· Enlist the consequences of the risk.
4. Gold Plating i.e. Reviewing the
· Estimate the impact of the risk on the project and
adding features to the requirements,
product. project. prototyping.
· Maintain the overall accuracy of the risk projection 5. Developing wrong Performing prototyping,
in order to have clear understanding of the software user interface. task analysis
that is to be built.
®
TM
®
TM
Risk mitigation 2. To ensure the steps defined to avoid the risk are
Risk mitigation means preventing the risks to applied properly or not.
occur(risk avoidance). Following are the steps to be 3. To gather the information which can be useful
taken for mitigating the risks. for analyzing the risk.
1. Communicate with the concerned staff to find of
Risk management
probable risk.
Project manager performs this task when risk
2. Find out and eliminate all those causes that can
becomes a reality. If project manager is successful in
create risk before the project starts.
applying the project mitigation effectively then it
3. Develop a policy in an organization which will becomes very much easy to manage the risks.
help to continue the project even though some
staff leaves the organization. For example, consider a scenario that many people
are leaving the organization then if sufficient
4. Everybody in the project team should be
additional staff is available, if current development
acquainted with the current development activity.
activity is known to everybody in the team, if latest
5. Maintain the corresponding documents in timely and systematic documentation is available then any
manner. This documentation should be strictly as ‘new comer’ can easily understand current
per the standards set by the organization. development activity. This will ultimately help in
6. Conduct timely reviews in order to speed up the continuing the work without any interval.
work.
7. For conducting every critical activity during Board Questions
software development, provide the additional 1. What is risk projection ? Enlist steps of risk
staff if required. projection. MSBTE : Summer-15, Marks 4
5. Availability of jobs within and outside the 6. Enlist and explain different types of Software
organization. Risks. (four points)
The project manager should monitor certain MSBTE : Summer-18, Marks 4
mitigation steps. For example.
Notes
®
TM
5
5.1 Project Scheduling
Software Quality Assurance
and Security
(7) Defined Milestones : Every task or group of tasks
MSBTE : Winter-15, 16, 17, Summer-15, 16, 17, Marks 4 should be associated with a project milestone.
Definition : Project scheduling is an activity the
estimated efforts are distributed across the planned 5.1.2 Work Breakdown Structure
project duration by allocating effort to specific · Work breakdown Structure(WBS) is a process of
software engineering tasks. dividing the complex projects to simpler and
manageable tasks.
In project the scheduling can be done using two
simple activities - · In WBS, the large tasks are broken down into
manageable chunks of work. These chunks can be
1. Determining overall schedule by using different easily examined and analysed.
important milestones.
· The project manager is responsible for creation of
2. Developing detailed schedule for different tasks. WBS.
(2) Interdependency : The interdependency of each (3) In the process of breaking down the tasks, one
compartmentalized activity, task and action must be can break them down into different levels of
determined. Some tasks execute in sequence and detail. One can detail a high-level task into ten
some might execute in parallel. sub-tasks while another can detail the same
high-level task into 20 sub-tasks. Thus there is no
(3) Time Allocation : For each scheduled task, some
standard rule for breaking down of task into
number of work units must be allocated. The start
chunks. In general there is a simple rule is that -
date and end date of each allocated task must be
The smallest tasks of WBS is should not be
specified.
smaller than two weeks worth of work.
(4) Effort Validation : The number of people Another rule is - no task should be smaller than 8
allocated for the scheduled tasks must be validated hours of work and should not be larger than 80
by the project manager. hours of work.
(5) Defined Responsibilities : Every task that is (4) There are many forms of displaying the work
scheduled should be assigned to specific team breakdown structure - it can be in tree like form,
member. table or list form. For example -
(6) Defined Outcomes : Every scheduled task must
have definite outcome.
®
(5 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 5-2 Software Quality Assurance and Security
Project
Example of WBS : The work breakdown structure for a simple product development is as shown
below -
1.4 (a)
Technical 1.6 (a)
risks Implementation
1.1
1.2 1.3 1.5
Checking
Scoping the Product Proof of Integrate a,b
feasibility
product planning product
of product
1.7
Customer
feedback
Activity network show dependencies between different activities. There are some automating project
management tools using which bar chart and activity network can be generated. These tools require
database of project information as an input.
Ex. 5.1.1 Consider, some hypothetical tasks, duration and dependencies. Draw the activity network and find the critical
path.
T1 10
T2 15 T1(M1)
®
TM
T3 15 T1(M2)
T4 7 T1,T2(M3)
T5 20 T1(M1)
T6 5 T4,T5(M4)
T7 4 T6(M6)
T8 8 T7(M5)
T9 10 T6,T8(M7)
T10 12 T9(M8)
Sol. : The T1, T2, … represent various tasks. The milestones of various tasks is shown by M1, M2, … The activity
network for these activities can be as shown below.
M6 T7
T5 M4 T6 M5
T8
T1 M1 T2 M2 T3
M7
START
T9
M3
M8
T4
END T10
The minimum amount of time required by the project can be computing the longest possible path to
reach from begin to end. This path is referred as the critical path in the project and the activities along
this path are referred as the critical activities. In Fig. 5.1.3 critical path is shown by thick edge.
Ex. 5.1.2 For a software project different activities and their durations are listed as below. Draw the activity network and
find the critical path.
Duration 8 15 15 10 10 5 20 25 15 15 7 10
(in days)
Dependencies – – T1 – T2 , T4 T1 , T2 T3 T4 T3 , T6 T5 , T7 T9 T11
®
TM
Sol. :
10 days 10 days
END
T4 T5
25 days
T8
A thick line denotes the critical path. A critical path ¡ Assign time and cost to each activity.
is a longest possible path which starts from the ¡ Compute critical path.
beginning and reaches at the end and which requires ¡
Use network to help plan, schedule, monitor
minimum amount of time.
and control the project.
5.1.4 Scheduling Techniques · Example -
· The formula used in PERT to calculate number of
· There are two commonly used scheduling
working days is based on three point estimate.
techniques - PERT and CPM.
· The three point estimates are optimistic, most likely
· The PERT stands for Project management and
and pessimistic estimates.
Review Technique. This technique is used for the
projects where time needed to complete different · Formula is
activities are not known. PERT weighted average
· The CPM stands for Critical Path Method. This Optimistic time+ 4 ´ Most likely time
technique is used in conjunction with PERT and is + Pessimistic time
used for managing the well defined activities of the =
6
project.
· Example : Given that
· The PERT and CPM technique is used for -
Optimistic time = 6 days
¡ Prediction of deliverables.
¡
Most likely time = 9 days
Planning resource requirements
¡ Controlling resource allocation Pessimistic time = 12 days
¡ Internal and external program review then
¡ Performance evaluation 6 + ( 4 ´ 9) + 12
PERT weighted average = =9
· Various framework activities in PERT/CPM are - 6
¡ Define the project. The project should have · Thus it would be 9 days using PERT.
single start activity and single finish activity.
· The main advantage of PERT is that it attempts to
¡ Develop relationships among the activities. address the risk associated with duration estimates.
¡ Draw the network diagram for connecting all
the activities.
®
TM
Difference between PERT and CPM 2. Evaluate results of all the project reviews.
· Project schedule is the most important factor for 3) When multiple horizontal bars occur at the same
software project manager. It is the duty of project time on the calendar, then that means
manager to decide the project schedule and track concurrency can be applied for performing the
the schedule. tasks.
· Tracking the schedule means determine the tasks 4) The diamonds indicate the milestones.
and milestones in the project as it proceeds. · In most of the projects, after generation of time line
· Following are the various activities conducted chart the project tables are prepared. In project
during tracking of the project schedule - tables all the tasks are listed along with actual start
and end dates and related information.
1. Conduct periodic meetings. In this meeting
various problems related to the project get
discussed. The progress of the project is reported
to the project manager.
®
TM
Example
1. 2 Software development
1. 2. 1 Requirements analysis
1. 2. 2 Architectural design
1. 2. 3 Procedural design
1. 2. 4 Code
1. 3 Testing
1. 3. 1 Unit test
1. 3. 2 Integration test
1. 3. 3 Acceptance test
1. 4 Operations
1. 4. 1 Packaging
1. 4. 2 Customer training
Tasks Planned start Actual start Planned end Actual end Effort assignment
Requirement analysis 6 Sept’05
th 6 Sept’05
th 20 Sept’05
th 22 nd Sept’05 Jayashree, Padma, Lucky
Architectural design 27 Sept’05
th 27 Sept’05
th 3 Oct’05
rd 7 Oct’05
th Trupti, Varsha
Procedural design 10 Oct’05
th 12 Oct’05
th 24 Oct’05
th 25 Oct’05
th Varsha, Sachin, Devendra
M M M M M M
Customer training 1st Jan’06 4th Jan’06 22nd Jan’06 25th Jan’06 Smita, Yogita
EV = Actual Completion (%) * BAC to ensure the project will meet or exceed
stakeholder's needs and expectations.
SV = EV – PV
· The project team must develop a good relationship
CV = EV – AC with key stakeholders.
· The project quality management is performed using
SPI = EV/PV
following three key processes.
CPI = EV/AC 1. Planning Quality Management
®
TM
Fig. 5.4.2
®
TM
Analyze - In this phase defect metrics are analyzed in operation. This process is called registration to ISO
order to determine the few causes. 9000.
For a newly developing software, some organizations system that can be applied to any size or type of
are suggesting following two alternating steps - organization.
· The guideline steps for ISO 9001:2000 are
Design - In this step avoid root causes of defects and
¡ Establish quality management system - Identify
meet the customer requirements.
and manage the processes in the quality
Verify - To verify the process, avoid defects and management system.
meet customer requirements. ¡ Document the quality management system
These steps can sometimes be referred as DMADV. ¡ Support the quality
¡ Satisfy the customers
5.6.2 ISO for Software
¡ Establish quality policy
· In order to bring quality in the product and service,
¡ Conduct quality planning
many organizations are adopting the quality
assurance system. ¡ Control quality systems
· The quality assurance systems are the organizational ¡ Perform management reviews
structures that are used to bring quality in ¡ Provide quality resources
responsibilities, procedures, processes and resources.
¡ Provide quality personnel
· ISO 9000 is a family of quality assurance system. It
¡ Provide quality infrastructure
can be applied to all types of organizations. It
¡ Provide quality environment
doesn’t matter what size they are or what they do.
It can help both product and service oriented ¡ Control realization planning
organizations to achieve standards of quality. ¡ Control customer processes
· ISO 9000 is maintained by ISO, the International ¡ Control product development
Organization for Standardization and is
¡ Control purchasing functions
administered by accreditation and certification
¡ Control operational activities
bodies.
· In ISO 9000, company’s quality system and ¡ Control monitoring devices
operations are scrutinized by third-party auditors ¡ Control non confirming products
for a complaince to the standard and effective ¡ Analyze quality information
®
TM
· The Software Engineering Institute (SEI) has 3. The basis of ISO 9001 The basis of CMM is :
developed a comprehensive process meta-model is : "Say what you do "Say what you do and
emphasizing process maturity. It is predicated on a and do what you do what you say".
say."
set of system and software capabilities that should
be present when organizations reach different levels
4. Servicing activities are CMM does not have
of process capability and maturity. considered as separate maintenance as a
· The Capability Maturity Model (CMM) is used in maintenance process separate process.
in ISO.
assessing how well an organization’s processes
allow to complete and manage new software
5. ISO 9001 maintains a The CMM emphasizes
projects. quality record the need to record
· Various process maturity levels are document which information for later
clearly shows whether use in the process and
Level 1 : Initial - Few processes are defined and or not required for improvement of
individual efforts are taken. quality is achieved. the process.
This document also
Level 2 : Repeatable - To track cost schedule and indicates whether or
functionality basic project management not existing quality
system operates
processes are established. Depending on earlier effectively.
successes of projects with similar applications
necessary process discipline can be repeated.
®
TM
Optimizing
Managed
Defined
Repeatable
Initial
Fig. 5.6.3
2. Explain CMMI model with neat diagram. Basic Principles of Software Security
MSBTE : Summer-15,Marks 8 1. Protection from disclosure
3. Give the outline that defines basic elements of ISO 2. Protection from alteration
9001 : 2000 for software quality assurance.
3. Protection from destruction
MSBTE : Winter-15, Marks 4
4. Who is making the request
4. What is six sigma ? Describes the core steps of
DMAIC in detail. MSBTE : Winter-15, Marks 4
5. What rights and privileges does the requester
have
5. What is CMMI ? State two objectives of CMMI.
Briefly explain the CMMI maturity levels. 6. Ability to build historical evidence
MSBTE : Summer-16, Marks 8 7. Management of configuration, sessions and
6. Explain CMMI with its levels and neat diagram. errors/exceptions
MSBTE : Winter-16, Marks 4
5.8 Introduction to DEVOPs
7. What is philosophy of six sigma ? Explain six
sigma strategies. MSBTE : Summer-17, Marks 8 Definition : Devops is a practice in which
development and operation engineers participate
8. Describe six sigma for software engineering.
together in entire lifecycle activities of system
MSBTE : Winter-17, Marks 4
development from design, implementation to product
9. State eight benefit of ISO standards. support.
MSBTE : Winter-17, Marks 4
· The term Devops is derived from "Software
10.Explain different levels of Capability Maturity DEVelopment " and "information technology
Model Integration technique. (CMMI) OPerationS".
MSBTE : Summer-18, Marks 8 · Devops promotes a set of processes and methods
from the three department Development, IT
5.7 Software Security operations and Quality assurance that communicate
and collaborate together for development of
Software security is a concept which is implemented
software system.
to protect software against malicious attack and other
hacker risks so that the software continues to function
correctly under such potential risks.
®
TM
Secure Software Engineering Life Cylce · It is better to integrate security concerning activities
· A Software Development Life Cycle (SDLC) is a across the SDLC to help discover and reduce
framework that defines the process used by vulnerabilities early, effectively building security in.
organizations to build an application. Over the
·A Secure SDLC process ensures that security
years, multiple standard SDLC models have been
assurance activities such as penetration testing, code
proposed (Waterfall, Iterative, Agile, etc.) and used
review, and architecture analysis are an integral
in various ways to fit individual circumstances.
part of the development effort.
· In general, SDLCs include the following phases:
· The primary advantages of secure software
1. Planning and requirements. development Life cycle is -
2. Architecture and design.
(1) More secure software as security is a
3. Test planning. continuous concern.
4. Coding.
(2) Awareness of security considerations by
5. Testing and results. stakeholders.
6. Release and maintenance.
(3) Early detection of flaws in the system.
· In the past, it was common practice to perform
security-related activities only as part of testing. (4) Cost reduction as a result of early detection
This technique usually resulted in a high number of and resolution of issues.
issues discovered too late. (5) Overall reduction of business risks for the
organization.
qqq
®
TM
®
(S - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering S-2 Solved Board Question Papers
WINTER - 2015
Software Engineering Solved Paper
Semester - IV (Civil) (15116)
®
TM
SUMMER - 2016
Software Engineering Solved Paper
Semester - IV (Civil) (15162)
a) Define the terms software process, software product, software work product and software engineering.
b) What is SRS ? Explain importance of SRS.
c) What is domain analysis ? Explain with suitable examples.
d) Describe the relationship between systems engineering and software engineering.
e) Draw a use case diagram for a Bank Management System.
f) What is Waterfall Model ? State the practical situations in which it can be used.
Q.3 Attempt any four of the following : 16
®
TM
a) What is Software deployment ? State the principles to be followed while preparing to deliver the software
increment.
b) What is project scheduling and tracking ? State four reasons why project deadlines cannot be met ?
c) What is CMMI ? State two objectives of CMMI. Briefly explain the CMMI maturity levels.
Q.6 Attempt any four of the following : 16
a) Compare top - down and bottom - up approach used for integrating testing.
b) Describe different debugging strategies.
c) What is software risk ? Explain types of software risks.
d) List different ways in which the project schedule can be tracked.
e) Compare software verification and software validation.
WINTER - 2016
Software Engineering Solved Paper
Semester - IV (Civil) (16117)
6) Mobile Phone, Pager and any other Electronic Communication devices are not permissible in
Examination Hall.
Q.1 A) Answer any three of the following : 12
a) With neat diagram, explain RAD model with its advantages and disadvantages. (2 each)
b) Draw DFD level 0 and level 1 for Hotel management system.
Q.2 Answer any four of the following : 16
®
TM
SUMMER - 2017
Software Engineering Solved Paper
Semester - IV (Civil) (16172)
6) Mobile Phone, Pager and any other Electronic Communication devices are not permissible in
Examination Hall.
Q.1 Attempt any five of the following : 20
®
TM
WINTER - 2017
Software Engineering Solved Paper
Semester - IV (Civil) (11718)
®
TM
SUMMER - 2018
Software Engineering Solved Paper
Semester - IV (Civil) (21718)
6) Mobile Phone, Pager and any other Electronic Communication devices are not permissible in
Examination Hall.
Q.1 a) Attempt any three of the following : 12
a) Give difference between waterfall model and incremental model. (four points)
b) Explain following requirements of engineering tasks :
i) Negotiation ii) Validation
c) Explain Architectural Design Elements.
d) State eight characteristics of software bugs.
e) Explain the functions of Software Configuration Management repository. (SCM)
Q.4 a) Attempt any three of the following : 12
i) Explain the testing concept with its Testing Principles. (any four principles)
ii) Compare Bottom - up integration testing and top - down integration software testing. (four points)
iii) Explain the factors that Delay Project Schedule.
iv) Explain the six sigma for software engineering.
b) Attempt any one of the following : 6
i) List and explain five framework activities defined in PSP (Personal software process).
ii) Explain 4 P's software project spectrum.
Q.5 Attempt any two of the following : 16
a) Draw the behavioral analysis model for small hospital management system and illustrate the working of it.
b) List and explain the elements of analysis model with neat labeled diagram.
c) Explain different levels of Capability Maturity Model Integration technique. (CMMI)
Q.6 Attempt any four of the following : 16
qqq
®
TM
Instructions :
(1) All questions are compulsory.
(2) Illustrate your answers with neat sketches wherever necessary.
(3) Figures to the right indicate full marks.
(4) Assume suitable data if necessary.
(5) Preferably, write the answers.
(a) List and explain any four attributes of a good software. (Refer section 1.1)
(b) Explain waterfall model in detail. (Refer section 1.7.1.1)
(c) Explain functional and non functional requirements. (Refer section 2.9)
(d) What is SRS ? Explain its importance. (Refer section 2.13)
(e) Explain the concept of cohesion and coupling in software design. (Refer section 3.3.1(7))
(f) Give any four rules used during data flow design. (Refer section 3.4.1.1)
®
(S - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering S-2 Solved Sample Test Papers
(d) What are three commonly used cost estimation approaches used in software projects ? (Refer section 4.3)
(e) Explain - work break down structure. (Refer section 5.1.2)
(f) Give the full forms of PERT and CPM. (Refer section 5.1.4)
Q.2 Attempt any THREE. [12]
qqq
®
TM
Instructions :
(1) All questions are compulsory.
(2) Illustrate your answers with neat sketches wherever necessary.
(3) Figures to the right indicate full marks.
(4) Assume suitable data if necessary.
(5) Preferably, write the answers in sequential order.
(a) Define the terms - Software and Software engineering (Refer section 1.1)
(b) State and explain any two types of software (Refer section 1.4)
(c) List core principles of software engineering (Refer section 2.2)
(d) What is data object? (Refer section 3.1.1.1)
(e) What are two types of size estimation (Refer section 4.2)
(f) Define the term- Risk (Refer section 4.6)
(g) What is software quality assurance (Refer section 5.4)
Q.2 Attempt Any THREE of the Following : [12]
(a) Explain software engineering as a layered technology approach. (Refer section 1.2)
(b) Explain the essence of software engineering practice (Refer section 2.1)
(c) Explain cardinality and modality with example. (Refer section 3.1.2)
(d) Prepare any four software quality assurance guidelines and describe them. (Refer section 5.4)
Q.3 Attempt Any THREE of the Following : [12]
(a) Give the difference between size oriented metrics and function oriented metrics. (Refer section 4.2.2)
(b) Explain following with reference to design concepts in design modeling.
i) Abstraction ii) Functional independence (Refer section 3.3.1)
(c) Explain deployment principle (Refer section 2.7)
(d) Enlist basic principles of software security (Refer section 5.7)
Q.4 Attempt Any THREE of the Following : [12]
(a) Enlist various functional and non functional requirements for the bank ATM system (Refer example 2.9.1)
(b) Elaborate the software characteristic: "Software is engineered, not manufactured " (Refer section 1.3)
(c) Explain 4 P's software project spectrum (Refer section 4.1)
(d) Write short note on - Unit testing (Refer section 3.5.3.1)
®
(S - -3)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering S-4 Solved Sample Model Question Paper
(a) What is DEVOPs ? Explain its needs and benefits of DEVOPs (Refer section 5.8)
(b) Explain Risk management procedure in detail (Refer section 4.6)
(c) What are major tasks of requirement engineering? (Refer section 2.8)
qqq
®
TM
Instructions :
1) All questions are compulsory.
a) Enlist and explain software characteristics (any two) (Refer section 1.3)
b) Define software on engineering. (Refer section 1.1)
c) State need of Software Requirement Specification (SRS). (Refer section 2.14)
d) Define Reactive Risk strategies.
Ans. : Reactive Risk Strategy is a strategy in which certain action occurs in response to the risk.
e) Specify following cost directives of cocomo : (Refer section 4.4)
i) Product attributes (any two) ii) Hardware attributes (any two).
f) Differentiate between software quality management and software quality assurance (any two points).
(Refer section 5.3)
g) Define software quality assurance. (Refer section 5.4)
Q.2 Attempt any Three of the following : [12]
a) Distinguish between perspective process model and agile process model. (Refer section 1.8)
b) Describe any four principles of communication for software engineering. (Refer section 2.3)
(S - 5)
R
c) Draw proper labeled “LEVEL I Data Flow Diagram” (DFD) for student attendance system.
Ans. :
Login
Student Student Attendance
System
Response
1.0
Login Check details
Student Login Student info
Response Response
1.2
Submit query update
Apply for Leave record
leave
Response acknowledge
e) Prepare time line chart for Library Managements System (five days a week) Consider phases of SDLC.
(Refer section 5.2.1)
Q.5 Attempt any Two of the following : [12]
a) Enlist Requirement Gathering and Analysis for web based project for registering candidates for contest (any six
points).
Ans. :
(1) The candidate must enter personal information for user name, and password, email_id.
(2) The system should validate his/her email_id.
(3) The system should sent the system generated user name and password to the user through his email.
(4) The system should sent the "Successful registration" message to the user. If the registration gets failed the
system should send the appropriate message to the user and it should consider such candidate as invalid.
(5) The candidate must be able to log-in with the user name and password.
(6) If the user forgets the password, the system should provide the assistance to the candidate with the help of
his/her authorized email-id
b) Differentiate between White box and Black box testing (any six points). (Refer section 3.5.2)
c) Describe Co-Como II model for evaluating size of software project with any three parameters in detail.
(Refer section 4.6)
Q.6 Attempt any Two of the following : [12]
a) Draw and explain transition diagram from requirement model to design model. (Refer section 5.3.1)
b) Describe CMMI. Give significance of each level. (Refer section 5.6.3)
c) Identify and enlist requirement for given modules of employee management software :
i) Employee detail ii) Employee salary iii) Employee performance
Ans. : (i) Employee details
qqq
Notes