Software Engineering
Software Engineering
Software Engineering
SOFTWARE ENGINEERING
Anuradha A. Puntambekar
M.E. (Computer)
Formerly Assistant Professor in
PE.S. Modern College of Engineering, Pune
“TECHNICAL
SZ PUBLICATIONS
SINCE 1993 An Up-Thrust for Knowledge
SOFTWARE ENGINEERING
Published by :
(x= . TECHNICAL Amit Residency, Office No.1, 412, Shaniwar Peth,
PUBLICATIONS Pune - 411030, M.S. INDIA, Ph.: +91-020-24495496/97
Hee 1983 ‘An Up-Thrust for Knowledge ) Email : sales@technicalpublications.org Website : www.technicalpublications.org g
Printer :
Yogiraj Printers & Binders
Sr.No. 10/1A,
Ghule Industrial Estate, Nanded Village Road,
Tal. - Haveli, Dist. - Pune - 411041
ISBN 978-93-90450-41-1
9789390450411[1] (ii)
PREFACE
The importance of Software Engineering is well Rnown in various engineering fields.
Overwhelming response to our books on various subjects inspired us to write this book. The
book is structured to cover the key aspects of the subject Software Engineering.
The book uses plain, lucid language to explain fundamentals of this subject. The booR
provides logical method of explaining various complicated concepts and stepwise methods
to explain the important topics. Each chapter is well supported with necessary illustrations,
practical examples and solved problems. All chapters in this book are arranged in a proper
sequence that permits each topic to build upon earlier studies. All care has been taken to
make students comfortable in understanding the basic concepts of this subject.
Representative questions have been added at the end of each section to help the
students in picking important points from that section
The book not only covers the entire scope of the subject but explains the philosophy of
the subject. This makes the understanding of this subject more clear and makes it more
interesting. The book will be very useful not only to the students but also to the subject
teachers. The students have to omit nothing and possibly have to cover nothing more.
We wish to express our profound thanks to all those who helped in making this book a
reality. Much needed moral support and encouragement is provided on numerous
occasions by our whole family. We wish to thank the Publisher and the entire team of
Technical Publications who have taken immense pain to get this book in time with quality
printing.
Any suggestion for the improvement of the book will be acknowledged and well
appreciated.
Authors
A. A. Puntambekar
Dedicated to God
(iii)
SYLLABUS
Software Engineering - 210253
Credit Scheme Examination Scheme and Marks
(Chapter 2)
Estimation for Software Projects : The Project Planning Process, Defining Software
Scope and Checking Feasibility, Resources management, Reusable Software Resources,
Environmental Resources, Software Project Estimation, Decomposition Techniques,
Software Sizing, Problem-Based Estimation, LOC-Based Estimation, FP-Based Estimation,
Object Point (OP)-based estimation, Process-Based Estimation, Estimation with Use Cases,
Use- Case - Based Estimation, Reconciling Estimates, Empirical Estimation Models, The
(iv)
Structure of Estimation Models, The COCOMO II Mode, Preparing Requirement
Traceability Matrix Project Scheduling : Project Scheduling, Defining a Task for the
Software Project, Scheduling. Suggested Free Open Source Tools : Gantt Project,
Agantty, Project Libre. (Chapter 3)
Design Concepts : Design within the Context of Software Engineering, The Design Process,
Software Quality Guidelines and Attributes, Design Concepts - Abstraction, Architecture,
design Patterns, Separation of Concerns, Modularity, Information Hiding, Functional
Independence, Refinement, Aspects, Refactoring, Object-Oriented Design Concept, Design
Classes, The Design Model , Data Design Elements, Architectural Design Elements, Interface
Design Elements, Component-Level Design Elements, Component Level Design for Web
Apps, Content Design at the Component Level, Functional Design at the Component Level,
Deployment-Level Design Elements. Architectural Design : Software Architecture, What is
Architecture, Why is Architecture Important, Architectural Styles. A brief Taxonomy of
Architectural Styles. Suggested Free Open Source Tool : Smart Draw (Chapter 4)
Risk Management : Software Risks, Risk Identification, Risk Projection, Risk Refinement,
Risk Mitigation, Monitoring, and Management, The RMMM Plan. Software Configuration
Management : Software Configuration Management, The SCM Repository The SCM
Process, Configuration Management for any suitable software system. Suggested Free
Open Source Tools : CF Engine Configuration Tool, Puppet Configuration Tool.
(Chapter 5)
(v)
TABLE OF CONTENTS
(vi)
1 PF COMCTIP FAITE WIC ONS cncacnncssnresrsasesdeocnanandnnns costpesstestrenatancsanstnapeiessbpresacdduaste
AES UN lect, PROCESS iv. Aiccsrcaetevedonivaswaensvénclvedincranseviconseetnedévedtosdlivantirbensbenss
1.19 Agile Software Development ou... cccceeseeseeseseteteceseseseesesesseeeseaeseeeeeeeeeees
1, 19:TApility:Princholes. ciel stsqetelesestentecestcventinslacdsstatecihsaladbsliseslepbotedtenseanesser
A c20 Agiles Wty els: oe. basal nA says cng nsadenadancl deresenct nse eM lae is aybanghevedbestbets baled matanette 1-35
1.20.1 Adaptive Software Development (ASD).........ccccccccseeeceecsessaeeecesseaeeeeeeee 1-35
VE 20.3 ZSCHUIM teas sada ncotieccndaconealatet aactea oncacn tet scheass Gaaateaahes eseeoasleatantsdaesaleseseasaacaistassecaseena
TiZOS CLYSTAL ater asens die sedessi'ecede eb devseaaron neuen aseandvacin adueedstdachasallrasanisa saris dees ace sadobdatssdaeohed
Unit - II
(vii)
2.3.3 Working Towards Collaboration ...........cccccsseeeceececesseeeceeeeseeseeceseaeeeeeesaeaes 2-9
Class Based Moclelling. ax de srs. snscannsve seqnee sans canhaanne Sead hecntneuanpaunes deepens
2.9.1 Objects and Object Classes ......ccccssssescsesssssssessecesssssssesesesseesseeeseeceees 2-29
2.10 BEXARea Bel tL ONT PR cots essen ecentirerecer enezsanzznes setnsererenetsesszcasatarasutopedepersncerctoesseeaessenses 2-42
2.10.1 Data Object, Attributes and Relationships .............cccccccseeseteeeececeeeteeeseaee 2-43
ZiAASpENAMIDICS | csassoseepeasezesscxasansecacened¥tepboseepeassacsatheasWesaseaag¥seteesad
dvdeshasespetse pest edaals 2-56
2.12. BENAVIOLAl WAGGING Peck Poa te tenn ee eseenPonnev enn stten ihn dahidad hutch dk aicipinsifed 2-73
2.12.1 Identifying Events with Use Cases ........cccccceeseeeeeeeeeeeneeeeseeeeansesenaeeaanaeeae 2-73
2 AZIZ SCALE, REPNESCHILALION’.sczasscsscenssesasecsesscsadousessaaaépanesaosessiecsesdbdes
sagas sedaseaseeeesey 2-73
ZrLZiSeSCQUEN
CH DIARTAND 2.2, cxssacnssseaasedesdesuesdecesarecssend¥uceetacedtsceseassseatesacessaaspssaaeanaes 2-74
DiseL | HUMAN RESGUNGOS srg rys dace atcadén ce eddices pe=dapecesendaentagtadds ededecesetecegesedssdaepeagiagdends 3-4
3.3.2 Reusable Software RESOUFCES..........eesescesseeeeeessssessesesecseseseseecseeseeeeseeasscess 3-5
3.3.3 “Environmental RESOUrCES <...c...s.sepecessesienisoosesesadagaasnesntegageaguscopecsoptsvopeagorsseens 3-5
AAAS RETIN GMIGNIE SF. scales See tedsese es taseuetes tess receestestegesiatee cant eectestactes seen ten teceensitenioeds 4-8
BAT :2- COUN Ba 5sda.Pe Biv soeden TiidiaZdeesSeeace eshte cnscesteas sasadectrevetel eesBicsaléed ve lonsdensTesaiel se 4-10
(xii)
BiA2.1- DOMINANE ISSUCS i acecsuesesceccsscansecactegseaspuctecseeseaccteatedscdtseseqsenscecsacses
seas eeserdnase 5-23
Upham
G.6:254- ™ SnOke: TOStU Pg. «0: says paut gen geen seesydes te gcvnguvagerhasgevsgavigersgen
evs gasseevaeh ten eigeeudes 6-15
6.6.3.2, Security TOSting fag d pcsceng sd enspeed acd gosh geek acneregesd pot gesedeagstb yesh eth gat onc getbeshes 6-16
6.7. Testing Strategies for Object Oriented Software... cece eteeeteeeeees 6-17
6.722 UNE Festingsin-OO Content: gcsestestcccs osasshastsedsogtessdaccapteatecsadales
tens seesesteceicees 6-18
GLEE TPS TST ssc taye dec eay deseb che vasdban Meeelietehp bchabbacncncus die eyo daskihenctabttoeiees 6-22
GrLI* White BOX, TESTING... catncetacn cass cssscacsstacntesnsasstacassssnsecetanasonssnssssssessetsransasstance’ 6-22
6:11.10 Basis‘ Path Testing caveserssccnsedhlersveerSaqessestessdesaaceeadebearsenateeadtenetade
dchesatveauale 6-22
Syllabus
Contents
1.1 Introduction to Software Engineering
1.2 The Nature of Software
1.3 Defining Software
1.4 Software Engineering Practice
1.5 Software Characteristics .................... May-11,14,19, Aug.-17,
w OC4.-18, DOC.-16, 0... cececccsececseceeeeeceeees Marks 10
1.6 Software Engineering Myths . April-16, Aug. 17, Dec.-17, 18, 19,
.. Oct-19 .-.. Marks 5
1.7 Generic Process Model...... ..Dec.-19, May-13 ... Marks 7
1.8 Defining Framework Activity... 45 .. Marks 7
1.9 Identifying a Task Set.. ..Dec.-11, April-15, 16, Aug.-17
«- May-18, 066.-19 0... cececcseceeseceeeeeeeteeente Marks 8
1.10 Process Pattern
1.11 Process Assessment and Improvement
1.12 Prescriptive Process Model
1.13 The Waterfall Model .. April-16, Dec.-18, Oct.-19 ... .. Marks 6
1.14 Increment Process Model ..--. May-18, May-19, Dec.-19..... ... Marks 6
1.15 Evolutionary Process Model
1.16 Comparison between Various Process Models ..... May-11,12,13, 14,
veceseeceeeeess DOC#12,13 oe ccesecessecesseess Marks 8
1.17 Concurrent Models
1.18 Unified Process
1.19 Agile Software Development.............Aug.-17, Dec.-17, 18, Oct.-19, May-19... Marks 5
1.20 Agile Methods
1.21. Plan Driven and Agile Development
1.22 Multiple Choice Questions
Software Engineering 1-2 Introduction to Software Engineering and Process Models
“Software engineering is a discipline in which theories, methods and tools are applied to
develop professional software product.”
In software engineering the systematic and organized approach is adopted. Based on the
nature of the problem and development constraints various tools and techniques are applied in
order to develop quality software.
The definition of software engineering is based on two terms :
e Discipline : For finding the solution to the problem an Engineer applies appropriate
theories, methods and tools. While finding the solutions, Engineers must think of the
organizational and financial constraints. Within these constraints only, he/she has to find
the solution.
e Product : The software product gets developed after following systematic theories,
methods and tools along with the appropriate management activities.
Defining Software
Software is nothing but a collection of computer programs and related documents that are
intended to provide desired features, functionalities and better performance.
Software products may be :
1. Generic : That means developed to be sold to a range of different customers.
2. Custom : That means developed for a single customer according to their specification.
4. The produce is getting consumed : While developing the software system, the
documentation must be maintained so that the maintenances of the system becomes easy.
5. Be Open to future : [f some changes need to be incorporated in the system, then those
must be accommodated easily.
6. Plan for Reuse : The software system components can be made reusable so that the time
and efforts can be saved. The programming techniques like Object oriented programming
can be used for it.
7. Think : Before performing every software engineering activity think and understand it.
May-11,14,19, Aug.-17,
Software Characteristics
1) In early stage of hardware development process the failure rate is very high because of
manufacturing defects. But after correcting such defects the failure rate gets reduced.
2) The failure rate remains constant for some period of time and again it starts increasing
because of environmental maladies (extreme temperature, dusts, and vibrations).
On the other hand software does not get affected from such environmental maladies. Hence
ideally it should have an “idealized curve”. But due to some undiscovered errors the
failure rate is high and drops down as soon as the errors get corrected. Hence in failure
rating of software the “actual curve” is as shown below :
Failure curves
(Bath tub curves)
Hardware curve
Side effect
Manufacturing
defects
Failure
During the life of software if any change is made, some defects may get introduced. This
causes failure rate to be high,
Before the curve can return to original steady state another change is requested and again
wn
component wears out it can be replaced by another component but it is not possible in case
of software.
8 Therefore software maintenance is more difficult than the hardware maintenance.
e Most software is custom built rather than being assembled from components
1) While developing any hardware product firstly the circuit design with desired functioning
properties is created. Then required hardware components such as ICs, capacitors and
registers are assembled according to the design, but this is not done while developing
software product.
3) However, now the software development approach is getting changed and we look for
reusability of software components.
4) It is practiced to reuse algorithms and data structures.
5) Today software industry is trying to make library of reusable components.
For example : In today’s software, GUI is built using the reusable components such as
message windows, pull down menus and many more such components.
6) The approach is getting developed to use in-built components in the software. This stream
of software is popularly known as component engineering.
Difference between Hardware Engineering and Software Engineering
2 In early stage of hardware development On the other hand, software does not get
process, the failure rate is very high affected from the environmental maladies.
because of manufacturing defects. But But due to some undiscovered errors the
after correcting such defects the failure failure rate is high and drops down as soon
rate gets reduced. The failure rate as the errors get corrected.
remains constant for some period of time
and again it starts increasing because of
environmental maladies.
3, There are spare parts available for the There are no spare parts for software
hardware components. components to replace.
4. The hardware unit is assembled from Most software is custom built rather than
components. being assembled from components.
wa Review Questions
1. Define software engineering. What are the software characteristics ? What are the various
categories of software ? SPPU : May-14, Marks 10
2. Define software engineering. How software engineering is different from hardware
engineering ? Justify. SPPU : May-11, Marks 8
There are some misbelieves in the software industry about the software and process of
building software. For any software developer it is a must to know such beliefs and reality
about them. Here are some typical myths -
e Myth : Using a collection of standards and procedures one can build software.
(Management Myth)
e Reality : Even though we have all standards and procedures with us for helping the
developer to build software, it is not possible for software professionals to build desired
product. This is because - the collection which we have should be complete, it should
reflect modern techniques and more importantly it should be adaptable. It should also help
the software professional to bring quality in the product.
e Myth : Add more people to meet deadline of the project. (Management Myth)
Reality : Adding more people in order to catch the schedule will cause the reverse effect on
the software project i.e. software project will get delayed. Because, we have to spend more
time on educating people or informing them about the project.
e Myth : Ifa project is outsourced to a third party then all the worries of software building
are over. (Management Myth)
¢ Reality : When a company needs to outsource the project then it simply indicates that the
company does not know how to manage the projects. Sometimes, the outsourced projects
require proper support for development.
e Myth : Even if the software requirements are changing continuously it is possible to
accommodate these changes in the software. (Customer Myth)
e Reality : It is true that software is a flexible entity but if continuous changes in the
requirements have to be incorporated then there are chances of introducing more and more
errors in the software. Similarly, the additional resources and more design modifications
may be demanded by the software.
e Myth : We can start writing the program by using general problem statements only. Later
on using problem description we can add up the required functionalities in the program.
(Customer Myth)
¢ Reality : It is not possible each time to have comprehensive problem statement. We have to
start with general problem statements; however by proper communication with customer
the software professionals can gather useful information. The most important thing is that
the problem statement should be unambiguous to begin with.
e Myth : Once the program is running then its over! (Practitioner's Myth)
®
TECHNICAL PUBLICATIONS™©~ An up thrust for knowledge
Software Engineering 1-7 Introduction to Software Engineering and Process Models
e Reality : Even though we obtain that the program is running major part of work is after
delivering it to customer.
e Myth : Working program is the only work product for the software project. (Practitioner's
Myth)
e Reality : The working program/software is the major component of any software project
but along with it there are many other elements that should be present in the software
project such as documentation of software, guideline for software support.
e Myth: There is no need of documenting the software project; it unnecessarily slows down
the development process. (Practitioner's Myth)
e Reality : Documenting the software project helps in establishing ease in use of software. It
helps in creating better quality and maintaining the software system. Hence documentation
is not wastage of time but it is a must for any software project.
a Review Questions
2. What are the practitioner’s myths ? Discuss the reality of these myths.
8, End Sem, Marks 5
3. List and explain practitioner’s myth and its realities SPPU : Oct.-19, In Sem, Marks 5
© Software engineering is a layered technology. Any software can be developed using these
layered approaches. Various layers on which the technology is based are quality
management layer, process layer, methods layer, tools layer.
Automatic
Software engineering ‘Support for software
Provide
technical details
for software
£ Tools 7 Foundation
of software
Backbone
of software
ae eS
Quality management
e In method layer the actual method of implementation is carried out with the help of
requirement analysis, designing, coding using desired programming constructs and testing.
2. Review Question
The process framework is required for representing the common process activities.
As shown in Fig. 1.8.1, the software process is characterized by process framework
activities, task sets and umbrella activities.
Software Process
Process Framework
Umbrella Activities
Action # 1.1
Framework « Tasksets | Work Task
Activity # 1 Milestone
SQA Paints
Action # 1.n
Framework ¢ Tasksets | Work Task
Activity #n. Milestone
SQA Points
2 Review Question
1. What are the various umbrella activities applied throughout a software project ?
SPPU : May-16, End Sem, Marks 7
Task sets : The task set defines the actual work done in order to achieve the software
objective. The task set is used to adopt the framework activities and project team requirements
using :
© Collection of software engineering work tasks
oO Project milestones
© Software quality assurance points
Umbrella activities : The umbrella activities occur throughout the process. They focus
on project management, tracking and control. The umbrella activities are
1. Software project tracking and control : This is an activity in which software team can
assess progress and take corrective action to maintain schedule.
Risk management : The risks that may affect project outcomes or quality can be
analyzed.
Software quality assurance : These are activities required to maintain software quality.
Formal technical reviews : It is required to assess engineering work products to
uncover and remove errors before they propagate to next activity.
Software configuration management : Managing of configuration process when any
change in the software occurs.
Work product preparation and production : The activities to create models, documents,
logs, forms and lists are carried out.
Reusability management : It defines criteria for work product reuse.
Measurement : In this activity, the process can be defined and collected. Also project
and product measures are used to assist the software team in delivering the required
software.
Process Pattern
Process is defined as a series of activities in which one or more inputs are used to produce
one or more outputs.
The process pattern is a template which appears as a general solution to a common
problem.
e Problem e Solution
e Resulting context e Known uses
The description of process pattern is as follows -
Pattern name
The pattern name should be a meaningful name given to the pattern. From pattern name
one can guess its functionality.
Intent
The objective or the purpose of the pattern should be described here.
Type
The type of pattern should be specified here.
Ambler has suggested three types of patterns
1) Task Pattern - It represents the software engineering action or work task which is a part of
process. For example, Formal Technical review is a task pattern.
2) Stage Pattern - It defines the process framework activity. A framework activity has
multiple work tasks; hence stage pattern consists of multiple task patterns. For example,
Coding phase is a stage pattern.
3) Phase Patterns - It defines the sequence of framework activities. For example the phrase
pattern can be spiral model or rapid prototype model.
Initial context
In this section the conditions under which the pattern applies are descri ibed.
Sometimes the entry conditions must be true before the process begins.
Solution
Every problem for which pattern has to be described should be accompanied with some
solution. For example: The problem of insufficient requirements has solution, That is -
Establish effective communication with the customer. Ask questions in order to obtain
meaningful requirements. Conduct timely reviews to modify/redefine the requirements. This
solution will help the software developer to get useful information before the actual work
starts.
Resulting context
It describes the results after successful implementation of pattern. The resulting context
should have following type of information on successful completion of pattern -
1. The team-related or organizational activities that must have occurred.
2. Exit state for the process.
3. The software engineering information or project information that has been developed.
Known uses/Examples
The specific instances or applications in which the described pattern is useful should be
mentioned under this section. In other words we describe applicability of the pattern. For
example : spiral model is useful for the large scale projects in which work products must be
examined in several iterations.
Software process
ee !
Analyzed by Ne
By improving the { Capabilities and
process changes risk of processes
in it can be made Software process can be identified
assessment
Leads to Leads to
Software process Capability
improvement Helps in determination
Process assessment is an activity in which it is ensured whether the software meets the
basic criteria for successful software engineering project.
This method provides the diagnostic technique for internal process assessment.
SPICE
Using this standard all the requirements are analyzed for software process assessment. This
standard helps in doing an objective evaluation on efficiency of any process.
ISO 9001:2000
This is a popularly used standard for improving the overall quality of the organization. The
International Organization for Standardization i.e. ISO has developed this standard.
Incremental Prototyping
model
Spiral model
RAD model :
Concurrent
development model
e The software development team must decide the process model that is to be used for
software product development and then the entire team must adhere to it. This is necessary
because the software product development can then be done systematically.
* Each team member will understand - what is the next activity and how to do it. Thus
process model will bring the definiteness and discipline in overall development process.
e Every process mode! consists of definite entry and exit criteria for each phase. Hence
the transition of the product through various phases is definite.
e Ifthe process model is not followed for software development then any team member can
perform any software development activity, this will ultimately cause a chaos and software
project will definitely fail without using process model. it is difficult to monitor the
progress of software product. Thus process model plays an important rule in software
engineering.
Maintenance
In requirement gathering and analysis phase the basic requirements of the system must
be understood by software engineer, who is also called Analyst. The information domain,
function, behavioural requirements of the system are understood. All these requirements
are then well documented and discussed further with the customer, for reviewing.
The design is an intermediate step between requirements analysis and coding.
Design focuses on program attributes such as -
Data structure
0
Software architecture
oO0
Interface representation
Algorithmic details
The requirements are translated in some easy to represent form using which coding can be
done effectively and efficiently. The design needs to be documented for further use.
Coding is a step in which design is translated into machine-readable form. If design is
done in sufficient detail then coding can be done effectively. Programs are created in this
phase.
Testing begins when coding is done. While performing testing the major focus is on logical
internals of the software. The testing ensures execution of all the paths, functional
behaviours. The purpose of testing is to uncover errors, fix the bugs and meet the
customer requirements.
Maintenance is the longest life cycle phase. When the system is installed and put in
practical use then error may get introduced, correcting such errors and putting it in use is
the major purpose of maintenance activity. Similarly, enhancing system's services as
new requirements are discovered is again maintenance of the system.
This model is widely used model, although it has many drawbacks. Let us discuss benefits
and drawbacks.
Sc meee Explain how water-fall model is applicable for the development of the following
stems :
Solution :
a) University accounting system : If the software developers who have the experience in
developing the account systems then building university account system based on existing
design could be easily managed with water-fall model.
Interactive system that allows railway passengers to find time and other information
7
—
Once the requirements are well defined then using disciplined design, coding and testing
phases the required system can be built using water-fall model.
Solution :
e The linear nature of linear sequential model brings a situation in the project that some
project team members have to wait for other members of the team to complete the
dependent tasks. This situation is called “blocking state” in linear sequential model.
e For example, after performing the requirement gathering and analysis step the design
process can be started.
e Hence the team working on design stage has to wait for gathering of all the necessary
requirements.
e Similarly the programmers can not start coding step unless and until the design of the
project is completed.
1. What are the elements of waterfall model ? State its merits and demerits.
SPPU : April-16, In Sem, Marks 6
2. Explain classic life cycle paradigm for software engineering and problems encountered
when it is applied. SPPU : Dec.-18, End Sem, Marks 5
In this model, the initial model with limited functionality is created for user's
understanding about the software product and then this model is refined and expanded in later
releases.
© The incremental model has same phases that are in waterfall model. But it is iterative in
nature. The incremental model has following phases.
1. Analysis 2. Design
3. Code 4. Test
e The incremental model delivers series of releases to the customer. These releases are called
increments. More and more functionality is associated with each increment.
e The first increment is called core product. In this release the basic requirements are
implemented and then in subsequent increments new requirements are added.
When to choose it ?
3. Fora very small time span, atleast core product can be delivered to the customer.
Increment with
enhanced
functionalities
Software functionality
Increment #1 \ t with
~+— Increment with very
Cet limited functionality
Time
Demerits
1) System structure tends to degrade when new increment is getting added to the existing
system. This actually spends time and money on refactoring to improve the software.
2) It is not cost effective to produce document for every version of the system, hence many
times the complete process is not getting documented.
e The RAD model is a type of incremental process model in which there is extremely short
development cycle.
e When the requirements are fully understood and the component based construction
approach is adopted then the RAD model is used.
e Using the RAD model the fully functional system can be developed within 60 to 90 days.
e Various phases in RAD are Requirements Gathering, Analysis and Planning, Design, Build
or Construction and finally Deployment.
e Multiple teams work on developing the software system using RAD model parallely.
e In the requirements gathering phase the developers communicate with the users of the
system and understand the business process and requirements of the software system.
e During analysis and planning phase, the analysis on the gathered requirements is made
and a planning for various software development activities is done.
Development process
Team#n
Designal
Team#2 .
x Build
Requirements Design a
gathering
D
e
Team#1 Build p
Analysis |
Design 1 :
and planning
Build
e During the design phase various models are created. Those models are Business model,
data model and process model.
e The build is an activity in which using the existing software components and automatic
code generation tool the implementation code is created for the software system. This code
is well tested by its team. The functionalities developed by all the teams are integrated to
form a whole.
e Finally the deployment of all the software components (created by various teams working
on the project) is carried out.
7% Review Questions
1. Explain with neat diagram incremental model and state its advantages and disadvantages
May-18, End Sem, Marks 6
2. Whatare the conditions in which rapid application development model is preferred?
May-19, End Sem, Marks 5
3. Explain RAD model with the help of diagram Dec.-19, End Sem, Marks 6
1.15.1. Prototyping
Communication Building of
with > quick
customer design
Cee Construction
delivery ———— of
and WwW
feedback Dro be
When to choose it ?
Software applications that are relatively easy to prototype almost always involve Human-
machine Interaction (HCI) the prototyping model is suggested.
A general objective of software is defined but not detailed input, processing or output
requirements. Then in such a case prototyping model is useful.
When the developer is unsure of the efficiency of an algorithm or the adaptability of an
operating system then prototype serves as a better choice.
Merits
1. The development team has adequate domain knowledge.
2. A\ll the end users are involved in all phases of development.
3. There is use of reusable components.
Drawbacks of prototyping
1. In the first version itself, customer often wants “few fixes” rather than rebuilding of the
system whereas rebuilding of new system maintains high level of quality.
2. The first version may have some compromises.
Sometimes developer may make implementation compromises to get prototype working
w
quickly. Later on developer may become comfortable with compromises and forget why
they are inappropriate.
1. Some requirements are gathered The requirements are precisely defined and there
initially, but there may be change in is no confusion about the final product of the
requirements when the working — software.
prototype is shown to the customer.
2: The development team has adequate The development team with less domain
domain knowledge. Similarly they knowledge can be accommodated due to iterative
can adopt the new technologies if nature of this model. The change in technology in
product demands. the later phase can not be tolerated.
3. All the end-users are involved in all All the end-users need not be involved in all the
phases of development. phases of development.
e This model possess the iterative nature of prototyping model and controlled and
systematic approaches of the linear sequential model.
e This model gives efficient development of incremental versions of software. In this model,
the software is developed in series of increments.
e The spiral model is divided into a number of framework activities. These framework
activities are denoted by task regions.
e Usually there are six tasks regions. The spiral model is as shown in Fig. 1.15.2.
e Spiral model is realistic approach to development of large-scale systems and software.
Because customer and developer better understand the problem statement at each
evolutionary level. Also risks can be identified or rectified at each such level.
e In the initial pass, product specification is built and in subsequent passes around the spiral
the prototype gets developed and then more improved versions of software gets developed.
Customer
communication
= Engineering
Concept
development
Project entry projects
point axis
New
product
development
rojects
Product
enhancement
projects
Product
maintenance,
projects
Customer evaluation Construction
and feedback and release
e During planning phase, the cost and schedule of software can be planned and adjusted
based on feedback obtained from customer evaluation.
e In spiral model, project entry point axis is defined. This axis represents starting point for
different types of projects.
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 project then at entry point 2
the product development process starts. Hence entry point 2 is called product development
project entry point. The development of the project can be carried out in iterations.
e In each region, number of work tasks are carried out depending upon the characteristics of
project. For a small project relatively small number of work tasks are adopted but for a
complex project large number of work tasks can be carried out.
e In spiral model, the software engineering team moves around the spiral in a clockwise
direction beginning at the core.
Advantages of spiral model
1. The development team with less domain The development team has adequate
knowledge can be accommodated due to domain knowledge. Similarly they can
iterative nature of this model. The change in adopt the new technologies if product
technology in the later phase can not be demands.
tolerated. |
2 All the end-users need not be involved in all All the end-users are involved in all phases
the phases of development. of development.
3. Funding are not stable for the projects that Funding are stable for these type of |
can be developed using spiral model. projects.
ere ee ee dt
4. The requirements that are gathered and Some requirements are gathered initially,
analyzed are high reliability requirements. but there may be change in requirements
| when the working prototype is shown to
the customer.
| Example 1.15.1 BG you move outward along with process flow path of the spiral model, what can
we say about the software that is being developed or maintained ?
Solution : When software engineering team moves around the spiral, the first circuit around
the spiral results in development of product specification. The subsequent passes around the
spiral might be used to develop prototype in more subsequent manner. In each pass, through
planning region, some adjustments to project plan are made. Cost and schedule adjustments
can also be made according to customer feedback.
ce How does “Project Risk" factor affect the spiral model of software development ?
Solution : The spiral model demands considerable risk assessment because if a major risk is
not uncovered and managed, problems will occur in the project and then it will not be
acceptable by end user.
ct eee Mow does a spiral model represent a process suitable to represent a real time
problem ?
Solution : Spiral model represents a process suitable to represent a real time problem because
of following reasons -
1. Software evolves as the project progresses. And at every evolutionary level the risks are
identified and managed and risks are reduced at every stage.
2. It enables the developer to apply the prototype approach at any stage in the evolution of the
product. It helps in adopting the approach systematic stepwise development of the product.
3. The iterative frameworks help in analyzing the product at every evolutionary stage.
The spiral model demands a direct consideration of technical risks at all stages of project.
The risks are reduced before they get problematic.
l. Some requirements are gathered The requirements are precisely defined and there
initially, but there may be change in is no confusion about the final product of the
requirements when the working — software.
prototype is shown to the customer.
2. The development team has adequate The development team with less domain
domain knowledge. Similarly they can knowledge can be accommodated due to
adopt the new technologies if product iterative nature of this model. The change in
demands technology in the later phase cannot be tolerated.
3. All the end-users are involved in all All the end-users need not be involved in all the
phases of development phases of development.
4. Risks can be identified at the end Risks can be identified and reduced before they
which may cause failure to the get problematic.
product.
De The customer can see the working The customer can see the working product at
model of the project only at the end. certain stages of iterations.
After reviewing of the working model;
if the customer gets dissatisfied then it
By This model is good for small systems. This model is good for large systems.
When the Due to iterative nature When developer is When the requirements
requirements are of this model, the risk unsure about — the re reasonably well
2
reasonably well identification and efficiency of an defined, the development
defined and the rectification is done algorithm or the effort suggests a purely
development effort before they get adaptability of an linear effort and when
suggests a purely problematic. Hence for operating system then limited set of software
linear effort then the handling real time the prototyping functionality is needed
waterfall model is problems the spiral model is chosen. quickly then the
7% Review Questions
2. Explain evolutionary process models mentioning the types of projects for which they are
suitable. SPPU : May-12, Marks 6
Explain the waterfall model with work products of each activity. Eig yURBVENe ERE crs
Concurrent Models
e The modeling or designing phase of software development can be in one of the states like
under development, waiting for modification, under revision or under review and so on.
Modeling activities
Under
development
Waiting
for
modification
Transition
from
ne
hoe Getti Getting
a revised reviewed
other
e All the software development activities exist concurrently in this model but these activities
can be in various states.
e These states make transitions. That is during modeling, the transition from under
development state to waiting for modification state occurs.
« This model basically defines the series of events due to which the transition from one state
to another state occurs. This is called triggering. These series of events occur for every
software development activity, action or task.
* This model defines various activities that occur concurrently and a network of activities is
defined.
Advantages
1. All types of software development can be done using concurrent development model.
2. This model provides accurate picture of current state of project.
3. Each activity or task can be carried out concurrently. Hence this model is an efficient
process model.
Unified Process
The unified process is a framework for object oriented models. This model is also called as
Rational Unified Process model (RUP). It is proposed by Ivar Jacobson, Grady Bootch and
James Rumbaugh. This model is iterative and incremental by nature. Let us discuss various
phases of unified process.
e In this phase there are two major activities that are conducted : Communication and
planning.
e By having customer communication business requirements can be identified.
e Then a rough architecture of the system is proposed. Using this rough architecture it then
becomes easy to make a plan for the project.
e Use cases are created which elaborates the user scenario.
e Using use cases the sequence of actions can be identified.
e Thus use cases help to identify the scope of the project which ultimately proves to be the
basis for the plan.
Elaboration
Planning
Communication Modeling
Construction
Deplayment
| a)
Release
Elaboration
e Elaboration can be done using two activities : Planning and Modelling.
e In this phase the use cases are redefined. And an architectural representation is created
using five models such as use-case model, analysis model, design model, implementation
model and deployment model.
Construction
e The main activity in this phase is to make the use cases operational.
e The analysis and design activities that are started in elaboration phase are completed in this
phase and a source code is developed which implements all desired functionalities.
e Then unit testing is conducted and acceptance testing is carried out on the use cases.
Transition
e In the transition phase all the activities that are required at the time of deployment of the
software product are carried out.
e Beta testing is conducted when software is delivered to the end user.
e User feedback report is used to remove defects from the created system.
e Finally software team prepares user manuals, installation guides and trouble shooting
procedures. This makes the software more usable at the time of release.
Production
e This is the final phase of this model. In this phase mainly the maintenance activities are
conducted in order to support the user in operational environment.
e Various work products that may get generated in every phase are as given below -
Initial use case e Use case model. e Design model © Delivered software |
model, e Requirements e Software increments
e Initial risk analysismodel components e Beta test report
assessment. e Architecture model e Test plan e User feedback
@ Project plan. e Preliminary design model Test cases report.
@ Risk list e User manual
e Iterative project plan e Installation manual
In 1980’s the heavy weight, plan based software development approach was used to
develop any software product.
In this approach too many things are done which were not directly related to software
product being produced.
This approach was rigid. That means if requirements get changed, then rework was
essential.
Hence new methods were proposed in 1990’s which are known as agile processes.
The agile processes are the light-weight methods are people-based rather than plan-based
methods.
The agile process forces the development team to focus on software itself rather than
design and documentation.
The agile process believes in iterative method. The aim of agile process is to deliver the
working model of software quickly to the customer.
For example : Extreme programming is the best known of agile process.
Conventional Software Development Methodology
As the software project makes the progress, the cost of the changes increases non linearly,
It is easy to accommodate changes during the requirement gathering stage. At this stage to
accommodate the changes - usage scenarios are modified, list of functions can be extended,
or written specification be edited.
As the progresses and if the customer suggest the changes during the testing phase of the
software development life cycle then to accommodate these changes the architectural
design needs to be modified and ultimately these changes will affect other phases of
software development cycle. These changes are actually costly to execute.
Agile Methodology
The agile method proponents claim that if the software development is carried out using the
agile approach then it will allow the software team to accommodate changes late in a
software project without dramatic cost and time impact.
In other words, if the incremental delivery is combined with agile practices such as
continuous unit testing and pair programming then the cost of changes can be controlled.
The following graph represents how the software development approach has a strong
influence on the development cost.
Cost of changes
due to conventional
software process
Development cost
Cost of changes
due to agile process
Time >
Demerits :
1) There is lack of emphasis on necessary designing and documentation during software
development process.
2) The project can easily get off the track if customer is not clear about his requirements.
2 Review Questions
e The adaptive software development approach was proposed by Jim Highsmith. This
approach is useful in building the complex software systems using iterative approach
e The focus of this method is on working in collaboration and team self organization.
e The life cycle of ASD consists of three phases of software development and those are -
Speculation
Release
or —t-=4 | Collaboration |
software
increment
Speculation : This is an initial phase of the adaptive software development process. In this
phase the adaptive cycle planning is conducted. In this cycle planning mainly three types
of information is used such as - Customer's mission statement, project constraints (delivery
date, user description, budgets and so on) and basic requirements of the project.
Collaboration : The motivated people work in collaboration to develop the desired
ag
software product. In this phase collaboration among the members of development team
is a key factor. For successful collaboration and coordination it is necessary to have
following qualities in every individual -
© Assist each other without resentment
O Work hard.
© Posses the required skill set.
© Communicate problems and help each other to accomplish the given task.
© Criticize without any hate.
Learning : As the team members go on developing the components, the emphasize is on
we
learning new skills and techniques. There are three ways by which the team members
learn-
© Focus groups : The feedback from the end-users is obtained about the software
component being developed. Thus direct feedback about the developed component can
be obtained.
© Formal technical review : This review for software components is conducted for
better quality.
© Postmortems : The team analyses its own performance and makes appropriate
improvements.
In this agile method, the project deadline is met using the incremental prototyping
approach. This is an iterative development process.
The Dynamic System Development Method (DSDM) consortium has defined an agile
process model called DSDM life cycle.
Various phases in this life cycle model are as follows -
1. Feasibili y study : By analyzing the business requirements and constraints the viability of
the application is determined in this phase.
Business study : The functional and informational requirements are identified and then the
business value of the application is determined. The basic application architecture is
decided in this phase.
3. Functional model iteration : The incremental approach is adopted for development. The
basic functionalities are demonstrated to the customer by building the suitable increments.
The intention of iterative cycle is to gather additional requirements by eliciting the
requirements from the customer as each prototype is being developed.
4. Design and build iteration : Each prototype is revisited during the functional model
iteration to ensure that the business requirements are satisfied by each software component.
Sometimes if possible, the design and build activities can be carried out in parallel.
5. Implementation : In this phase, the software increment is placed in the working
environment. If changes are suggested or if the end-user feels it incomplete then the
increment is placed in iteration for further improvement.
The DSDM can be combined with XP method or ASD concepts to create a combination
model.
1.20.3 Scrum
e SCRUM is an agile process model which is used for developing the complex software
systems.
e [tis a lightweight process framework that can be used to manage and control the software
development using iterative and incremental approach. Here the term lightweight means
the overhead of the process is kept as small as possible in order to maximize productive
time.
e This model is developed by Jeff Sutherland and Ken Schwaber in 1995.
Principles
e Various principles using which the SCRUM works are as given below -
1. There are small working teams on the software development projects, Due to this
there is maximum communication and minimum overhead.
2. The tasks of people must be partitioned into small and clean packets or partitions.
3. The process must accommodate the technical or business changes if they occur.
4. The process should produce software increments. These increments must be
inspected, tested, documented and built on.
5. During the product building the constant testing and documentation must be
conducted.
6. The SCRUM process must produce the working model of the product whenever
demanded or required.
* Various development activities (requirements analysis, design, evolution and delivery) are
guided by SCRUM principles.
Development Activities
30 Days
obstacles and plan for next activities. Following are three questions that are mainly
discussed during the meetings
i) What are the tasks done since last meeting ?
Demo : During this phase, the software increment is delivered to the customer. The
implemented functionality which is demonstrated to the customer. Note that demo focuses
on only implemented functionalities and not all the planned functionalities (and yet to get
implemented) of the software product.
Roles:
1. Scrum Master - The Scrum master leads the meeting and analyses the response of each
team member. The potential problems are discussed and solved in the meeting with the
help of master.
2. Team Members - These are the persons working in a team to develop the software
solutions.
e Originally Peter Coad suggested this approach for object oriented software engineering.
e Stephen Palmer and John Flesing has extended and enhanced Coad's work.
e In FDD, the feature means client valued function. It is an iterative and incremental
software development process
In FDD, the collaborative activities are carried out. These activities are called as process as
shown in Fig. 1.20.3.
decomposed into various subject areas. These subject areas contain the business
activities. The steps within business activity forms the categorized feature list. Features are
basically the client valued functions and can be expressed in the form.
<action> <result> <by|for|of|to> <object>
For example
.
<Action>
4
<result>
+
<of>
4
<object>
Plan by feature : After completing the building of feature list the development plan is
created. The features are assigned as classes and are chief programmer or the class owner
is assigned with appropriate classes.
4. Design by feature : A design package was produced for each feature. A chief
programmer selects a small group of features and these features are to be developed within
two weeks. For each feature the sequence diagram is created.
Build by feature : Finally a complete client valued function is developed for each feature.
nm
The class owners develop the actual code for their classes and this code is promoted to the
main build.
e Following are some benefits of the features -
1. Features represent small block of deliverable functionalities hence user can better
describe, understand and review them.
The features can be arranged into hierarchical business related grouping.
The team can develop every feature within the two weeks.
The features are typically smaller in size and therefore can be analyzed effectively.
ot
1.20.5 Crystal
The agile modeling can be used for large and complex projects. By adopting agile
modeling techniques the scope and complexity of the project can be understood. The
problems can be partitioned effectively among the group of people. And the quality of the
working model can be assessed at every step of development.
Scott Ambler described the Agile modeling as - “Agile modeling is a collection of values,
principles and practices for modeling the software. Agile Modeling (AM) is a practice-
based methodology for effective modeling and documentation of software-based systems.
This modeling technique is more effective and light weight than the traditional modeling
technique.”
Various features suggested by Scott Ambler for agile modeling are as follows -
1. Specify the purpose for the model : Prior to development of the software model the
goals and objective of the model must be known to the developer.
2. Make use of multiple models : Various models can be used to gain the insight in the
software product, Each model can have different perspective. A small amount of set of
models can be useful for building the desired software product.
Follow a definite path : Use only those models that give long term value so that the
we
work can proceed in definite direction. Every work product must be maintained as
changes occur.
4. Give importance to contents and not the presentation : The correct information in
the model is more important than the flawed representation.
5. Understand the models and supporting tools : It is necessary to understand the
strengths and weaknesses of the model that are used and the tools that are used in
development process.
6. Adapt locally : The needs of modeling team must be satisfied by adopting appropriate
modeling approach.
e Normally there are two approaches of software development-plan driven development and
agile development.
e Agile Development :
© In agile approach, the design and implementation are the central activities and other
activities such as requirement elicitation and analysis, testing and so on are integrated
with design and implementation.
©. The agile approach is not completely code focused, some necessary documents such as
design specification can be produced in this approach.
process.
The incremental delivery is possible in plan driven development.
ae -!
analysis
Requirements
analysis
Design and
implementation
Agile development
Change in
Implementation
requirements
Software development is possible by using the elements of both the plan driven and agile
approach. However following are the issues that are considered while deciding whether to use
agile development approach or to use plan driven development
If the project requires, the detailed specification and implementation before going into next
state then plan driven approach should be used.
If the rapid software development is required and incremental approach of development is
adopted then go for agile approach of development.
For developing large system, then using small interacting team, the agile approach can be
used.
For the complex systems like real time systems the lot of analysis is required before
implementation, then the plan-driven approach is required.
For long-life systems in which the original documentation is used by the team members to
support the software development. In this situation the plan driven approach is the most
suitable one.
If the new tools and techniques are available for software development then agile approach
is used.
If the development team is distributed and part of software development need to be
outsourced then the plan-driven approach is adopted, because in plan driven development
the detailed documents are created to communicate the development to other team
members.
If traditional culture is preferred in organization then plan driven approach is used.
It is considered than the highly skilled developers are required for agile approach. If such
team members are available then the agile approach is used.
10. If the system needs the approval from external regulators then it requires to produce
detailed system documentation and in such case, the plan driven approach is used.
Embedded
[b] design
Q.3 Robotics, expert system and pattern recognition are the applications of
Q.5 Quality focus layer, process layer, methods layer and layer is a known as software
u
Q.7 __ isacollection of software engineering work task, milestones and deliverable that must
be accomplished to complete particular project.
Program [b] Document
Design Task
Q.8 The __ model is a realistic approach to the development of large-scale systems and
software.
spiral RAD
prototype incremental
Q.11 Which two models doesn't allow defining requirements early in the life cycle ?
Q.12 If XYZ company wants to enhance the current software product, then which process
model will you prefer to perform this job ?
[a] Spiral [b] Iterative enhancement model
both b and c
Q.13 If the project is to be completed within the tight schedule then we choose waterfall model
Q.15 Choose the type of project where the prototyping model of software development is well
suited.
none of these
Q.19 The model in which the requirements are implemented by its category is
Q.22 What is the main difference between the spiral model and other models ?
[a]Each loop is considered as a phase
Waterfall Crystal
Qi b Q.2 c Q3 c Q.4 c
Q.25 Q.26 d
Q00
Notes
Software Requirement
Engineering and
Analysis Modeling
Syllabus
Contents
2.1 Requirements Engineering es sesseeeeeeeseeeeees MAY RTD: 0... .c0iseserzoceisedeaseanisezens Marks 5
2.2 Requirements Engineering Tasks .............0:--+. Dec.-14, 17, 19, April-16 ....... Marks 5
2.3 Establishing the Groundwork —o....s..eesseeeeeeee Dec.-07, May-14 ...........:00004- Marks 4
2.4 Eliciting the RequirementS — se seeeeseeeseeeeees DOG 514; 185, cise ccxicn sizes cugsesicvnss Marks 5
2.5 Developing Use CaseS eaeeeseeesteteteeeee May-11, Dec.-14 0.0.0.2... Marks 5
2.6 Building Requirements Models
2.7 Elements of the Requirements Model............... D@C.-14......ccccecesecesteeee
cette tees Marks 5
2.8 Scenario Based Modeling ceteceeeeteeeeceseeeee May-13, D@C.-13.....020.20002202--. Marks 8
2.9 Class Based Modeling ee eeeeeeeeteeesteeeee Mayet 9.202263,
ete Soh beset Marks 4
2.10 Data Modeling seeeeecessesseeeeeeess DOC.-11, 14, May-12, Oct.-19. Marks 5
(2-1)
Software Engineering 2-2 Software Requirement Engineering and Analysis Modeling
Requirements Engineering
What is a requirement ?
A requirement can range from a high-level abstract statement ofa service or of a system
constraint to a detailed mathematical functional specification.
The requirement must be open to interpretation and it must be defined in detail.
Types of requirements
( Types of requirements]
e User requirements
It is a collection of statements in natural language plus description of the services the
system provides and its operational constraints. It is written for customers.
e System requirements
It is a structured document that gives the detailed description of the system services. It is
written as a contract between client and contractor.
e Software specification
It is a detailed software description that can serve as a basis for design or implementation.
Typically it is written for software developers.
Following are those reasons which specify that there is a need for the requirements to be
stable and correct -
As requirements are identified and analysis model is created the software team and other
stakeholders negotiate the priority, availability and relative cost of the requirement. During this
negotiation there are chances that the requirements may get changed. During requirement
analysis, each requirement is validated against the needs of the customer. If the requirements
are stable, correct and unambiguous then they remain unchanged throughout the requirement
analysis process. And finally the working model that satisfied customers need can be created
effectively.
> Elicitation
>. Elaboration
Requirement P.,.
engineering ————»——————— Negotiation
tasks
/+———_—_—_———» Specification
>. Validation
2.2.1 Inception
The inception means specifying the beginning of the software project. Most of the
software projects get started due to business requirements. There may be potential demand
from the market for a particular product and then the specific software project needs to be
developed.
There exist several stakeholders who define the business ideas. Stakeholders mean an
entity that takes active participation in project development. In software project development,
the stakeholders that are responsible for defining the ideas are business managers, marketing
people, product managers and so on. Their role is to do rough feasibility study and to identify
the scope of the project.
During the inception a set of context free questions is discussed. The purpose of
inception is to -
1. Establish the basic understanding of the project.
2. Find out all possible solutions and to identify the nature of the solution.
3. Establish an effective communication between developer and the customer.
2.2.2 Elicitation
Before the requirements can be analyzed and modelled they must undergo through the
process of elicitation process. Requirements elicitation means requirements discovery.
Requirements elicitation is very difficult task.
Following are the reasons for : why it is difficult to understand customer wants? -
1. Customer sometimes is unable to specify the scope of the project. Sometimes customers
specify too many technical details and this may increase the confusion.
2, There is difficulty in understanding the problem. Sometimes customer could not decide
what are their needs and wants. Sometimes they have got poor understanding of
capabilities and limitations the existing computing environment.
Sometimes customers find it difficult to communicate with the system engineer about
their needs. Sometimes customers may have got some conflicting requirements. This
ultimately results in specifying ambiguous requirements.
3. As project progresses the needs or requirements of the customers changes. This creates a
problem of volatility.
To overcome these problems the requirements gathering must be done very systematically.
2.2.3. Elaboration
e Elaboration is an activity in which the information about the requirements is expanded and
refined. This information is gained during inception and elicitation.
e The goal of elaboration activity is to prepare a technical model of software functions,
features and constraints.
e The elaboration consists of several modelling and refinement tasks. In this process
several user scenarios are created and refined. Basically these scenarios describe how end-
user will interact with the system.
e During elaboration, each user scenario is parsed and various classes are identified. These
classes are nothing but the business entities that are visible to end user. Then the attributes
and services (functions) of these classes are defined. Then the relationship among these
classes is identified. Thus various UML (Unified Modelling Diagrams) are developed
during this task.
e Finally the analysis model gets developed during the elaboration phase.
2.2.4 Negotiation
Sometimes customer may demand for more than that is achieved or there are certain
situations in which customer demands for something which cannot be achieved in limited
business resources. To handle such situations requirement engineers must convince the
customers or end users by solving various conflicts. For that purpose. requirement engineers
must ask the customers and stakeholders to rank their requirements and then priority of these
requirements is decided. Using iterative approach some requirements are eliminated,
combined or modified. This process continues until the users’ satisfaction is achieved.
2.2.5 Specification
2.2.6 Validation
Requirements are always incomplete and inconsistent. New requirements occur during the
process as business needs change and a better understanding of the system is developed.
System customers may specify the requirements from business perspective that can conflict
with end user requirements.
During the development of the system, its business and the technical environment may get
changed.
Requirement management process
Following things should be planned during requirement process.
3. Review Questions
Definition of stakeholder : Stakeholder means anyone who gets benefited from the
system in a direct or indirect way when a system is getting developed.
For example : Consultant, product engineers, software developer, customer, marketing
people, end user, support and maintenance engineer and others.
Every stakeholder has different view for the system and everyone gets benefited differently
when the system gets developed successfully.
During the requirement inception phase, the requirement engineers must create a list of
stakeholders who will participate in project development process and their contribution
towards requirement elicitation. This list may get increased as the project progresses.
In the project development process there are variety of stakeholders that get involved in.
Hence a project has multiple viewpoint. Normally the viewpoint is influenced by the kind of
stakeholder who is participating in the project.
Stakeholder Viewpoint
End user The end users expect that the developed system should be easy to learn and the
features included in the project should be familiar to them.
Marketing These stakeholders expect that the project should posses some exciting feature so
people that market can be attracted towards the product and then selling of the product
should become easy.
Business The system getting developed should be with in the specified budget and it should
managers satisfy the demands of the market.
Software These stakeholders expect that the requirements which they get should be realistic
developers and unambiguous so that systematic infrastructure of the project can be built.
Support The support engineers expect that the project should get developed in such a
engineers manner that it can be easily maintained.
All these stakeholders contribute a lot in requirement engineering process, The information
gathered using different view points can be conflicting or may be inconsistent. Hence the
requirement engineers categorize all stakeholders’ information in a systematic manner so that
decision makers can choose proper set of requirements.
| Example 2.3.1 | Describe two real life situations in which the customer and the end-user is the
same. Describe two situations in which they are different.
SPPU : Dec.-07, May-14, Marks 4, I
Solution : Two situations in which the customer and the end user is the same person
1. For an anti-virus product the customer and the end-user might be the same person.
According to his needs (such as single user, with internet security. anti-spam and so on) the
customer develop the antivirus software product and the same person makes use of it.
2. The Management Information System(MIS) product can be developed by the customer
according to his needs and requirements and can be used by the same person.
Two situations in which the customer and the end user is different
1. An on-line shopping application can be purchased by some customer and it can be used by
different group of people.
An on-line Banking system is purchased by the bank and is used by its account holders. In
nN
this case the customer and the end-user is not the same person.
For building a successful system, the collaboration among the stakeholders and software
engineers is must.
The job of requirement engineers is to identify the areas of commonality, inconsistencies
and conflicts. The commonality denotes the requirements on which all the stakeholders agree.
These identified requirements are then categorized. During collaboration process different
stakeholders can present their own viewpoint, but business manager or senior technical
person makes the final decision about the requirements which should be eliminated.
During the project inception phase variety of context free questions are asked. For
example
These questions will help to identify the stakeholders that are interested in getting the
system developed.
1. What are the characteristics of good output that would be generated by successful
solution ?
2. What kind of problems will be projected by the solution ?
3. Can anybody describe the business domain in which the solution will be used ?
4. Is there any special performance issue or constraint that affects the success of the
system getting developed ?
These questions will help to gain clear understanding of the system and associated
problems.
This questions are useful to initiate the communication and are essential for successful
elicitation.
Questioning is useful only at inception of the project but for detailed requirement
elicitation it is not sufficient. During requirement elicitation certain activities such as problem
solving, elaboration, negotiation and specification must be carried out. Various ways by which
the requirement elicitation can be done are -
Collaborative requirement gathering
2. Quality function deployment
Use scenarios
Ww
An agenda should be prepared in such a way that it covers all the important point as well as
it allows all the new innovative ideas.
A facilitator controls the meeting. He could be customer, developer or outsider.
A definition mechanism is used. The mechanism can be work sheets, flip charts, wall
stickers, electronic bulletin board, chart room, virtual forum.
6. The goal is to identify the problem, decide the elements of solution, negotiate different
approaches and specify the preliminary set of solution requirements.
In FAST meeting each FAST attendee is asked to prepare - a list of objects, list of
services and a list of constraints.
The list of objects consists of all the objects used in the system, the objects that are
produced by the system and the objects that surround the system.
The list of services contain all the required functionalities that manipulate or interact
with the objects.
The list of constraints consists of all the constraints of the system such as cost, rules,
memory requirement, speed accuracy etc.
As the FAST meeting begins, the very first issue of discussion is the need and
justification for the new product. Once everyone agrees upon the fact that the product
is justified, each participant has to present his lists.
These lists are then discussed, manipulated and these modified or refined lists are
combined by a group.
The combined list eliminates redundant entries adds new ideas that come up during the
discussion. The combined list is refined in such a way that it helps in building the
system.
The combined list should be prepared in such a way that a “consensus lists” can be
prepared, for object, services and constraints.
A team is divided into subteams. Each subteam develops a minispecification from each
consensus list.
Finally a complete draft specification is developed.
For example -
A FAST team is working on a commerical product. A following product description is
given as below -
“Nowadays the market for video game is growing rapidly. We would like to enter this
market with more features, like attractive GUI, multiple sound setting, realistic (3D)
animations. This product is tentatively called “Gamefiun’. At the end of game, scores of each
player should be displayed”.
The FAST attendee prepare following lists -
1) List of objects - Display, menu, a sound, an event (moving from one level to another) and
so on.
2) List of services - Setting sounds, setting colors in GUI, HELP, instructions for players,
score card etc.
3) List of constraints - Must be user friendly, must have high speed, must accommodate less
size, should have less cost.
The for Menu (object) can be as given below -
e Contains ‘Start game’ and ‘exit’ options.
e List of all functional keys with corresponding functionality.
e Software provides interaction guidance, quick tour, sound controls.
e All players will play or interact through keys.
e Software provides facility for change in the look of GUI.
e Software displays scores of each player.
Expected requirements -
These types of requirements are such requirements which system must be having even if
customer did not mention about them. These are such requirements that if they are not present
then the system will be meaningless.
For example : A software package for presentation (like Microsoft Power Point) must
have option of 'new slide insert', so that user will be able to insert a new slide at any position
during his presentation.
Exciting requirements -
When certain requirements are satisfied by the software beyond customer's expectations
then such requirements are called exciting requirements.
For example : Spell check facility in Microsoft Word is an exciting requirement. Various
types of deployments that can be conducted during software development process are -
Function deployment : For determining the value of each function this deployment can be
done.
Information deployment : After identifying various functionalities events and data
objects must be identified.
Task deployment : The task associated with each function must be identified.
Value analysis : Identify the priorities of requirements. The technique of QFD requires
proper interaction with customer.
e During requirement gathering overall vision for systems functions and features get
developed.
e In order to understand how these functions and features are used by different classes of end
users, developers and users create a set of scenarios. This set identifies the usefulness of the
system to be constructed. This set is normally called as use-cases.
© The use-cases provide a description of how the system will be used.
Following are some work products that get produced during requirement elicitation -
e A statement of feasibility study performed in order to find the need of the project.
e Statement for the scope of the system.
e A list of various stakeholders such as customer, end-users, technical persons, and many
others who participate during requirement elicitation.
e A technical description of system environment
e A list of requirements and constraints.
e Aset of usage scenarios along with operating conditions.
e The prototype that may get developed for defining the requirements in better manner.
These work products are then reviewed by all the people who participate in requirement
elicitation.
wa Review Question
What are the mains fictions that must be performed by the actor ?
0'°O
Goal in Context To monitor all the functionalities required to establish the session
Preconditions ATM system has to be programmed and as to recognise and validate the PIN.
2. PIN is incorrect.
4. Insufficient balance
Open Issues 1. Is there a need to display any additional information by the control panel?
2. For how many time the PIN is allowed to enter on incorrect supplement.
3. How much time is allotted to the customer to pick the items like cash or
The high-level use case for the ATM system can be as shown below —
Shuts down
system
Operator
Establishes
session
Customer Transaction
Cwinrava) Deposit
Peed Write an use case for ‘login’ with a template and diagram.
SPPU : May-11, Marks 4
Solution :
Goal in Context To monitor all the functionalities required to register for the course.
Preconditions None
Scenario / Basic Flow 1. The system requests student to enter his name and password.
3. The system validates the entered name and password and logs the
student into the system.
/ \
> .
es \<s<include>>
7 <<include>> ‘,
7. Review Question
1. What do you need to know in order to develop an effective use case ? Describe a
standard use case documentation template. SPPU : Dec.-14, Marks 5
Designer - After requirement analysis, the designer can design for data, architectural
interface and component level designs.
Developer - Using requirements specification 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 ofa system must be understood.
Modelling
we
After evaluation and synthesis, using data, functional and behavioral domains the data
model, functional model and behavioral model can be built.
Specification
»
Review
nm
Arlow and Neustadt suggested some rules that should be followed during the creation of
analysis model. These rules are called analysis rules of thumb. They are as follows -
e The analysis model should focus only on requirements that are visible within the business
domain. That means there is no need to focus on detailed requirements.
e Each element of analysis model should help in building overall understanding of software.
These elements should provide insight into information domain, function and behaviour of
the system.
e Minimize coupling within the system. Coupling is basically used to represent the
relationship between the two objects by means of functionalities.
e Delay use of infrastructure and other non functional models until detailed software design is
obtained.
e Some analysis models should provide the values to the stakeholders. For example, the
business stakeholder should focus on the functionalities that are basic demands of the
market; software designer must focus on basic design of the product.
e The analysis model should be very simple so that it could be understood easily.
It is observed that there are varieties of patterns that occur in many applications with in
the same business domain. If these patterns are categorized systematically then that allows
software engineer to reuse them. Analysis model helps in identifying such patterns.
The analysis is made on data and processes in | The analysis is made on the classes and
which data is transformed as separate entities. interaction among them in order to meet the
customer requ irements.
Data objects are modelled in such a way that | Unified Modelling Language(UML) and
data attributes and their relationship is defined | unified processes are used in object oriented
in structured approach modelling approach.
% Review Question
When user of the computer-based system gets satisfied completely then that system or a
product is said to be successful product. The software engineers try to understand how an user
will interact with the system by properly characterising the requirements and by building the
analysis models. In analysis modelling, at the beginning, creation of scenarios in the form of
use cases, activity diagrams and swimlane diagram occurs.
Use case diagrams represent the overall scenario of the system. A scenario is nothing but a
sequence of steps describing an interaction between a user and a system.
For example : In library, student searches the book in catalog, finds book, reserves the
book. He returns a book or pays fine for a book-all these activities constitute a scenario.
Thus use case issaa set of scenarios tied together by some goal. The use case diagrams are
drawn for exposing the functionalities of the system.
Actor
An actor is an entity which interacts with the system. Actors carry out use cases.
For example : In above use case diagram student is an actor.
A single actor may perform many use cases; conversely, a use case may have several
actors. It is not necessary that the user should be an actor. The external system that gets some
value or produces some value can be an actor. For example, Account system can be actor.
Actor is nothing but a role played by a person, system, device or even an enterprise, that
has a stake in the successful operation of the system.
Use cases
The use cases represent the
behavior of the system. Typically
various functions are represented peor
eoe gua
as use cases. For example, in the
above use case diagram Reserve a Sparen a ie
book, Borrow book, Return book, Payment of fine are the use cases. Use cases can be
represented as follows.
Relationships
Association ; It identifies an interaction between actors and use cases. Each association
represents a dialog.
Include relationship : Identifies a reusable use case that is unconditionally required for
the execution of another use case. The decision about when and why to use the included use
case is taken by the calling use case.
Extend relationship : Identifies a reusable use case that conditionally interrupts the
execution of another use case by using its functionality. The decision of when the extending
use case should be used is taken by the extending use case itself.
Generalization : Identifies an inheritance relationship between actors or between use
cases.
Fig. 2.8.1 shows the association, include relationship, generalization and Extended use case
for Clinical system.
Make an
appointment
1
' << include >>
Patient ' Scheduler
MAL
, << include >>
Cancel appointment
Payment delay
<< extend >>_ -
Payment of bill
Bill insurance
elu ows Design use case diagram for user interaction with ATM system.
Solution : For an ATM system following are the scenarios with the user.
User enters the card, types user name and PIN.
2. User makes enquiry for balance. He may demand for getting the mini statement.
3. User withdraws the desired amount of money.
4. User may deposit some money.
5. Finally user closes the session.
ATM system
O27,
Ze ene “"
a
Enters card,
user name and PIN
Tees |
Deposite
money
Fig. 2.8.2
ee erway Draw a use case diagram for library management system.
Solution :
1. For library system user can be a staff or a student who initially registers himselfas a new
user.
a) For registering as a new user registration form is filled up.
b) Then librarian issues a library card on which some ID is assigned to the card holder.
2. The user requests for a new book.
6. User can also submit his feedback by returning the feedback form.
7. There is another important actor in this system and that is "Librarian". The librarian adds
the record in the library database.
8. Librarian deletes a record, if the book is not existing in the library or if student leaves the
college.
9. Librarian updates the database.
Filling up
feedback form,
Student Staff
Sel wee Give the actors, use cases and use case diagram for "online mobile order and
purchase system". Write the scope of the system. SPPU : Dec.-13, Marks 8
Solution : The basic idea is that customers can buy products using online. It consists of
product details, security system, status and exits. The administrator can enter the name and
password and generate the report and can perform operations like add, search, delete the
products in the database. The online mobile shopping system enables vendors to set up online
shops, customers to browse through the shops and a system administrator to approve and reject
requests for new shops and maintain lists of shop categories. Also on the agenda is designing
an online shopping site to manage the items in the shop and also help customers purchase them
online without having to visit the shop physically. Web customer actor uses some web site to
make purchases online. Top level use cases are View Items, Make Purchase and Client
Register.
Administrator : Person responsible for the system. The administrator is the person in
charge of managing and administering the system, He also assumes the role of supervisor in
the sense that he enforces the "Terms of use" of the site, and has the right to revoke client's
privileges by deleting their account.
Bank : The supplier's bank. The bank gets involved to debit the client's account and credit
the supplier's account during a purchase.
View
mobile
‘Authentification
Make
purchase
Registered ti
1
Identify
provider
Web
customer ean.
Credit payment
New service
ree |
Client
register
Paybill
(Bank)
System : Dummy actor representing the system. This actor is a dummy actor used to
represent the system in interactions diagrams for the use cases.
Client : Person purchasing products online. The client, also known as customer, is the
person that logs onto the shopping cart online system to purchase products of his/her choice.
The activity diagram is a graphical representation for representing the flow of interaction
within specific scenarios. It is similar to a flowchart in which various activities that can be
performed in the system are represented. This diagram must be read from top to bottom. It
consists of forks and branches. The fork is used to represent that many activities can be
parallely carried out. This diagram also cons of merge, where multiple branches get
combined. Before transitioning into final activity state there comes a join. A typical structure
of activity diagram is -
Below is the railway reservation system. The activity diagram for reserving a ticket is
shown below. (Also refer Fig. 2.8.6 on next page)
Start
activity
Fork
a
activity
eee in
activity
End
Enquiry
about
reservation
Fill Pays
reservation for
form ticket
Make
Receive
confirmed payment
reservation
Close
form
©
Fig. 2.8.6 Activity diagram for reservation
The activity diagram shows various activities performed, but it does not tell you who is
responsible for these activities. In swimlane diagram the activity diagram is partitioned
according to the class who is responsible for carrying out these activities.
Enquiry
about
reservation
Fills
reservation
form
Pays for
ticket
Reserve
a seat
Receive
payment
&
©
Fig. 2.8.7 Swimlane diagram for reservation
enerate video
Select camera output
ser interface
View camera prompts for
output
Pn another view
Fig. 2.8.8
Class diagrams in UML are used to capture the static view of the system. Basically class
diagram represents how to put various objects together. The class diagram gives an overview
of a system, in which various classes and relationship among these classes is represented. In
UML class is a kind of classifier. For example, in class diagram manager, executive,
salesperson can be represented by a class Employee. Thus each specific type of class is an
instance ofa class.
one or more sub classes. The sub classes may add its own attributes and methods. The
example
example of
of generalization
generalization hierarchy
hierarchy isis asas shownshown belo
below.
Shape
Color
Weight
void draw()
void setcolor ()
char getcolor{)
void hide()
void show()
t
Triangle Rectangle
height lefttoppoint
breadth rightbottompoint
In this example the super class is a shape class from which two classes can be derived
namely triangle and rectangle. The triangle and rectangle classes make use of some properties
of base class shape and at the same time these classes have their own attributes and operations.
Note that the inheritance relationship is shown by,
The arrowhead points to base class or super class and the other end of arrow is connected
to derived classes. These classes inherit the properties of super class. Such classes are
sometimes called as child classes.
The generalization indicates type of relationship. If the child classes are derived from more
than one parent then it shows multiple inheritance. Fig. 2.9.3 shows the multiple inheritance.
Shape
Color Printer
Weight
void draw()
void setcolor () e .
char getcolor() void print_diagram ()
void hide()
void show() ~
Triangle Rectangle
height lefttoppoint
breadth rightbottompoint
Advantages of inheritance
3. Inheritance specifies different types of classes that can be derived from one or more
classes. Thus it brings abstraction mechanism in the design of the system.
Drawbacks of inheritance
1. Derived classes are not self contained. In order to understand the derived classes the super
class must be known.
2. The inheritance graph created during analysis phase is not sufficient and cannot be directly
used for implementation purpose. If it is directly used as it is then it leads to inefficient
code generation.
3. The design of inheritance graph may vary during analysis, design and at implementation
levels. Hence at each of these phases these graphs need to be maintained. And appropriate
design must be selected for final implementation.
Solution : Aggregation : In the class diagram we can has '‘part-of relationship which
represents the aggregation. The aggregation can be represented by an edge with diamond end
pointing to the super class. In above class diagram, ‘Library management system! is a super
class which consists of various classes such as User, Book and Librarian. Similarly, 'User' is a
super class which has 'Account' class. They share aggregate relationship.
Multiplicity : One or more instances of particular class can be associated with one or more
instances of another class. For denoting one instance we write | and to denote many instances
is used. For example, in above given class diagram, many users can be associated with many
books. On the other hand, every single user will have only one account. (See Fig. 2.9.5 on next
page).
() euy eyejnayeo
junowe eu,
sy00q 4Soj OU
syooq peunjes ou
®
hate eset
owen ann
aseqeyep Aueiqr ueuesgry yoog etn
| * J«
2-34
o L $'
TECHNICAL
() ynoBo7
() saysiBoy
() ui607
piomssed
aWweWesf)
adApesp
Software Engineering
Wwayshs
juewebeuew Ayeiqi]
Software Engineering 2-35 Software Requirement Engineering and Analysis Modeling
1. Using natural language description the objects can be identified. The simple rule is that the
nouns in the problem description correspond to objects and the verbs correspond to
operations or behaviour. This is known as HOOD method.
2. The roles such as student, customer; the tangible entities such as course, book; the events
such as schedule; the locations such as library, office support the objects. This is Coad and
Yourdon approach.
3. By understanding the behaviour of the system objects can be obtained. The entities which
initiate and participates the behaviour of the system are the objects.
4. Using system scenario the objects can be identified.
For example : "Consider an ATM System in which the customer with an ATM card can
establish session with the system. First of all he inserts the card into the system and enters the
PIN. The console of the system reads the card and authenticates the customer. The system has
console containing display and keyboard.
The session with the system can be accomplished by the transaction. Using the withdrawl
transaction the customer can get the requested amount through cash dispenser,
In above problem statement underlined words denote objects of the system. Hence -
ATM System
int id
Char Bankname[20]
Char BankAdd[20]
int State
int Switch_ON
run ()
Switchon ( )
Switchoff ()
getID ()
getplace ()
Startup_system( )
Shutdown_system ()
Char mesage
[oeee
readCard ( ) display ()
ejectCard ( ) readPIN ()
keepCard( ) readMenu ( )
readAmt( )
1 es
ACC_ID
Address
Check_initial_amt () enter_PIN( )
| dispense_amp
() select_choice ( )
information. This information can be used by the system for defining the functionalities.
Hence chosen object must contain some useful information.
2. Services : The set of identified objects specify the required services. These services are
provided by the various functionalities of the system, Hence the objects must be chosen in
such a way that they provide some services to the system,
Common attributes ; Every object defines some set of attributes. These attributes can be
we
member variables or member functions, Some member variables are common to all the
objects. The selection of object can be done based on such common characteristics of the
system.
4. Common operations : Every object defines some set of attributes. These attributes can be
member variables or member functions. Some member functions are common to all the
objects. The selection of object can be done based on such commen characteristics of the
system,
Multiple attributes : The object that contains multiple attributes can retain more
an
information about the system. Such object can provide some useful service to the system.
While selecting particular entity as an object it is necessary to ensure that the chosen object
has multiple attributes. This will lead to focus on major information.
6. Essential requirements : The external entities are responsible for producing or consuming
some kind of information. These entities can act as an object. Selection of such entities as
an object helps to perform various operations that are required for getting the solution of
the problem defined by the system.
Fishersmith has suggested following types of classes.
Device classes : The external devices can be declared as the classes such as keyboard,
_
System intelligence means the ability of the system. In simple words, “what system can
do” and “what system knows” means system intelligence. Regarding distribution of
responsibility, one approach was adopted earlier, that is : there will be two types of classes
smart class and dumb class. The class who carries out more responsibilities is supposed to be
the smart class and the class who carries out few responsibilities or who acts as the “servant” of
smart class is called the dumb class. But this approach has some drawbacks. Firstly, the major
responsibilities get concentrated among few classes. secondly making changes in such system
®
TECHNICAL PUBLICATIONS™- An up thrust for knowledge
Software Engineering 2-39 Software Requirement Engineering and Analysis Modeling
becomes more complicated and lastly by adopting such approach system may require more
number of classes.
Hence system intelligence must be evenly distributed among several classes. That means
cohesiveness of the system must be improved.
We can check whether the system intelligence is evenly distributed or not by using CRC
model index card. In this case, a list of responsibilities is made. If a particular class has more
number of responsibilities than expected then that means intelligence is centred on that
corresponding class.
The responsibilities mean attributes and operations should be stated in most general way.
Similarly polymorphism should be adopted wherever possible.
3. Information and the behaviour related to particular class should remain in that class
only.
The data and related operations should be packaged in a single entity called class. This
indicates the encapsulation property.
4. Information about particular class should be for that class only and it should not be
distributed among several classes.
If the related information is not localized and if it is distributed among several classes then
such systems become more difficult to manage.
All the related objects must exhibit the same behaviour at the same time in order to
maintain the consistency in the system operation.
* Collaborations
The class can fulfill its responsibilities by
= Using its own set of operations and attributes.
= By collaborating with other classes.
Collaborations can be defined as is nothing but the identification of relationships between
classes. When a set of classes collaborate with some other classes for fulfilling some
requirements then they actually form a subsystem.
When a complete CRC model has been developed the customer and a software engineer
must review this model. While reviewing such model following approach must be adopted -
1. All members of review must be given CRC index cards. Cards that indicate the
collaborations must be separated out.
Appropriate classification of all the scenarios of the use cases must be done.
N
3 . A token is maintained. There is review leader who reads out the use-cases. When a
particular phrase occurs then the review leader passes the token to the person who is
holding the CRC index card of that particular phrase (in fact it is a class name). It is then
examined whether all possible responsibilities of that class are mentioned in the CRC card
or not.
The review then determines whether or not the responsibilities of corresponding class are
properly noted on the CRC card.
If the responsibilities and collaborations noted on the index card can not fulfil the scenarios
of use cases then some modifications can be made in the CRC card.
el ewes Write a CRC for the class ‘Email system user’. SPPU : May-13, Marks 4
Solution :
Class: Email System User |
Attributes:user_id, password
Responsibilities Collaborator |
| Enters the user id and password for logging in. Authentication sub-system
| Reads the mail Mailing sub-system |
| Sends the mail |
| View/delete address-book entries. Address book sub-system
Chatting Messenger subsystem |
Using CRC modelling we can identify the classes and objects. Then following steps are
adopted
Step 1: The relationship among the several classes must be established.
Step 2 : Identify the responsibilities of each class.
Step 3 : Define the collaborator classes so that the responsibilities can be achieved.
When two classes are connected then the relationship exists between the two. The most
common type of relationship is a binary relationship. For example a client server relationship
is a kind of binary relationship.
According to Rambaugh relationship can be derived by examining the problem statement.
According to him the verb or verb phrases represent the relationships. Hence it is
expected to do the grammatical parsing and isolate the verbs from the problem statement.
Typically communication, locations, ownerships and satisfaction conditions indicate the
relationships.
e Following are the 3 steps used to derive the object relationship model -
1. Using CRC index cards the Collaborator objects can be identified.
Following Fig. 2.9.7 represents the various CRC index cards that can be connected
together. Note that these objects are simply connected together no named relationship exists at
this stage.
Security LCD
eee. --- system }-----4 Display }------ Sensor
Sensor event
2. Evaluate the responsibilities and collaborators of CRC index cards and label each
connected lines.
Now each relationship of the object must be named appropriately. Thus relationship gets
established among the multiple objects.
Produces Contains polls
or Security ee LCD a
Beep Sensor
Boe eel system Display L
} recognises
Sensor event
For example :
Produces Contains polls
— Security - LCD —
— system} ----_J Display |------ Sensor
0:10 1:1 W100 1:1 1:1 1:m
1:1, \
| } recognises
O:n|
Sens or event
e Data modelling is the basic step in the analysis modelling. In data modelling the data
objects are examined independently of processing.
e The data domain is focused. And a model is created at the customer’s level of abstraction.
e The data model represents how data objects are related with one another.
Elements
of data model
Object : Vehicle
Attributes:
Make
Model
Color
Owner
Price
What is relationship ?
Relationship represents the connection between the data objects. For example
The relationship between a shopkeeper and a toy is as shown below
Here the toy and shopkeeper are two objects that share following relationships -
e Shopkeeper orders toys.
e Shopkeeper sells toys.
e Shopkeeper shows toys.
e Shopkeeper stocks toys.
© One to one (1:1) - One object can relate to only one other object.
e One to many (1:N) - One object can relate to many objects.
e Many to many (M:N) - Some number of occurrences of an object can relate to some other
number of occurrences of another object.
Modality indicates whether or not a particular data object must participate in the
relationship.
Example
Cardinality : Single customer Cardinality : Many purchase
waiting for purchase f actions is possible.
Modality : It is optional,
Modality : For purchase action Y there as not be
eel is must any purchasing
(modality 1) (modality 0)
e The object relationship pair can be graphically represented by a diagram called Entity
Relationship Diagram(ERD).
e The ERD is mainly used in database applications but now it is more commonly used in data
design.
e The ERD was originally proposed by Peter Chen for design of relational database systems.
e The primary purpose of ERD is to represent the relationship between data objects.
e Various components of ERD are -
Entity
e Drawn as a rectangle.
e Anentity is an object that exists and is distinguishable.
e Similar to a record in a programming language with attributes.
Relationship
e Drawn as a diamond.
e Anassociation among several entities.
e Relationships may have attributes.
e Relationships have cardinality (e.g., one-to-many).
Attribute
e Drawn as ellipses.
e Similar to record fields in a programming language.
C Attribute
Relationship
Catibute>
€ Attribute >
Entity
Weak entity
When this entity is dependant upon some another entity then it is called
weak entity.
Attribute
Derived attribute
+ i o . 3 + ‘ oer am,
It is a kind of attribute which is based on another attribute. ¢ Attribute
_——
Key attribute
A key attribute is an unique attribute representing distinguishing
characteristic of entity. Typically primary key of record is a key attribute.
Multivalued attribute
A multivalued attribute have more than one value.
Relationship
When two entities share some information then it is denoted by Relationship
relationship.
Notations to show cardinality
One to one
> Many
The entity relationship diagram is used to represent the data objects their attributes and the
relationship among these data objects. The ERD is constructed in iterative manner. Following
guideline is used while drawing the ERD.
1. During the requirement elicitation process, the requirements should be collected in such a
way that we can evolve input, output data objects and external entities for system
modeling.
The analysis and customer should be in a position to define the relationship between the
to
data objects.
3. Whenever a connection between data objects is identified the object relationship pair must
be established. Thus iteratively relationship between all the objects must be established.
4. For each object relationship pair the cardinality and modality is set.
5. The attributes of each entity must be defined.
6. The entity relationship diagram is formalized and reviewed.
7. All the above steps are repeated until data modeling is complete.
Sc cwa Draw an ER diagram for the relationship of teacher and courses. Also
specify the association, cardinality and modality.
Solution :
Specialization~
info
Teacher
~———Cardinality
“\—_________ Modality : Must
Conducts
ue Modality : Optional
Course
Course_
(Schedule ’ Gp syllabus.
Fig. 2.10.6
Association
In the above ER diagram, a relatiohship conducts is introduced. “Teacher” is associated
with “Course” by conducting it.
Cardinality
Many Teachers can conduct the single course.
Modality
For conduction ofa course, there must be a Teacher.
There may a situation that a Teacher is not conducting any course.
el eae Draw an ER diagram for the relationship between customer and banking
system.
Solution :
Lh. 1
M ay
log 1 accountn Current
=
Transaction t
cust branch
acct, acct,
customer |M La» M ee
Orrow,
Technical
Publication = oe
Specialized
in
Editor Author
Fig. 2.10.8
w Review Question
The flow oriented modelling is down by designing special kind of diagrams called data
flow diagrams and control flow diagrams.
abstraction.
External
e The DFD can be partitioned into levels [ca] entity
that represent increase in information
flow and detailed functionality.
e A level 0 DFD is called as ‘fundamental system model’ or ‘context model’. In the context
model the entire software system is represented by a bubble with input and output indicated
by incoming and outgoing arrows.
e Each process shown in level | represents the sub functions of overall system.
e The number of levels in DFD can be increased until every process represents the basic
functionality.
e As the number of levels gets increased in the DFD, each bubble gets refined. The following
figure shows the leveling in DFD. Note that the information flow continuity must be
maintained.
e The data flow diagrams are used to model the information and function domain.
Refinement of DFD into greater levels helps the analyst to perform functional
decomposition.
1. Level 0 DFD i.e. Context level DFD should depict the system as a single bubble.
3. While doing the refinement isolate processes, data objects and data stores to represent
the next level.
e A simple and effective approach to expand the level 0 DFD to level | 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.
Level 0 DFD
Lili.
Entity A Information Entity B
system
Level 1 DFD
Entity A
Entity B
Data store
Level 2 DFD
Data store
Level 3 DFD
Correct
—_—_—_—_
way
ix =O}
Fig. 2.11.2
2. The verb phrases in the problem description can be identified as processes in the system.
Correct
—
way
Fig. 2.11.3
3. There should not be a direct flow between data stores and external entity. This flow should
go through a process.
Correct —————
——
way
oN N\ Correct
way
Source Sink Source Sink
The control flow diagrams show the same processes as in data flow diagrams but rather
than showing data flow they show control flows.
The control flow diagrams show how events flow among processes. It also shows how
external events activate the processes.
The dashed arrow is used to represent the control flow or event.
A solid bar is used to represent the window. This window is used to control the processes
used in the DFD based on the event that is passed through the window.
Instead of representing control processes directly in the model the specifications are used to
represent how the processes are controlled.
There are two commonly used representations of specifications : Control Specification
(CSPEC) and Process Specification (PSPEC).
When a data input is given to the process a data condition should occur to get the control
output. For Example.
Obtained
temperature
ZS Event gets
generated
Check and Check and
Converted
t Soe temperature eine Pointer
temperature temperature
“SNe
:y eee
™p ~~
Maximum
temperature
The CSPEC .
PSPEC tells us to Signal
do when an go d
if obtained temp > max temp event occurs etre
set above_temp = TRUE
else
set above_temp = FALSE
begin
temp_conversion algorithm:
compute converted temp;
end
end if
There are certain applications which are event driven rather than being data driven. They
produce control information rather than producing data(may be report, displays). Such
applications can be modeled with the control information along with data flow modeling.
A graphical model used to represent the control information along with the data flow model
is called control flow model.
The following guideline is used while drawing the control flow diagrams.
1. List all the sensors that can be read.
2. List all the interrupt conditions.
3. List all the data conditions.
4. List all the switches actuated by the operator.
Bt Use noun/verb parsing technique to identify the control information.
6. Describe behavior of the system by identifying the states. Define the transition
between the states.
7. Avoid common errors while specifying the control.
2.11.3. Examples
el wea DED for library information system. A student comes to a library for
borrowing book. The student makes the book request by giving book title and author name.
The student has to submit his library card to the library. Sometimes student may simply
give topic and demand for a book (For example ‘just give me book on data structure”).
The library information system maintains list of authors, list of titles, list of topics. This
system also keeps record of topics on which books are available with the system. This
system maintains information about shelf number on which books are located. Finally the
list of demanded book should be displayed, on the console for ease of selection. Draw first
level of DFD.
Solution : In this DFD the whole system is represented with the help of input, processing and
output. The input can be -
i) Student requests for a book hence Book request.
ii) To show identity of the student he/she has to submit his/her Library card, hence Library
card. The processing unit can be globally given as
Book request -
Library
Information Demanded Display of
Suen Library card Book
System book Info
ii) The library information system should display demanded book information which can be
used by customer while selecting the book.
Level 1 DFD
er ee
Book selves
Book request
Student Library
i card ¥ Boe
Delive: Author (s) aatine
List of
Hoot List of
Titles
demanded
List of topics
Display of
Book request Book
(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.
Level 2 DFD
Out of scope :
The purchasing of new books/replacement of old books or charging a fine all these
maintenance activities are not considered in this system.
Book request
Student Book shelf
Shelf number
and book info/no.
List of
Titl
Book title dts
Demanded
book
Display of
Book
Fig. 2.11.9
el ewes Draw DFD for food ordering system. A customer goes to a restaurant and
orders for the food. The food order is noted down carefully and this order is sent to kitchen
for preparing the required food.
This restaurant has to manage one housekeeping department which maintains sold items
and inventory data. The daily information about sold items and inventory deplition amount
is used to generate a management report. Finally this management report is given to
restaurant manager.
Solution :
Level 0 DFD
In this level, the system is designed globally with input and output. The input to food
ordering system are -
1. As customer orders for the food. Hence food order is an input.
The output to food ordering system are -
1) Receipt.
Orders for
the food
Food
ordering
Food order
Receipt system
Bill
oe
Manag
Feport? Ment Restaurant
manager
2) The food order should be further given to kitchen for processing the order.
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 -
2. Inventory database.
Finally management report can be prepared using daily sold details and daily inventory
deplition amount. This management report is given to restaurant manager.
Level 3 DFD : In this DFD we will elaborate “Generate management report” activity in more
detail. For generating management report we have to access sold items data and inventory
data. Then aggregate both solid items data and inventory data. Total price of each item has to
be computed. Then from these calculation a management report has to be prepared and given
Orders for
ustenien food Food order
Processing of
an order
Receipt
Formatted
Database of sold sold item data Formatted Inventory
items inventory data database
Info. about daily sold items Fee Info. about daily inventory
and amount report depletion amount
Management | Restaurant
report manager
Access sold
items Inventory depletion Inventory
Info about daily sold items amount database
and amount
and
inventory data
Inventory
data
Aggregate
inventory
data
and sold items
Inventory and
sold items list
Compute the
total price
of each item
el ewes Prepare a CFD for a Books order processing system. The customers in this
stem are book sellers who do not make a stock of books. As the orders come the books are
demanded from publishers directly.
As per the problem description it is clear that the input to this system is ‘customer’ who
places an order and output will be purchase order given to publisher.
Solution :
Purchase
Books order
processing Publisher
system
Now, we will do more detailing for order processing when an order is received by the
system, it will be first verified using the books database. Credit rating will be decided by
checking customer details (i.e. whether the customer is regular customer or whether he is
new). For submitting a batch of orders we have to maintain pending orders list as well. There
may be the order for books which are published by different publishers, in such a case database
for different publishers need to be maintained by the system. This list of purchase orders is
maintained by the system and then after verifying the shipment a shipping note will be given to
the customer. The level 1 decomposition is as shown below —
Books Info
Places
Customer
Verification
of order
ratings Customers details
Order
Pending order
Batch of
orders
Purch
Assemble order wrenesé Publisher
order
Shipping
note
List of
corresponding
publishers
Publishers
Purchase orders
Verify
shipment
We can further decompose the system by elaborating the process Assemble order. In
assemble order we
e First get details of total copies per title.
e Then prepare purchase order accordingly for corresponding publishers.
e Send these purchase orders to publishers.
e These purchase order details should be stored in the system. Let us draw level 2 CFD for
these details.
Pending orders
Batch
of orders
List of
corresponding
publishers
Publishers
Store
P.O. details
Batch of
orders
Purchase orders
Fig. 2.11.16
Solution : The system then gives these booking details to the corresponding hotel. Design
DFD for this system.
i Reservation
Booking Online hotel
details reservation details Hotel
Customer
system
Charges
Customer
details Processing details
Customer request
Hotel names
Charges Hotels details
Room , time,
charges, available
Suitable info.
details
patra
7 Confirmation R ‘eservation
i
of detail | lotel
reservation Sia
Booking details
Hotel name
Charges
Seu Cwaey Based on your experience with a bank ATM draw a DFD modelling the
processing involved when customer withdraws cash from the machine.
Solution : The DFD for ATM system can be drawn with level 0 DFD and level 1 DFD. The
level 0 DFD is the context level DFD in which only inputs and outputs that are interacting with
the system are given.
Customer Ss
keypad creen
Printout
dispenser
Control Cash
system dispenser
Card
reader
Screen
Card
ioader Ac. no and
validity
of card Control
system
Checks
Request availability Update \|_Cash Cash
for withdrawal of amount database details dispenser
Account
info
Fig. 2.11.21
Sel we Draw level 0 DFD and level 1 DFD for railway reservation system. Also
write the data dictionary for the same.
Solution :
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.
Fare amount
Reservation Passenger
Passenger Processing Passenger database
details request details
Calculated
fare amount
Ch,
Suitable Reservation
details details
Data Dictionary
Name: Reservation Details or Ticket
Aliases : None
Where used/how used : For reserving seat details of passenger are used as input.
Reservation details of reserved seat is output.
Description :
Passenger nam First name + Middle name + Surname.
oO
In number of years.
Male/Female.
Reservation number Boggue number + Coach number
Starting location Name of city
Destination location Name of city
Train details Train number + Name of the train + Up or down
+ Date and time of departure + Time of arrival
Fare Total amount of fare for entire journey.
Command for
Photocopy
Invoke input
I
Command for Woke
for
Photocopy
Photocopies @) stop
Reading done
. Making
Invoke read Invoke next input copying
input Invoke for
making copy Invoke
reload
ee
Invoke and — Paper
Reload jammed
manage paper ;
copying
eu Draw the data flow diagram upto level 1, for a ‘temperature monitoring
system' in an intensive care unit ofa hospital. SPPU : Dec.-11, Marks 8
Temperature
monitoring
system
DFD Level 1
Patient
sign
controlling
Log
update
Log Request
Example 2.11 Draw and explain context level, level 1 and level 2 DFD for college
gathering. eee ere Co ced
Solution : In this system whole system is represented with the help of input processing and
output. The input can be
1. Students 2. This system should show output as gathering.
0.0
Participates/ College Program Display
gathering
system
| schedule gated
schedule
Participation Student
Processin: ‘uden
Suen participation\ request g info details
info
Checking oes
availability Program
of timing details info
slot hae
oes
Scheduling \ Program isplay
for the gathering schedule
program
Registering’
name, Student
performing _details
details
Cancelling Checking
entry
2.2
Preparing \ Program aepey
i
timetable } schedule gathering
Sonenule
Reservation no
Customer Customer
Rental fee
Returned car
Service Account
centre department
Checked car
Fig. 2.11.33
Reservation no
Car record
Car information Reserve
Customer Customer
information
New New
customer reservation
record record
D3} Car master
Car record
New ;
customer cae ee
record
Car information
Account
department
Returned car
Service
Customer Checked car center
Fig. 2.11.34
w Review Question
1. Explain the data flow model with example and diagram. SPPU : Dec.-14, Marks 5
Behavioral Modeling
The dynamic behaviour of the system can be represented by creating the behavioural
model of the system. Basically the behavioural model represents how software will respond to
external events or stimuli. Following steps need to be followed while creating behavioural
model -
1. Evaluate use-case diagrams for understanding the sequence of interactions between the
system.
2. Identify the events for interactions and co-relate the classes with these events.
3. Create a sequence for each use-case.
4. Create a state diagram for the system.
5. Finally review behavioural model.
The state transition diagram is basically a collection of states and events. The events cause
the system to change its state. The state transition diagram also represents what actions are to
be taken on occurrence of particular event.
tid Initial state It indicates the starting state of the system.
-— Cancel transaction
Getting
Choosing Ejecting
transaction card
chosen
Performing
transaction Finished
Another transaction transaction
Fig. 2.12.1
2.12.3 Sequence Diagram
In the sequence diagram how the object interacts with the other object is shown. There are
sequences of events that are represented by a sequence diagram.
x Destruction of object.
Insert card
Display balance |
Eject card
During requirements engineering, the inception, elicitation and elaboration determine the
customer requirements. But the requirements obtained by these tasks are not in sufficient
details. There is an important requirement engineering task named negotiation in which the
developer communicates with the customer so that some requirements specified by the
customer can be negotiated or modified in order to meet the budget and deadline of the project.
Negotiations are carried out for following two reasons -
1. In order to develop the project plan.
2. By negotiations the real-world constraints are understood by both the developer and
the customer.
If WIN_WIN situation is achieved after the negotiation then it is called as best negotiation.
The WIN-WIN situation means customer gets satisfied because his major needs are going to
get fulfilled and developer gets satisfied because the project development will be based on
realistic goals and achievable budgets and deadlines.
The communication with the customer is the most important activity for the negotiation.
Apart from this following are some important activities suggested by Bohm for
negotiations -
1. Identify the important stakeholders of the system
2. Determine the requirements that are most important for the customer.
3. Negotiate with the customer in order to achieve the WIN-WIN condition.
The analysis model is reviewed for consistency and unambiguity. Various requirements are
prioritised and grouped in the software packages.
Following are some important questions that are considered while validating the
requirements. This is also known as requirements validation checklist -
1. Does each requirement consistent ?
2. Are the requirements abstract ? That means - does the technical details of requirements are
appropriate ?
Does particular requirement really necessary ?
oe
Review Question
1. What do you think happens when requirement validation uncovers an error ? Who is
involved in correcting error ? SPPU : Dec.-14, Marks 5
e RTM traces all the requirements from design, development, and testing.
e The traceability matrix is typically a worksheet that contains the requirements with its all
possible test scenarios and cases and their current state, i.e. if they have been passed or
failed. This would help the testing team to understand the level of testing activities done for
the specific product.
(1) Requirement ID
Example
TC#002 Pass
TC#O03 Pass
It shows the overall defects or execution status with a focus on business requirements.
eo
It helps in analysing or estimating the impact on the QA team's work with respect to
revisiting or re-working on the test cases.
feasibility study
all of these
Q.5 The process to gather the software requirements from client, analyse and document them
is known as
unctional, non-functional
Q.7 Theterm___ is used to refer to any person or group who will be affected by the
system, directly or indirectly.
customer
Q.8 DFDstandsfor
Data Flow Deployment [b] Data Flow Design
Q.9 Which one of the following is a requirement that fits in a developer's module ?
Testability
Usability Flexibility
Q.10 In the requirement analysis which model depicts the information domain for the
problem ?
Q.11 "Consider a system where a heat sensor detects an intrusion and alerts the security
company ". What kind of requirement the system is providing ?
Functional [b] Non functional
dynamic static
Q.15 While dealing with the system requirements __ and __ factors are considered.
[a] coding and design [b] coding and maintenance
none of these
Q.19 requirements constraint the system being developed and the development
process that should be used.
Functional [b] Nonfunctional
Architectural Classification
Composition Data-flow
Q.21 Which of the following is not a check for requirements validation process ?
Validity [b] Consistency
Qi d Q.2 b Q3 c Q4 c
Q.21 d Q.22 a
O00
Notes
Syllabus
Estimation for Software Projects : The Project Planning Process, Defining Software
Scope and Checking Feasibility, Resources management, Reusable Software Resources,
Environmental Resources, Software Project Estimation, Decomposition Techniques,
Software Sizing, Problem-Based Estimation, LOC-Based Estimation, FP-Based
Estimation, Object Point (OP)-based estimation, Process- Based Estimation, Estimation
with Use Cases, Use-Case-Based Estimation, Reconciling Estimates, Empirical
Estimation Models, The Structure of Estimation Models, The COCOMO II Mode,
Preparing Requirement Traceability Matrix
Project Scheduling : Project Scheduling, Defining a Task for the Software Project,
Scheduling.
Contents
3.1 The Project Planning Process
3.6 Empirical Estimation Model seveeeseeseee---DeC.-11, 16, 17, 18, May-16..... Marks 8
3.8 Project Scheduling Tor ssdee sects nee DOC 916, 1D Sst, cco cer Rete eeredtese Marks 6
3.10 Task Network secsserceeeeeseeee May-11, 18, 19, Dec.-13, 17..... Marks 8
3.11. Scheduling with Time Line Chart. ...........000++ Dec.-12,16, May-18............000+ Marks 8
e Project planning is an activity in which the project manager makes reasonable estimates of
resources, cost and Schedule.
e In order to make these estimates, it is necessary to prepare a project plan and the beginning
of the project and as the project proceeds this plan can be updated appropriately.
e Following figure represents various task sets that are associated with project planning
process.
Determine y
project scope Analyze Identify
and feasibility risk resources
Develop Estimate
project cost &
schedule efforts
Step 1: This is an initial stage in which the scope and feasibility of the project is determined.
This stage helps to identify the functions and features that can be delivered to the
end user.
Step 2: Risks are identified and analyzed.
Step 3: The required resources such as human resources, environmental resources, and
reusable software resources can be determined.
Step 4: The estimation for cost and efforts is made. In this stage the problem is first
decomposed, then using the size, function point or use cases the estimates are made.
Using the scheduling tools or task networks the schedule for the project is prepared.
2. Scope can be defined as a set of use cases developed by the end users.
e In the scope description, various functions are described. These functions are evaluated
and refined to provide more details before the estimation of the project.
e For performance consideration, processing and response time requirements are analyzed.
e The constraints identify the limitations placed on the software by external hardware or any
other existing system.
e After identifying the scope following questions must be asked -
© Can we build the software to meet this scope ?
© Is this software project feasible ?
That means after identifying the scope of the project its feasibility must be ensured.
e Following are the four dimensions of software feasibility. To ensure the feasibility of the
software project the set of questions based on these dimension has to be answered. Those
are as given below -
1. Technology
2. Review Question
1. What is the need for defining a software scope ? What are the categories of software
engineering resources ? SZ Dec.-17,May-18, End Sem, Marks 7
Resource Management
e The first task in project planning is to identify the scope and feasibility of the project and
the second task is to estimate the resources required to accomplish the software
development efforts.
e There are three major categories of software engineering resources -
1. Peoples
2. Reusable software components
Development environment i.e. hardware and software tools.
Ww
Software resources
New component
e The Project Planner begins by evaluating software scope and selecting the "skills"
required to complete development.
e Both organizational position (such as manager, senior software engineer and so on) and
the specialty (database telecommunication, client/server etc) are specified for a relatively
small project. A single individual may perform all software engineering tasks, by
consulting with the specialist whenever needed.
e For larger projects, software team may be geographically at different locations. Hence, the
location of each human resource is specified. The number of people required for a software
project can be determined only after an estimate of development effort
(e.g. person-months) is made. The techniques for estimating development effort can be
LOC (Lines Of Code) based or based on FP (Function Point).
According to need and specification of the current project the software components can be
built by the software team.
Software project estimation can be performed in systematic steps with acceptable risks.
In order to obtain reliable cost and effort estimations various alternatives can be used —
1. Delay the estimation activity as far as possible.
2. The base estimates can be made using the similar projects.
3. Using simple decomposition techniques the project cost and effort estimates can be made.
4. Empirical models can be used for project cost and effort estimation.
For the first and second alternatives are simple. The third and fourth alternative suggests
use of specific approach of project estimation techniques. Let us discuss these approaches of
software project estimation in detail.
wa Review Question
1. What is need of project estimation? What are the steps while estimation of software?
SPPU : May-19, Dec.-19, End Sem, Marks 8
Decomposition Techniques
SPPU : May-11, 18, 19, Dec.-11, 12, 15, 19, Marks 9
Software project estimation is just similar to problem solving. Many times the problem to
be solved is too complex in software engineering. Hence for solving such problems, we
decompose the given problem into a set of smaller problems.
The decomposition can be done using two approached decomposition of problem or
decomposition of process. Estimation uses one or both forms of decomposition (partitioning).
e Following are certain issues based on which accuracy of software project estimate is
predicated -
1. The degree to which planner has properly estimated the size of the product to be built.
2. The ability to translate the size estimate into human-effort, calendar time and money
The degree to which the project plan reflects the abilities of software team.
WwW
The stability of product requirements and the environment that supports the software
>
engineering effort.
e Sizing represents the project planner's first major challenge. In the context of project
planning, size refers to a quantifiable outcome of the software project.
e The sizing can be estimated using two approaches - a direct approach in which lines of
code is considered and an indirect approach in which computation of function point is
done.
e Putnam and Myers suggested four different approaches for sizing the problem -
With a bounded statement of software scope a project planning process begins and by using
the statement of scope the software problem is decomposed into the functions that can be
estimated individually.
(LOC) or (FP) is then estimated for each function.
Baseline productively metrics are then applied to the appropriate estimation variable and
cost or effort for the function is derived.
Function estimates are combined to obtain an overall estimate for the entire project.
Using historical data the project planner expected value by considering following
variables -
1. Optimistic 2. Most likely 3. Pessimistic
For example, following formula
S = [Spe +4* Sin + Spressl / 6
considers for "most likely" estimate where S is the estimation size variable, Sont represents
the optimistic estimate, Sin represents the most likely estimate and S cass represents the
pessimistic estimate values.
e Expected LOC for 3D Geometric analysis function based on three point estimation is -
© Optimistic estimation 4700
© Most likely estimation 6000
© Pessimistic estimation 10000
S=[S,,+G@*S)t+ ]/6
opt Sore ‘ess
Expected value = [4700 + (4 * 6000) + 10000] / 6 — 6450
e Areview of historical data indicates -
1. Average productivity is 500 LOC per month
2. Average labor cost is $6000 per month
Then cost for lines of code can be estimated as
cost / LOC = (6000/ 500) = $12
By considering total estimated LOC as 32620
e Total estimated project cost = (32620 * 12)= $391440
e Total estimated project effort = (32620 / 500) = 65 Person-months
FP focuses on information domain values rather than software functions. Thus we create a
function point calculation
c table for ABC project, discussed in section 3.3.3.
| INFO DOMAIN Opt. most likely pessimistic esti. value weight factor FP ]
VALUE
|NO.OF INPUTS 25 28 32 28.1 4 12 |
coorcmeo i —e 2 [or 86) li
[Oommen 17 [em 371: ee 865 [ie
|NO.OFFILES 5 a 7 5.33 10 Lae
| NO.OF EXTERNAL 2 2 3 2 7 15 |
|INTERFACES a
| COUNTTOTAL _ 381
e For this example we assume average complexity weighting factor.
e Each of the complexity weighting factor is estimated and the complexity adjustment factor
is computed using the complexity factor table below. (Based on the 14 questions)
} 2. _Data communication ? 2
| 3 Distributed processing ? 0
4. Performance critical ? 4
2 Review Questions
1. Explain the FP based estimation technique. SPPU : May-18, End Sem, Marks 6
2. Compare the Lines of Code(LOC) and Function Point(FP) based estimation techniques
with suitable example. SPPU : May-19, End Sem, Marks 8
3. How to calculate FP and how it is used in estimation of software project ?
SPPU : Dec.-19, End Sem, Marks 5
e This is the most commonly used estimation technique for estimating the project based on
the processes used.
e In this technique, the process is decomposed into relatively size set of tasks and the effort
required to accomplish each task is estimated.
© The estimation begins with identification of software functions obtained from the project
scope. Then a series of software process activities must be performed for each function.
The function and software process activities are presented in a tabular form. Then planner
estimates the efforts for each software function.
Consider the same project described in section 3.5.3. We can estimate it using process
based estimation technique by creating a table as shown below. In this technique for each of
the business function software engineering tasks such as analysis, design, coding and testing is
carried out. The estimated efforts for each of these functions are identified and their sum is
obtained. In the following table, the sum of all the rows and columns is taken and the effort for
each business function is estimated in percentage.
ACTIVITY cc Planning Risk Engineering Construction TOTAL
analy: release
BUSINESS
FUNCTION
User interface and
control
facilities(UICF)
2D graphics 0.75 0.75 8.00
analysis(2DGA)
wn
“I
na
w
n
Management
(DBM)
Computer graphics 0.50 0.70
iS}
oe
wn
‘o
a
display
Facility(CGDF)
function(PCF)
Total 22.25
Use-cases also provide a software team with insight into software scope and
requirements. But there are some difficulties in developing estimations using use cases
due to the following reasons
= There are varieties of ways by which use cases can be described. There is no unique
format for them.
= Use-cases represent an external view (User's view) of the software. These are also
written at different levels of abstraction. That means some use cases may be written
to expose only primary functions where as some other use cases may describe each
function in more detail.
= The complexity of the functions and features cannot be described by use cases.
= The complex behaviour involved in many functions and features is also not described
in use cases.
In spite of these difficulties the use cases can be used for estimation, but only if they are
considered within the context of structured hierarchy that use cases describe.
Smith argues that any level of structured hierarchy -
1 Can be described by at the most 10 Use-cases.
2. Each use-case would not contain more than 30 distinct scenarios.
Therefore before using the use cases for the estimation -
© The level within the structured hierarchy must be established.
The average length of each use case must be determined.
The type of software application for which estimation is calculated must be defined.
°
After establishing these characteristics, empirical data can be used to estimate LOC or
°
FP for each use case. Then the structured hierarchical data can be used to compute
the efforts required to develop the system,
As we have discussed that estimation can be obtained using LOC, FP, process based and
use-case based techniques. We obtain the estimated efforts for
LOC = 68 person-month
FP = 69 person-month
Process based = 48 person-month
That means the ABC project can be completed with range from a low of 48 Person-months
to high of 69 Person-months. The Average Estimates is 61 Person-months.
1. What is software project estimation ? How use cases are used in estimation ?
SPPU : May-11, Marks 6
The empirical data are derived from a limited sample of projects. Hence this estimation
model is appropriate for all classes of software product. Therefore, the results obtained from
such models must be used judiciously.
where
A, B and C are the constants derived empirically.
E is the effort in persons-months
e, is the estimation variable derived from either LOC or FP.
There are many other estimation models that have some form of project adjustment
components that enables the value of E to be adjusted by other projects characteristic.
e Various LOC based estimation models are -
i! 7 ‘Name of the model = a Estimation ‘
Each of these Models shows different result for the same value of LOC an FP. Therefore
estimation model must be calibrated for local models.
COCOMO II is applied for modern software development practices addressed for the
projects in 1990’s and 2000’s.
The sub-models of COCOMO II model are -
Developers experience and Very low Low Nominal High Very high
capability _
Productivity (NOP/Month) 4 7 13 25 50 |
1 6
l | | | ! J
Very Very
low high
e There is third category of code which is used in reuse model and it is the code which
can be generated automatically. In this form of reuse the standard templates are
integrated in the generator. To these generators, the system model is given as input
from which some additional information about the system is taken and the code can be
generated using the templates.
e The efforts required for automatically the generated code is
PM = (ASLOC x AT/ 100) / ATPROD
where
AT is percentage of automatically generated code.
ATPROD is the productivity of engineers in estimating such code
e¢ Sometimes in the reuse model some white box code is used along with the newly developed
code. The size estimate of newly developed code is equivalent to the reused code.
Following formula is used to calculate the effort in such a case -
ESLOC = ASLOC x (1 —AT/ 100) x AAM
where
ESLOC means equivalent number of lines of new source code.
ASLOC means the source lines of code in the component that has to be adapted.
AAM is adaptation Adjustment multiplier. This factor is used to take into the efforts
required to reuse the code.
The exponent term B has three possible values that are related to the levels of project
complexity. The values of B are continuous rather than discrete. It depends upon the five
scale factors. These scale factors vary from very low to extra high (i.e. from 5 to 0).
Development flexibility Flexibility in development process. Very low means the typical
process is used. Extra high means client is responsible for
defining the process goals.
Architecture/risk resolution Amount of risk that is allowed to carry out. Very low means little
risk analysis is permitted and extra high means high risk analysis
is made.
Team cohesion Represents the working environment of the team. Very low
cohesion means poor communication or interaction between the
team members and extra high means there is no communication
problem and team can work in a good spirit.
Process maturity This factor affects the process maturity of the organisation. This
value can be computed using Capacity Maturity Model (CMM)
questionnaire, for computing the estimates CMM maturity level
can be subtracted from 5.
e Add up all these rating and then whatever value you get, divide it by 100. Then add the
resultant value to 1.01 to get the exponent value.
e This model makes use of 17 cost attributes instead of seven. These attributes are used to
adjust initial estimate.
a= peng EAS ae ee ea
| DOCU Product Some amount of documentation used
wa Review Questions
Lorenz and Kidd suggested the estimation technique for object oriented project. The steps
for this estimation technique are as follows -
1. Using requirement model, develop use cases and determine the count. As the project
proceeds, the number of use cases may get changed.
2. Using the requirement model, determine the number of key classes.
3. Categorize the type of interface and develop the multiplier. For example
| Complex GUI |
Multiply the key classes by these multipliers to obtain the number of support classes.
4. Now multiply the key and support classes by average number of work units per class.
Approximately there are 15-20 person-days per class.
e While scheduling the project, the manager has to estimate the time and resource of the
project.
e All the activities in the project must be arranged in coherent sequence.
e The schedules must be continually updated because some uncertain problems may occur
during the project life cycle.
e For new projects initial estimates can be made optimistically.
e During the project scheduling the total work is separated into various small activities. And
time required for each activity must be determined by the project manager.
e For efficient performance some activities are conducted in parallel.
e The project manager should be aware of the fact that : Every stage of the project may not be
problem-free.
e Some of the typical problems in project development stage are :
© People may leave or remain absent.
© Hardware may get failed.
© Software resource may not be available.
e To accomplish the project within given schedule the required resources must be available
when needed.
e Various resources required for the project are -
© Human effort
© Sufficient disk space on server
© Specialized hardware
© Software technology
© Travel allowance required by the project staff.
e Project schedules are represented as the set of chart in which the work-breakdown structure
and dependencies within various activities is represented.
w Review Question
1. What is project scheduling ? What are the basic principles of project scheduling ?
SPPU : Dec.-16, End Sem. Marks 6, Dec.-19, End Sem, Marks 5
Definition of task set : The task set is a collection of software engineering work tasks,
milestones, and work products that must be accomplished to complete particular project.
Every process model consists of various tasks sets. Using these tasks sets the software team
define, develop or ultimately support computer software.
There is no single task that is appropriate for all the projects but for developing large,
complex projects the set of tasks are required. Hence every effective software process
should define a collection of task sets depending upon the type of the project.
Using tasks sets the high quality software can be developed and any unnecessary work can
be avoided during software development.
The number of tasks sets will vary depending upon the type of the project. Various types of
projects are enlisted below -
1. Concept Development project : These are the projects in which new business ideas
or the applications based on new technologies are to be developed.
2. New application development project : These projects are developed for satisfying a
specific customer need.
3. Application upgradation project : These are kind of projects in which existing
software application needs a major change. This change can be for performance
improvement, or modifications within the modules and interfaces.
4. Application maintenance project : These are kind of projects that correct, adapt or
extend the existing software applications.
5. Reengineering projects : These are the projects in which the legacy systems are
rebuilt partly or completely.
Various factors that influence the tasks sets are -
1. Size of project 2. Project development staff
3. Number of user of that project 4. Application longetivity
5. Complexity of application 6. Performance constraints
7. Use of technologies
Task set example : Consider the concept development type of the project. Various tasks
sets in this type of project are -
© Defining scope : This task is for defining the scope, goal or objective of the project.
© Planning : It includes the estimate for schedule, cost and people for completing the
desired concept.
© Evaluation of technology risks : It evaluates the risk associated with the technology
used in the project.
© Concept implementation : It includes the concept representation in the same manner
as expected by the end user.
1.4 {b) ee a] /,
= Technical
FER Impl
7SIB)
Implementation
i
rier
Customer
feedback
e The task network definition helps project manager to understand the project work
breakdown structure.
e The project manager should be aware of interdependencies among various tasks. It should
be aware of all those tasks which lie on the critical path.
x. Review Questions
1. What is a task network in project scheduling ? Explain with an example.
: May -11, 18, 19, End Sem, Marks 6, Dec.-17
2. What is a task network ? How it is used in scheduling of software project ?
SPPU : May -11, Dec.-13, Marks 8
e In software project scheduling the timeline chart is created. The purpose of timeline chart
is to emphasize the scope of individual task. Hence set of tasks are given as input to the
time line chart.
e The time line chart can be developed for entire project or it can be developed for individual
functions.
2) The horizontal bars indicate the time required by the corresponding task.
3) When multiple horizontal bars occur at the same time on the calendar, then that means
e In most of the projects, after generation of time line chart the project tables are prepared. In
project tables all the tasks are listed along with actual start and end dates and related
information.
Example
1. 2 Software development F VF Vv 7
1 2. 1 Requirements analysis I
4 . 2. 2 Architectural design
1 . 2. 3 Procedural design 1
1.2.4 Code L
1.3 Testing + a +
1.3. 1 Unit test
4 . 3. 2 Integration test
1 3. 3 Acceptance test
1 . 4 Operations
1 .4. 1 Packaging y —_
1 . 4. 2 Customer training I
Project table
——__—_____- a :
th
Requirement analysis 6° Sept’05 6" Sept’05 20" Sept’05 22" Sept’05 Jayashree, Padma, Lucky
|
| Architectural design 27" Sept’05 27" Sept’05__ 3" Oct’05 7" Oct’05 — Trupti, Varsha
| Procedural design 10" Oct’05 12" Oct’05 24" Oct’05 25" Oct’05 Varsha, Sachin, Devendra
j — = —
| Customer training 1* Jan’06 4" Jan’06 22" Jan’06 25" Jan’06 ~— Smita, Yogita
Review Questions
e The schedule tracking tools help the project manager to define work tasks and their
interdependencies.
It is possible to assign human resources to these tasks and develop graphs, charts and tables
that are required for tracking the schedule.
e The Microsoft project and Daily Activity Reporting and Tracking are commonly used
scheduling tools. Let us discuss them briefly.
e Microsoft has offered a project management tool named Microsoft Project for project
planning activities.
i) Developing the project plan ii) Assigning the resources to the tasks
Features
Various features of MS planning tool are
1. It generates variety of reports and templates with industry standard.
2. Themes can be customized and some elements can be removed.
3. The date can be set for the tasks to accomplish.
4. It has got the compatibility with other programs such as Microsoft Word, Excel, Visio and
so on.
5. It can support for the cloud services to share the work among the geographically distant
developers.
e This tool enables you to track the changes to record being made by users.
e Many organizations deploy the Daily activity reporting and tracking tool that monitors the
progress of the software project.
e DART collects the activity data and keep track of the work flow.
e DART can compute the set of business queries which are also called as indicators that can
be used to keep track of the performance.
e The aim of DART is to empower software project stakeholders in their daily discussion
regarding the performance of the project.
Q.3 Which of the following is activity is not the part of project planning ?
Q.4 Which of the following is an important factor that affects the accuracy and efficacy of
estimates ?
Complexity of project [b] Size of project
Q.6 Following are the phases of project management life cycle. Arrange them in correct order
1. Design 2. Marketing
3-2-1-4 1-2-3-4
2-3-1-4 4.3-2-1
Q.7 Assembling project team and assigning their responsibilities are done during which phase
of a project management ?
Initiation [b | Planning
Execution Closure
reliability availability
security reusability
Q.10 Following is a basic parameter based on which all other estimations can be made during
project planning.
Efforts Duration
Schedule Project size
Q.12 Which of the following can be used for project size estimation ?
[a ]Loc [b]FP
[c | Fuzzy logic [d | LOC and FP
Q.14 Which of the following is an activity that is conducted before requirements analysis and
specification phase ?
Project planning [b | Project monitoring
hardware [b | software
people both a and b
Q.16 The size estimate for the software product build on LOC is considered as a direct measure
True False
Q.18 Which software project sizing approach develop estimates of the information domain
characteristics ?
None of these
Qi c Q2 d Q5 b Qa b
Qs d Q6 a Q7 a Q.8 a
Qs c Q.10 d Qu d Q.12 d
Q.13 b Qa a Q13 d Q.16 a
Q.17 d Q.18 a Q3 b Q.20 a
goog
Syllabus
Design Concepts : Design within the Context of Software Engineering, The Design
Process, Software Quality Guidelines and Attributes, Design Concepts - Abstraction,
Architecture, design Patterns, Separation of Concerns, Modularity, Information Hiding,
Functional Independence, Refinement, Aspects, Refactoring, Object-Oriented Design
Concept, Design Classes, The Design Model, Data Design Elements, Architectural
Design Elements, Interface Design Elements, Component-Level Design Elements,
Component Level Design for Web Apps, Content Design at the Component Level,
Functional Design at the Component Level, Deployment-Level Design Elements.
Architectural Design : Software Architecture, What is Architecture, Why is
Architecture Important, Architectural Styles, A brief Taxonomy of Architectural Styles.
Contents
4.1 Concept of Design .....Dec.-12,16, May-14 .-..-Marks 8
4.2 The Design Process
4.3 Software Quality Guidelines and Attributes ......... Dec.-12, 16, 19, May-14 ...... Marks 8
4.4 Design Concepts ou... sseeeeee April-15, May-11, 13, 15, Dec.-12, 16 .......... Marks 8
4.5 Object Oriented Design Concepts
4.6 Design Classes keeeteeeeee DOC TB iid cdecsedecgsnoerstndysbecgih cdesrievsbedesBedashedens Marks 6
4.7 The Design Model and Elements.............. Dec.-11, May-13, 14... Marks 8
4.8 Component Level Design
4.9 Class Based Design
4.10 Conducting Component Level Design
4.11 Component Level Design for Web Apps
4.12 Software Architecture
4.13 Architectural Styles «ww. Dec.-11,12, MAay-12 00... .eeeeeceeceeceseeeeeeeeeeees Marks 8
4.14 Multiple Choice Quesions
(4-1)
Software Engineering 4-2 Design Engineering
Definition : Software design is model of software which translates the requirements into
finished software product in which the details about the software data structures,
architecture, interfaces and components that are necessary to implement the system are
given.
e Software design is an iterative process using which the user requirements can be translated
into the software product.
e At the initial stage of the software is represented as an abstract view. During the sub-
sequent iterations data, functional and behavioral requirements are traced in detail. That
means at each iteration the refinement is made to obtain lower level details of the software
product.
Characteristics of Good Design
1. The good design should implement all the requirements specified by the customer. Even
if there are some implicit requirements of the software product then those requirements
should also be implemented by the software design.
2, The design should be simple enough so that the software can be understood easily by the
developers, testers and customers.
The design should be comprehensive. That means it should provide complete picture of
ios)
the software.
e Software design is at the core of software engineering and it is applied irrespective of any
process model.
e After analysing and modelling the requirements, software design is done which serves as
the basis for code generation and testing.
e Software designing is a process of translating analysis model into the design model.
e The analysis model is manifested by scenario based, class based, flow oriented and
behavioural elements and feed the design task.
e The classes and relationships defined by CRC index cards and other useful class based
elements provide the basis for the data or class design.
e The architectural design defines the relationship between major structural elements of the
software. The architectural styles and design patterns can be used to achieve the
requirements defined for the system.
Class-based
nts, Fi |?
gore SW Orig elements
+ Data flow Ve, 1» Flow-oriented Sie hed
diagram elements. Basia
* Usecase diagram « Control flow > Behavioral ?
Ff «Activity diagram diagram elements ges
of, *» Processing + Scenario-based
oot rrarratives aiamnd abs nace
iagram —+ |e Flow-oriented Interface | —> ces
7 elements
* Class diagram « State ean design
o\ + Analysis erie elaridiike Architectural design
.
BA package diagram > Flow-oriented
% * CRC models elements. Architectural
Ng ¢ Collaboration > Class-based design Data/class diagram
diagrams elements
a pik 1» Class-based Data/ class
Bel elements diagram Design mode!
The interface design describes how software communicates with systems. These systems
are interacting with each other as well as with the humans who operate them. Thus interface
design represents the flow of information and specific type of behaviour. The usage
scenarios and behavioural models of analysis modelling provide the information needed by
the interface design.
The component-level design transforms structural elements of software architecture into
procedural description of software module. The information used by the component design
is obtained from class based model, flow based model and behavioural model.
Software design is important to assess the quality of software. Because design is the only
way that we can accurately translate the user requirements into the finished software
product.
Without design unstable system may get developed. Even if some small changes are made
then those changes will go fail .It will become difficult to test the product. The quality of
the software product can not be assessed until late in the software process.
Software design is an iterative process in which the requirements are translated into the
blueprint of the software. Initially the software is represented at high level of abstraction,
but during the subsequent iterations data, functional and behavioural requirements are
traced in more detail.
Thus refinement made during each iteration leads to design representations at much lower
level of abstraction. Throughout the software design process the quality of the software is
assessed by considering certain characteristics of the software design.
e In order to evaluate quality of software there should be some predefined rules or criteria
that need to be used to assess the software product. Such criteria serve as characteristics for
good design.
2. In the design the data, architecture, interfaces and components should be clearly
represented.
3. The design should be modular. That means the subsystems in the design should be
logically partitioned.
4. The data structure should be appropriately chosen for the design of specific problem.
5. The components should be used in the design so that functional independency can be
achieved in the design.
6. Using the information obtained in software requirement analysis the design should
be created.
7. The interfaces in the design should be such that the complexity between the
connected components of the system gets reduced. Similarly interface of the system
with external interface should be simplified one.
8. Every design of the software system should convey its meaning appropriately and
effectively.
Quality Attributes
2 Review Questions
1. Explain the quality attributes, considered in software design. SPPU : Dec.-12, Marks 8
2. What are the design quality guidelines ? SPPU : May-14, Marks 8
3. Explain the quality attributes, considered in software design ;
SPPU : Dec.-16, End Sem, Marks 5
The software design concept provides a framework for implementing the right software.
Following
Following are
are certain
certain issues
is ues thatthat aare
re considered
considered while
while designing
designing the
the softwar
software -
4.4.1 Abstraction
e In data abstraction the collection of data objects is represented. For example for the
procedure search the data abstraction will be record. The record consists of various
attributes such as record ID, name, address and designation.
4.4.2 Modularity
© The software is divided into separately named and addressable components that called as
modules.
* Monolithic software is hard to grasp for the software engineer, hence it has now become a
trend to divide the software into number of products, But there is a co-relation between the
number of modules and overall cost of the software product.
e Following argument supports this idea -
“Suppose there are two problems A and B with varying complexity. If the complexity of
problem A is greater than the complexity of the problem B then obviously the efforts
required for solving the problem A is greater than that of problem B. That also means the
time required by the problem A to get solved is more than that of problem B.”
® The overall complexity of two problems when they are combined is greater than the sum of
complexity of the problems when considered individually, This leads to divide and
conquer strategy (according to divide and conquer strategy the problem is divided into
smaller subproblems and then the solution to these subproblems is obtained).
e Thus dividing the software problem into manageable number of pieces leads to the concept
of modularity.
e It is possible to conclude that if we subdivide the software indefinitely then effort required
to develop each software component will become very small. But this conclusion is invalid
because the total number of modules get increased the efforts required for developing each
module also gets increased.
e That means the cost associated with each effort gets increased.
e The effort (cost) required for integration these modules will also get increased.
e The total cost required to develop such software product is shown by Fig. 4.4.1.
e The Fig. 4.4.1 provides useful guideline for the modularity and that is - overmodularity or
the undermodularity while developing the software product must be avoided. We
should modularize the software but the modularity must remain near the region denoted by
M.
Total software,
Cost to
integrate
Total number of
Effort or cost
modules must be
within this region,
It is a region of
minimum cost
Perse module
Region of under - Region of
modularity over-modularity
Number of
modules
¢ Modularization should be such that the development can be planned easily, software
increments can be defined and delivered, changes can be more easily accommodated and
long term maintenance can be carried out effectively.
e Meyer defines five criteria that enable us to evaluate a design method with respect to its
ability to define an effective modular system :
1. Modular decomposability : A design method provides a systematic mechanism for
decomposing the problem into sub-problems. This reduces the complexity of the
problem and the modularity can be achieved.
2. Modular composability : A design method enables existing design components to be
assembled into a new system.
3. Modular understandability : A module can be understood as a standalone unit. It
will be easier to build and easier to change.
4.4.3 Architecture
Model Functioning !
- = oe 7
4.4.4 Refinement
4.4.5 Pattern
According to Brad Appleton the design pattern can be defined as - It is a named nugget
(something valuable) of insight which conveys the essence of proven solution to a recurring
problem within a certain context.
In other words, design pattern acts as a design solution for a particular problem occurring
in specific domain. Using design pattern designer can determine whether-
e Pattern can be reusable.
e Pattern can be used for current work.
e Pattern can be used to solve similar kind of problem with different functionality.
e The functional independence can be achieved by developing the functional modules with
single-minded approach.
e By using functional independence functions may be compartmentalized and interfaces are
simplified.
e Independent modules are easier to maintain with reduced error propagation.
e Functional independence is a key to good design and design is the key to software quality.
¢ The major benefit of functional independence is in achieving effective modularity.
e The functional independence is assessed using two qualitative criteria - Cohesion and
coupling.
4.4.7.1 Cohesion
4.4.7.2 Coupling
Coupling effectively represents how the modules can be “connected” with other module or
with the outside world.
Coupling is a measure of interconnection among modules in a program structure.
Coupling depends on the interface complexity between modules.
The goal is to strive for lowest possible coupling among modules in software design.
The property of good coupling is that it should reduce or avoid change impact and ripple
effects. It should also reduce the cost in program changes, testing and maintenance.
Various types of coupling are :
i) Data coupling : The data coupling is possible by parameter passing or data
interaction.
ii) Control coupling : The modules share related control data in control coupling.
iii) Common coupling : In common coupling common data or a global data is shared
among the modules.
iv) Content coupling : Content coupling occurs when one module makes use of data or
control information maintained in another module.
4. The major drawback of content coupling © The major drawback of common coupling
is that - if we want to reuse one _ is that - modules in the common coupling are
component we need to import all the — tightly coupled. A fault in one module using
components that are coupled with the — global data may show up in another module
component being reused. because global data may be updated by any
module at any time. This greatly affects the
: reusability of modules. 7
5. The access to internal structure is of main ‘The access to global data is of main concern
concern in this kind of communication. in this kind of communication.
6. In this coupling, component directly In common coupling, it is difficult to
modifies another's data. determine all the components that affect a
= _data element. oe
7 Example - Part of Program that searches Example - A process control component that
for the entry of particular employee. when _ maintains the status of operations in a global
the module does not find the entry for the data store. This control block gets data from
employee, it directly adds employee multiple sources or supplies data to multiple
modifying the contents of data structure sinks. Each source process writes the status
containing employee data. of its operation directly to the global data
store.
4.4.8 Refactoring
Refactoring is necessary for simplifying the design without changing the function or
behaviour. Fowler has defined refactoring as “The process of changing a software system in
such a way that the extemal behavior of the design do not get changed, however the internal
structure gets improved”.
Benefits of refactoring are -
e The redundancy can be achieved.
e Inefficient algorithms can be eliminated or can be replaced by efficient one.
e Poorly constructed or inaccurate data structures can be removed or replaced.
e Other design failures can be rectified.
The decision of refactoring particular component is taken by the designer of the software
system.
ieee Justify the term : “Design is not coding and coding is not design”.
Solution : This is one of the design principles that are to be applied while designing the
software systems. This means that level of abstraction of design model should be higher than
the source code. At the time of coding, whatever design decisions are made can be
implemented. Hence design should be such that it can be transformed into source code.
Similarly, during coding it is not desired to do the design to fulfill the requirements.
ieee Discuss the statement, “Abstraction and refinement are complementary concepts.
Solution : Abstraction and refinement are complementary concepts. The major difference is
that - in the abstraction low-level details are suppressed.
Refinement helps the designer to elaborate low-level details.
Sie em Modularity is the single attribute of the software that allows a program to be
intellectually manageable” ~ How this is true ?
Solution : This is quoted by Glenford Mayers, Consider that there is a large program
composed of single module. Such a program cannot be grasped by reader. The control paths,
span of reference, number of variables and overall complexity of such a program is beyond
understanding. On the other hand if the program is divided into certain number of modules
then overall complexity of the program gets reduced. The error detection and handling can be
done effectively. Also changes made during testing and maintenance become manageable.
Hence it is true that “Modularity is the single attribute of the software that allows a program to
be intellectually manageable”.
e Information hiding implies that effective modularity can be achieved by defining a set
of independent modules that communicate with one another only that information necessary
to achieve software function.
e Using abstractions the procedural entities are defined. This is helpful for testing and
maintenance.
ecm | ustify ” A cohesive design should have high cohesiveness and low coupling”.
eRe ei GURU ceo
Solution :
%. Review Questions
What are the characteristics of a well formed design class ? SPPU : Dec.-12, Marks 6
Explain the following design concepts. i) Refinement ii) Modularity _ iii) Architecture
. What do you mean by the term cohesion and coupling in the context of software design ?
How are these concepts useful in arriving at a good design of a system ?
SPPU : Aug.-17, In Sem, Marks 3
1 . What is the relationship between modularity and functional dependence ?
ar
12. A Design should have high cohesive and low coupling. Justify.
SPPU : Dec.-18, Oct.-19, In Sem, Marks 5
13. What do you understand by refactoring ? Give importance of refactoring in improving the
quality of software. SPPU : Dec.-18, End Sem, Oct.-19, In Sem, Marks 5
Object is an important element of an Object Oriented Design (OOD). Various objects and
their interaction with each other objects is graphically represented in object oriented design.
An object is an entity which can be obtained from its belonging class and it posses attributes
and operations. The typical presentation of object oriented system is depicted by following
Fig. 4.5.1.
atS at4
opd () op4()
Fig. 4.5.1
Design classes are defined as the classes that describe some elements of problem domain,
focus on various aspects of problem from user's point of view.
The goals of design classes is :
|. To refine the analysis classes by providing the detail design, so that further implementation
can be done easily.
2... To create new set of classes for implementing the infrastructure of the software.
There are five different types of design classes
[Design classes|
3. Process Class : Process class implement lower level business abstractions used by the
business domain.
Persistent Class : These classes represent the data store such as databases which will be
retained as it is even after the execution of the software.
System Class : These classes are responsible for software management and control
functions that are used for system operation.
Each class must be well formed design class. Following are some characteristics of well
formed design classes -
¢ Complete and Efficient
A design class must be properly encapsulated with corresponding attributes and methods.
Design class must contain all those methods that are sufficient to achieve the intent of the
class.
e Primitiveness
Methods associated with one particular class must perform unique service and the class
should not provide another way to implement the same service.
e High Cohesion
A cohesive designed class must posses small, focused set of responsibilities and these
responsibilities must be associated with all the attributes of that class.
* Low Coupling
Design classes must be collaborated with manageable number of classes. If one design
class is collaborated with all other design classes then the implementation, testing and
maintenance of the system becomes complicated. The law of Demeter suggests that the
one particular design class should send messages to the methods of neighbouring design
classes only.
The Design Model and Elements SPPU : Dec.-11, May-13, 14, Marks 8
The process dimension denotes that the design model evolutes due to various software
tasks that get executed as the part of software process.
The abstract dimension represents level of details as each element of analysis model is
transformed into design equivalent.
In following Fig. 4.7.1 the dashed line shows the boundary between analysis and design
model.
» DFD «DFD
*CFD * Collaboration *CFD
* Processing diagram * Processing
narratives © State diagram narratives Analysis
* Sequence « State diagrams ee]
ls { diagram * Sequence
diagrams
dimension
Design class
realizations » Technical
subsystems interface design * Component
collaboration « Navigation design diagrams
Abstraction
Process dimension
e In both the analysis and design models the same UML diagrams are used but in analysis
model the UML diagrams are abstract and in design model these diagrams are refined and
elaborated. Moreover in design model the implementation specific details are provided.
e Along the horizontal axis various elements such as architecture element, interface element,
component level elements and deployment level elements are given. It is not necessary that
these elements have to be developed in sequential manner. First of all the preliminary
architecture design occurs then interface design and component level design occur in
parallel. The deployment level design ends up after the completions of complete design
model.
The data design represents the high level of abstraction. This data represented at data
design level is refined gradually for implementing the computer based system. The data has
great impact on the architecture of software systems. Hence structure of data is very important
factor in software design. Data appears in the form of data structures and algorithms at the
program component level. At the application level it appears as the database and at the
business level it appears as data warehouse and data mining. Thus data plays an important
role in software design.
The architectural design gives the layout for overall view of the software. Architectural
model can be built using following sources -
e Data flow models or class diagrams
e Information obtained from application domain
e Architectural patterns and styles.
Interface Design represents the detailed design of the software system. In interface design
how information flows from one component to other component of the system is depicted.
Typically there are three types of interfaces -
User interface : By this interface user interacts
with the system. For example - GUI
Fig. 4.7.2
4.7.4 Component Level Design Elements
e The component level design is more detailed design of the software system along with the
specifications. The component level design elements describe the internal details of the
component. In component level design all the local data objects, required data structures
and algorithmic — details ~— and Component
procedural details are exposed. Interface
e Fig. 4.7.3 represents that component
order makes use of another Order ----5- C)
component form.
e The order is dependent upon the Dependency
component form. These two objects relation
can be interfaced with each other. Fig. 4.7.3 Components
The deployment level design elements indicate how software functions and software
subsystems are assigned to the physical computing environment of the software product.
Mobilephone Client-PC
Web Web
browser browser
T
!
1
'
i
'
'
!
'
~—
Web [|___..-----~---
browser
For example web browsers may work in mobile phoned or they may run on client PC or
can execute on server machines.
2 Review Questions
1. Describe the design model with a neat diagram and give the trac EIaE of each oe of
design model to analysis model. SP c.-11, Marks 8
2. Whatare the deployment level design elements ?
Explain the elements of design model.
wo
4. Whatare the elements in data design ? What are the guidelines for the data design ?
SPPU : May-14, Marks 8
Components are the part of software architecture and hence they are important factors in
achieving the objectives and requirements of system to be built.
Components can communicate and collaborate with other components.
Design models can be prepared using object oriented views and conventional views.
There are four design principles that are used during the component level design. These
principles are -
1. The Open-closed Principle
This principle states that - A module or a component should be open for extension and
should be closed for modification. A designer should design a component in such a manner
that some functionalities can added to it if required but in doing so there should not be any
change in the internal design of the component itself.
The Liskov Substitution Principle
This principle states that - subclasses should be substitutable for their base classes. This
principle is proposed by Barbara Liskoy. A component that contains the base class and if
that component works properly then the same component should work properly even if the
derived class of that base class is used by the component as a substitute.
Dependency Inversion Principle
The components should be dependant on the other abstract components and not on the
concrete component, This is because if some component has to be extended then it
becomes easy to enhance it using other abstract component instead of concrete component.
The interface Segregation Principle
Many client specific interfaces are better than one general purpose interface. According to
this principle, designer should create specialized interfaces for each major category. So that
the clients can access the interfaces based on the category. If a general purpose interface is
created then multiple clients may try to access it for different operations at the same time.
®
TECHNICAL PUBLICATIONS™- An up thrust for knowledge
Software Engineering 4-22 Design Engineering
4.9.3 Cohesion
In component level design for object oriented systems, the cohesion means a class or a
component that consists of data and operations that are closely related to each other and related
to the class itself. Various types of cohesions are -
Functional : In this type of cohesion the each module performs only one component.
Layer : This type of cohesion is used in packages, components and classes. In this type of
cohesion the higher level layer access the functionalities of the lower levels but the lower
level layers do not access the functionalities of the higher level layers.
Communicational : When all the operations of the class access the same set of data then
this type of cohesion occurs.
Sequential : In this type of cohesion, the components are grouped together in such a
manner that the output of one operation is provided as input to another operation. So that
all the operations execute in some specific sequence,
Procedural : In this cohesion the procedures are invoked immediately one after the
another,
Temporal : The cohesion in which the operations specify specific behaviour is called
temporal cohesion.
Utility : The components, classes or operations are grouped together if they perform some
specific operation otherwise they are not related with each other.
4.9.4 Coupling
Coupling is a mechanism of degree to which the classes are connected to one another.
Various types of coupling are :
% Review Question
Following is a set of steps that are applied for component level design -
1. Identify all the design classes from the problem domain.
2. Identify all the design classes from the infrastructure domain.
3. Detail out all the design classes which are not the reusable components.
a. When components communicate or collaborate then represent their communication
using messages.
b. Identify interfaces for each component.
c. Define the attributes of the classes by specifying the data types and deciding the data
structures.
d. Specify all the operations by describing the processing flow within each operation.
4. Specify the databases and files and identify the classes that are involved in handling them
5. Describe the behavioural representation for the class.
6. Design the deployment diagram fro providing additional implementation.
7, Factor the component level design.
2S Review Question
These tasks can be accomplished by designing and constructing the program components
that are identical in the form to software component for conventional software.
During the content design at the component level, the focus is on two things - i) Content
objects and ii) The way the content objects are packaged for presentation to the end user.
At the component level, the content design need to focus on the characteristics of the
WebApps.
It is necessary to organize the contents in such a way that the design manipulation and
reference could be easier.
If the contents are highly dynamic, it becomes important to establish a clear structural
model that incorporates content components.
The Web contents and above mentioned functionalities are combined to create functional
architecture.
A functional architecture is a representation of the functional domain of the
WebApplications and describes the key functional components in the WebApplications and
how these components interact with each other.
Horizontal partitioning
e Horizontal partitioning defines separate branches of the modular hierarchy for each major
program function,
e Horizontal partitioning can be done by partitioning system into : Input, data transformation
(processing) and output.
e In horizontal partitioning the design making modules are at the top of the architecture.
Decision maker
|_| worker
[|
Vertical partitioning suggests the control and work should be distributed top-down in
program structure. (Refer Fig. 4.12.2).
Function 1 Function 2 Function 3
In vertical partitioning
e Define separate branches of the module hierarchy for each major function.
e Use control modules to co-ordinate communication between functions.
Horizontal partitioning can be done by Vertical partitioning suggests the control and work |
partitioning system into: input, data should be distributed top-down in program
transformation (processing), and output. structure,
—— ——
This kind of partitioning have fewer side Vertical partitioning define separate branches of
effects in change propagation or error the module hierarchy for each major function.
propagation. Hence these are easy to maintain the changes.
2. Review Questions
1. Explain software architecture as a concept of software design. SPPU : May-12, Marks 4
2. What do you mean by software architecture? Explain with suitable example.
SPPU : April-16, In Sem, Marks 4
e The architectural model or style is a pattern for creating the system architecture for given
problem. However, most of the large systems are heterogeneous and do not follow single
architectural style.
e System categories define the architectural style
1. Components : They perform a function.
For example : Database, simple computational modules, clients, servers and filters.
» Connectors : Enable communications. They define how the components
n
‘S SN, !1 Y 7
\ !
’,
s . 1 ‘
XN 1 ¢
Pipes
If the data flow degenerates into a single line of transforms, it is termed as batch
sequential.
In this architecture series of transformations are In this architecture the data store lies at the
applied to produce output data. center of the architecture and other components
frequently access it by performing add, delete,
and modify operations.
In this architecture the set of components are In data centered architecture the components
called filters and are connected by pipes to are the database elements such as tables and
transform data from one component to another. queries. And the communication among these
components takes place with the help of
relationship.
The filters normally work independently The components of this architecture perform
without bothering about working of with the central repository without affecting the
neighboring filter. working of other components.
Client Client
software software
Client Client
software “—* | Data store |“ software
eNOS
Client Client
software software
e The program structure can be easily modified or scaled. The program structure is organized
into modules within the program. In this architecture how modules call each other. The
program structure decomposes the function into control hierarchy where a main program
invokes number of program components.
e In this architecture the hierarchical control for call and return is represented.
Main
Fan out
Controller
© | sub programs
Application
sub programs
Attributes Attributes
. Messages rf
Operations 9 Operations
Attributes Attributes
Messages
Operations Operations
e The layered architecture is composed of different layers. Each layer is intended to perform
specific operations so machine instruction set can be generated. Various components in
each layer perform specific operations.
e The outer layer is responsible for performing the user interface operations while the
components in the inner layer perform operating system interfaces.
e The components in intermediate layer perform utility services and application software
functions.
User interface
layer
Application
layer
Utility
y lomponents
performing
various operations
In this section we will understand what are architectural patterns ? The architectural
pattern is basically an approach for handling behavioural characteristics of software systems.
Following are the architectural pattern domains
1. Concurrency
Concurrency means handling multiple tasks in parallel. For example in operating system,
multiple tasks are executed in parallel. Hence concurrency is a pattern which represents
that the system components can interact with each other in parallel. The benefit of this
pattern is that system efficiency can be achieved.
2. Persistence
Continuity in the data can be maintained by the persistence pattern. In other words the data
used in earlier execution can be made available further by storing it in files or in
databases. These files/databases can be modified in the software system as per the need. In
object oriented system the values of all attributes various operations that are to be
executed are persistent for further use. Thus broadly there are two patterns.
i) Database management pattern ii) Application level pattern.
3. Distribution
Distribution pattern refers to the way in which the system components communicate with
each other in distributed systems. There are two major problems that occur in distribution
pattern
e The nature of interconnection of the components
e The nature of communication
These problems can be solved by other pattern called broker pattern. The broker pattern
lies between server and client components so that the client server communication can be
established properly. When client want some service from server, it first sends message to
broker. The broker then conveys this message to server and completes the connection.
Typical example is CORBA. The CORBA is a distributed architecture in which broker
pattern is used.
Software designing
c |Requirements gathering
Abstraction Refinement
Information hiding All of the above
[a] Operations are part of single functional task and are placed in same procedures.
[b] All operations that access the same data are defined within one class.
All operations that access the data from outside the module.
Q.15 Control systems may make use of the environmental control pattem, which is a general
control pattern that includes __ ___ processes.
actuator
Q.16A view shows the system hardware and how software components are
distributed across the processors in the system.
logical
Q.17 Which view in architectural design shows the key abstractions in the system as objects or
object classes ?
[b] Development
[a] Process
Q.21 d
goog
Notes
Syllabus
Contents
5.7 Introduction to Concept of Risk management
5.2 Reactive Vs. Proactive Risk Strategies ...............2-- May-14 oo... cece Marks 6
5.7 Risk Mitigation, Monitoring and Management........ May-12, 14, Dec.-19...... Marks 10
5.8 THO-RMMM Plans -.c. Bessbsecsshascdsecsetasobtanséjnsettnncbhns May-18, Dec.-17, 18, ........... Marks 6
5.11 The SCM Process .......2...20::e0+:------ May-16, 18, 19, Dec.-18, 19........20...004 Marks 8
(5-1)
Software Engineering 5-2 Risk and Configuration Management
e Definition of risk : The risk denotes the uncertainty that may occur in the choices due to
past actions and risk is something which causes heavy losses.
e Definition of risk management : Risk management refers to the process of making
decisions based on an evaluation of the factors that threats to the business.
e Various activities that are carried out for risk management are -
1. Risk identification
2. Risk projection
3. Risk refinement
4. Risk mitigation, monitoring and management.
Reactive risk management is a risk management strategy in which when project gets into
trouble then only corrective action is taken. But when such risks can not be managed and
new risks come up one after the other, the software team flies into action in an attempt to
correct problems rapidly. These activities are called “firefighting” activities.
Resources are utilized to manage such risks. And if still the risks do not get managed then
project is in danger.
In this strategy no preventive care is taken about the risks. They are handled only on their
occurrences.
This is an older approach of risk management.
Proactive risk management strategy begins before the technical activity by considering the
probable risk.
In this strategy potential risks are identified first then their probability and impact is
analyzed. Such risks are then specified according to their priorities (i.e. high priority risks
should be managed first!). Finally the software team prepares a plan for managing these
risks.
The objective of this strategy is to avoid the risks(prevention is better than cure!!!), But it
is not possible to avoid all the risks, hence team prepares the risk management plan in such
a manner that risk controlling can done efficiently.
e This is an intelligent strategy for risk management and now a day it is used by most of the
IT industries.
[5.3
] 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.
1. Project risk
Project risks arise in the software development process then they basically affect budget,
schedule, staffing, resources, and requirements. When project risks become severe then the
total cost of project gets increased.
2. Technical risk
These risks affect quality and timeliness of the project. If technical risks become reality
then potential design implementation, interface, verification and maintenance problems
gets created, Technical risks occur when problem becomes harder to solve,
3. Business risk
When feasibility of software product is in suspect then business risks occur. Business risks
can be further categorized as
i) Market risk - When a quality software product is built but if there is no customer for
this product then it is called market risk (i.e. no market for the product).
ii) Strategic risk - When a product is built and if it is not following the company’s
business policies then such a product brings strategic risks.
iil Sales risk - When a product is built but how to sell is not clear then such a situation
brings sales risk.
iv) Management risk - When senior management or the responsible staff leaves the
organization then management risk occurs.
v) Budget risk - Losing the overall budget of the project is called budget risk.
'
Project risk
'
Technical risk
'
Business risk
Market risk
Strategic risk
Sales risk
Management risk
Budget risk
e Known risks are those risk that are identified after evaluating the project plan. These risks
can also be identified from other sources such as environment in which the product gets
developed, unrealistic dead lines, poor requirement specification and software scope. There
are two types of known risks - predictable and unpredictable risks.
0 Predictable risks are those risks that can be identified in advance based on past project
experience. For example : Experienced and skilled staff leaving in between or
improper communication with customer resulting in poor requirement specification.
© Unpredictable risks are those risks that can not be guessed earlier.
For example certain changes in Government policies may affect the business project.
3. Review Question
1. Explain various risk associated with software project. How they are managed ?
SPPU : Dec.-17, End Sem, Marks 6
Risk Identification ISPPU : May-13, 18, Dec.-13, 16, 18, 19, Marks 8
Risk identification can be defined as the efforts taken to specify threats to the project
plan. Risks identification can be done by identifying the known and predictable risks.
Normally the risk identification is done by the project manager who follows following
steps -
The set of risk components and drivers list is prepared along with their probability of
occurrence. Then their impact on the project can be analysed.
Let us understand which are the risk components and drivers.
U.S. Air force has written a guideline for risk identification which is based on
identification of risk component and risks drivers. It has suggested following types of risk
components -
1. Performance risk - It is the degree of uncertainty that the product will satisfy the
requirements
2. Cost risk - It is the degree of uncertainty that the project will maintain the budget.
3. Support risk - \t is the degree of uncertainty that the software project being developed will
be easy to correct, modify or adapt.
4. Schedule risk - \t is the degree of uncertainty that the software project will maintain the
schedule and the project will be delivered in time.
Performance
risk
Risk
components
Schedule risk
Associated with these components are the risk drivers that are used to analyse the impact
of risk. These four risk drivers are listed below
For the risk impact assessment a table is built in which impact of each risk driver on each
software component can be specified.
Negligible
{
Marginal
t
Critical
{
Catastrophic
Fig. 5.4.2
5.4.2 How to Asses Overall Project Risk ?
The best approach is to prepare a set of questions that can be answered by project
managers in order to asses the overall project risks. These questions can be
1. Will the project get proper support by the customer manager ?
2. Are the end-users committed to the software that has been produced ?
3. Is there a clear understanding of requirements ?
4. Is there an active involvement of the customer in requirement definition ?
5. Is that the expectations set for the product are realistic ?
6. Is project scope stable ?
7. Are there team members with required skills ?
8. Are project requirements stable ?
9. Does the technology used for the software is known to the developers ?
3. Review Questions
1. Explain the risk identification and assessment process for a software project
SPPU : May-13, Dec.-13, Marks 8
Fig. 5.5.1
The project planner, technical staff, project manager performs following steps to perform
following steps for risk projection -
e Establish a scale that indicates the probability of risk being real.
1. Building the risk table is the simplest and most commonly used technique adopted by
project managers in order to project the risks. The sample risk table is as given below -
Risk table
and high impact risks will be at the top of the table. And low probability and low impact
risk will be at the bottom of the table, This arrangement of the table is called first-order
prioritization.
Then the project manager goes through this first-order prioritized risk table and draws a
t
horizontal line at some point in the table. This line is called cut off line. The risks table
above the cut off line is now considered for further risk analysis.
The risk table below the cut off line is again sorted and a second-order prioritization is
>
5. The risk table above the cut-off line is having the risks with high probability and high
impact and such risks should occupy the significant amount of management time.
6. All the risks that lie above the cut off line should be managed. Using Risk mitigation,
monitoring and management plan the last column of the risk table is filled up.
Risk exposure
The risk exposure can be calculated by following formula
Thus risk exposure for each risk from risk table is calculated. The total risk exposure of all
risks helps in determining the final cost of the project.
3. Review Questions
1. How risk projection is carried out risk table ? SPPU : May-11, Marks 8
2. How tisk projection is carried out using risk table? SPPU : May-19, End Sem, Marks 5
Risk Refinement
Risk refinement is a process of specifying the risk in more detail. The risk refinement can
be represented using CTC format suggested by D.P.Gluch.
The CTC stands for condition-transition-consequence. The condition is first stated and
then based on this condition sub conditions can be derived. Then determine the effects of these
sub conditions in order to refine the risk. This refinement helps in exposing the underlying
risks. This approach makes it easier for the project manager to analyze the risk in greater
detail.
Risk mitigation
Risk mitigation means preventing the risks to occur(risk avoidance). Following are the
steps to be taken for mitigating the risks.
1. Communicate with the concerned staff to find of probable risk.
2. Find out and eliminate all those causes that can create risk before the project starts.
3. Develop a policy in an organization which will help to continue the project even though
some staff leaves the organization.
4. Everybody in the project team should be acquainted with the current development activity.
5. Maintain the corresponding documents in timely manner. This documentation should be
strictly as per the standards set by the organization.
6. Conduct timely reviews in order to speed up the work.
7. For conducting every critical activity during software development, provide the additional
staff
if required.
Risk monitoring
In risk monitoring process following things must be monitored by the project manager,
1. The approach or the behaviour of the team members as pressure of project varies.
2. The degree in which the team performs with the spirit of “team-work”.
3. The type of co-operation among the team members.
4. The types of problems that are occurring.
5. Availability of jobs within and outside the organization.
The project manager should monitor certain mitigation steps. For example.
If the current development activity is monitored continuously then everybody in the team
will get acquainted with current development activity.
The objective of risk monitoring is
1. To check whether the predicted risks really occur or not.
To ensure the steps defined to avoid the risk are applied properly or not.
Ne
3. To gather the information which can be useful for analyzing the risk.
Risk management
7 Review Questions
1. What is risk mitigation, monitoring and management (RMMM) ? Write a note on it.
[5.8
] The RMMM Plan 8, Marks 6
e The RMMM plan is a document in which all the risk analysis activities are described.
e¢ Sometimes project manager includes this document as a part of overall project plan.
e Sometimes specific RMMM plan is not created, however each risk can be described
individually using risk information sheet.
e Typical template for RMMM plan or Risk information sheet can be,
Description
<Description of risk identified>
Refinement/Context
<associated information for risk refinement>
Mitigation/Monitoring
<enter the mitigation/monitoring steps taken>
Trigger/Contingency plan
<if risk mitigation fails then the plan for handling the risk>
Status
<Running status that provides a history of what is being done for the risk and changes in the risk.
Include the date the status entry was made>
Approval Closing date
<name and signature of person approving closure>. <date>
Example In recent year, university has computerized its examination system by using
various software applications. Find out Risk involved in implementation and administration
you as software expert. Prepare RAMM Plan for the same. SPPU : Dec.-17, Marks 6
Mitigation : The computer crash result in loss of data. Due to loss of data the online
examination system can not be delivered properly. Such a system will not be acceptable by the
customer,
Monitoring : While working on building of online examination system, the staff member
should always be aware of the stability of computing environment. Any changes in stability of
environment should be recognized and taken seriously.
Mitigation : The cost associated with late delivery of online examination system is critical.
This result in rescheduling of online examination system.
Monitoring : Realistic schedule must be established for monitoring the project status.
Management : If the project cannot be delivered on time then the university can not conduct
the examination system properly. Ifit becomes apparent that the project will not be completed
on time, the only course of action available would be to request an extension to the deadline.
1. Explain RMMM plan with suitable example. [Bg May-1 8, End Sem, Marks 6
During the development of software change must be managed and controlled in order to
improve quality and reduce error.
Hence Software Configuration Management is a quality assurance activity that is applied
throughout the software process.
The origins of changes that are requested for software are -
1. New business or market positions cause the changes in the requirements. Due to which
the changes need to occur.
New stakeholders may require some changes in the existing requirements.
tN
During software development process, various roles and tasks are involved.
The goal of project manager is to ensure that the project is getting completed within given
schedule and budget. Hence project managers continuously track the progress of the
project.
The configuration managers ensures that the changes in the projects is appropriately taking
place and the testing is conducted thoroughly after the modification in the project.
The goal of software engineer is to work on the assigned module to produce efficient code
and error free code.
Finally the customer uses the product, analyze it and may request for the change or find out
the bugs.
Susan Dart identified four important elements for software configuration management
system. These elements are -
Elements of
SCM
Component Elements : It consists of collection of tools that are used for file management
system. For example - databases.
Process Elements : It consists of actions and tasks used during change management and
use of software.
Construction Elements : It is a collection of tools that automate the construction of
ua
software.
Human Elements : It consists of set of tools that are used by software team to implement
software configuration management.
5.9.3 Baselines
o A specification or product that has been formally reviewed and agreed upon, that
thereafter serves as the basis for further development, and that can be changed only
through formal change control procedures.
A baseline is a milestone in the development of software that is marked by the delivery of
one or more software configuration items and the approval of them is obtained through
formal technical review.
The baseline is the shared project database. It is an SCM task to maintain the integrity of
the set of artifacts.
The elements of a design model have been first documented and reviewed. From this design
model errors are identified and corrected. Once all parts of the model have been reviewed,
corrected and then approved, the design model becomes a baseline.
s
L277 fo
Modification Tt ee eee
pi
craneets
pace
Sy 7.:
AY
!
Software Technical Approved
task review
Project
database
Extracted
o. Data
- Program components or functions
- External data
- File structure
e For each type of item, there may be a large number of different individual items produced.
For instance there may be many documents for a software specification such as project
plan, quality plan, test plan, design documents, programs, test reports, review reports.
These SCI or items will be produced during the project, stored, retrieved, changed, stored
again, and so on.
Each configuration item must have a unique name, and a description or specification which
distinguishes it from other items of the same type.
a Review Questions
1. What are the elements that exist when an effective SCM system is implemented? Discuss
each briefly. SPPU : Dec.-17, End Sem, Marks 6
5.10.2 Features
repository are related to each other. The repository must have an ability to keep track of
these relationship and to maintain data integrity.
Requirements Tracing : If the constructed components, its designed is tracked, then
particular requirement can be traced out. The repository must have this ability to trace the
requirement from constructed components.
Configuration Management : The repository must be able to keep track of series of
configurations representing project milestones and production releases.
Audit Trails : The audit trail
nN
1. What is software SCM repository? Explain the features of tool set supporting SCM
repository. SPPU : Dec.-17, 18, End Sem, Marks 6
2. Explain the SCM repository in detail. What are the advantages of SCM repository ?
Side UC ee CeCe)
[5.11 |The SCM Process SPPU : May-16, 18, 19, Dec.-18, 19, Marks 8
The SCM process must be developed in such a way that the software team must answer the
following set of questions -
How does the software team identify the software configuration items ?
2 How does the software team control the changes in the software before and after delivering
it to the customer ?
How does the software team manage the versions of the programs in the software
package ?
How does team get ensured that the changes are made properly ?
Who is responsible for approving the changes in the software ?
The answers to these questions lead the definition of five tasks of SCM and those are -
Identification, change control, version control and configuration audit and status reporting.
The software configuration items must be separately named and identified as object.
These objects must be arranged using object oriented approach.
There are two categories of objects - basic objects and aggregate objects.
The basic object is unit of information created during requirements analysis, design,
coding or testing. For example basic object can be part of source code.
Aggregate object is a collection of basic objects and other aggregate objects. For example
SRS or data model can be aggregate object.
Each object can be uniquely identified because it has got -
1. Name : The name of the object is nothing but the collection of characters (string) or
some text. It is unique.
2. Description : For describing the object, the object description can be given. This
description contains document, program or some other description such as project
identifier or version information.
List of resources : The resources are the entities that are used for accessing,
ow
referencing and processing of objects. The data types and functionalities can serve as a
resource.
4. Realization or identification : It is pointer to object.
The configuration object identification can also consider relationships that exist between
the named objects.
If a change is made to one configuration object it is possible to determine which other
configuration objects in the repository are affected by the change.
e Basically object evolve throughout the software process. During the process of object
identification the evolution of objects along with its process must be identified.
e Major modifications in the object must be noted.
e Changes in any software projects are vital. Sometimes, introducing small changes in the
system may lead to big problems in product.
e Similarly, introducing some changes may enhance the capabilities of the system.
e According to James Bach too little changes may create some problems and too big changes
may create another problems.
e For a large software engineering project, uncontrolled change creates lot of chaos. For
managing such changes, human procedures or automated tools can be used.
e The change control process is shown by following Fig. 5.11.1 (See Fig. 5.11.1 on Next
page)
Step 1: First of all there arises a need for the change.
Step 2: The change request is then submitted by the user.
Step 3: Developers evaluate this request to assess technical merits, potential side effects, and
overall impact on system functions and cost of the project.
Step 4: A change report is then generated and presented to the Change Control Authority
(CCA).
Step 5: The change control authority is a person or a group of people who makes a final
decision on status or priority of the change.
Step 6: An Engineering Change Order (ECO) is generated when the change gets approved.
In ECO the change is described, the restrictions and criteria for review and audit are
mentioned.
Step 7: The object that needs to be changed is checked out of the project database.
Step 8: The changes are then made on the corresponding object and appropriate SQA
activities are then applied.
Step 9: The changed object is then checked in to the database and appropriate version control
is made to create new version.
The checked in and checked out mechanisms require two important elements -
e Access control
e Synchronization control
The access control mechanism gives the authority to the software engineer to access and
modify the specific configuring object. The synchronization control mechanism allows to
make parallel changes or the changes made by two different people without overwriting each
other's work.
e Version is an instance of a system which is functionally distinct in some way from other
system instances.
e Version control works to help manage different versions of configuration items during the
development process.
e The configuration management allows a user to specify the alternative configurations of the
software system by selecting appropriate version.
e Certain attributes are associated with each software version. These attributes are useful in
identifying the version. For example : The attribute can be ‘date’, ’creator’, ’customer’,
‘status’.
e In practice the version needs an associated name for easy reference.
e Different versions of a system can be shown by an evolution graph as shown in
Fig. S012;
e Each version of software system is a collection of software configuration items.
e In order to ensure that the change has been properly implemented or not two activities are
carried out.
1. Formal Technical Review (FTR)
7. Whether the SCM process (object identification, change and version control,
configuration audit and status reporting) are properly followed ?
e The above questions can be asked as a part of formal technical review.
2 Review Questions
4. Explain change control mechanism in SCM. SPPU : Dec.-19, End Sem, Marks 5
The webapps get developed in a short span of time using customer driven approach. Hence
there are four major issues that need to be handled during configuration management for web
applications. These issues are -
1. Content:
e The typical web application contains text, graphics, scripts, audio/video files, forms,
active web pages and so on.
e There is a challenge to organize these contents into configurable objects and
establish control mechanism for these objects.
2. People:
Many times the contents for web apps are developed by the people having no software
engineering background. Such people are completely unaware of need for
configuration management.
As a result changes are accommodated in the web app in an uncontrolled manner.
3. Scalability :
The web app grow significantly with interconnections with information subsystems.
As size and complexity grows the small changes are difficult to incorporate or these
changes may lead to problematic situations.
Hence as the scalability of web apps grows, the configuration control mechanism need
to be rigorously applied.
4. Politics:
e Content management is a process in which contents are organized, presented to the end user
and then displayed in client — server
" Content
environment. management
Server - side
Client
Content HTMU
Templates. management XML
system Scripts
Database
2. Management Subsystem :
e The contents prepared in content management are stored in repository.
e The management subsystem implements the repository that contains following
elements -
1. Content database : It contains the information structure used for storing the data.
2. Database capabilities : It contains functionalities used for storing and retrieving
the data objects.
3. Configuration management functions : It includes functions related to version
control, change management, change auditing and reporting.
3. Publishing subsystem :
e The publishing subsystem comes in a picture when contents are ready to present on
client browsers.
e Various elements of publishing subsystem are -
i) static elements such as text, graphics, scripts.
ii) publication services that include the functionalities related to retrieval and
formatting of the contents.
iii) external services for accessing external infrastructure.
o Class3 : This type of content change causes major influence across the web
applications.
o Class 4 : This type of content change demand for major design change.
e The class 1 and class 2 changes are informally handled using agile method. For the class 2
changes the impact study is done.
e The class 3 changes are reviewed by developers.
e The class 4 changes are reviewed by developers and stakeholders.
As the web app gets developed different versions exist at the same time. Version control is
a mechanism to manage these versions in appropriate manner.
The version control process is as follows -
Step1 : There should be some central repository for the web app project. This repository
contains current versions of all web app configurable objects.
Step 2 : Each developer creates a working folder. This folder contains current object being
created or changed.
Step 3 : The clocks on all the workstations should be synchronized.
Step 4 : The new objects are developed or existing objects are changed.
Step 5 : When objects are imported or exported from the repository, an automatic log
messages can be generated.
e All objects that are checked into or out of the repository are recorded into log. This log can
be viewed at any time.
e In addition to that, automatic e-mail notification can be sent to developers when the objects
that are checked into or out of the repository.
customer investor
project team
Q.3 The goal of quality assurance is to provide management with the data needed to
determine which software engineers are producing the most defects.
True False
Q.4 The problem that threatens the success of a project but which has not yet happened is a
albus [b | error
risk failure
Q.7 IfP is risk probability, L is loss, then Risk Exposure (RE) is computed as :
Q.9 When senior management or responsible staff leaves the organization then following type
of risk occurs ;
Q.10 When risk is associated with hardware or software technology then following type of risk
occurs
Q.11 RErepresents
[a | Risk Expense ‘elated Expense
Q.13 _ __ is the process, which controls the changes made to a system and manages the
different versions of the software project.
Q.14__ process involve technical change analysis, cost benefit analysis and change
tracking.
Baseline [b Procedure
Audit None of the above
Q.16 Which of the following task is not part of software configuration management ?
ooo
Software Testing
Syllabus
Contents
6.1 Fundamental Concepts of Testing ............+.---- May-14, 16, Dec.-19................ Marks 9
6.2 A Strategic Approach to Software Testing ...... Dec.-12, 13, 18,
dedeadessheuddedeatheoteseliepeecdle May-16, 18, 19.................+.--..
Marks 8
6.3 Organizing for Software Testing
6.4 Criteria for Completion of Testing
6.5 Strategic Issues
6.6 Testing Strategies for Conventional Software May-11, 13, 14, 16, 18
sbedssbedbe.Biveibdyeperedse Dec.-11, 12, 13, 17, 19.........:0:00+... Marks 8
6.7 Testing Strategies for Object Oriented Software .......... May-12, 13..........:0:0 Marks 6
6.8 Test Strategies for Web Apps
6.9 Validation TeSting oe eeeeseeeeceesecesteeeeeeeeeeeteeees May-19, Dec.-19...0.0.....2:ceee Marks 4
6.10 Types of Testing
6.11 White Box Testing 0... Dec.-11,12, 16, May-11,12,13,14,16............. Marks 8
6.12 Black Box Testing Marks 6
6.13 Comparison between Black Box and White Box Testing........De@C.-12............ Marks 4
6.14 Multiple Choice Questions
(6-1)
Software Engineering 6-2 Software Testing
The purpose of software testing is to ensure whether the software functions appear to be
working according to specifications and performance requirements.
Every software engineer must apply following testing principles while performing the
software testing.
1. All tests should be traceable to customer requirements.
2. Tests should be planned long before testing begins.
3. The Pareto principle can be applied to software testing - 80 % of all errors uncovered
during testing will likely be traceable to 20 % of all program modules.
4. Testing should begin “in the small” and progress toward testing “in the large”.
5. Exhaustive testing is not possible.
6. To be most effective, testing should be conducted by an independent third party.
e Generally, testing is a process that requires more efforts than any other software
engineering activity.
e Testing is a set of activities that can be planned in advance and conducted systematically.
e If it is conducted haphazardly, then only time will be wasted and more even worse errors
may get introduced.
e This may lead to have many undetected errors in the system being developed. Hence
performing testing by adopting systematic strategies is very much essential in during
development of software.
2 Review Questions
1. What is importance of testing practices ? What are the principles of testing practices ?
SPPU : May-14, Marks 8
2. What are the main objectives of software testing and what are the principles of software
testing ? SPPU : May-16, End Sem, Marks 9,Dec.-19, End Sem, Marks 5
e A testing strategy provides a process that describes for the developer, quality analysts and
the customer the steps conducted as part of testing. The testing strategy includes
oO Test planning
© Test case design
© Test execution
© Data collection
o Effectiveness evaluation.
e The strategic approach for software testing can be -
1. Just before starting the testing process the formal technical reviews must be
conducted. This will eliminate many errors before the actual testing process.
2. At the beginning, various components of the system are tested, then gradually each
interface is tested and thus the entire computer based system is tested.
3. Different testing techniques can be applied at different point of time.
4. The developer of the software conducts testing. For the large projects the
Independent Test Groups (ITG) also assist the developers.
5. Testing and debugging are different activities that must be carried out in software
testing.
6. Debugging also lies within any testing strategy.
© There are two levels specified in the testing strategy and those are low level and high level.
The low level tests that are necessary to verify that small source code segment has been
correctly implemented. Similarly the high level tests should be conducted that validate
major system functions against customer requirements.
© Software developers
© Testers (test engineers) in Independent Test Group (ITG)
e Verification refers to the set of activities that ensure that software correctly implements a
specific function.
e Validation refers to a different set of activities that ensure that the software that has been
built is traceable to customer requirements.
e According to Boehm
¢ Quality must be built into the development process, you can't use testing to add quality after
the fact.
e Verification and validation involve large number of software quality assurance activities
such as -
Performance monitoring
Feasibility study
O
Documentation review
0-0
Database review
Algorithmic analysis
0-0
Development testing
Installation testing
0
F Verification refers to the set of activities Validation refers to the set of activities
that ensure software correctly implements that ensure that the software that has been
the specific function. built is traceable to customer
requirements.
2. After a valid and complete specification Validation begins as soon as project starts.
the verification starts.
——— = —— 1
oF Verification is for prevention of errors. Validation is for detection of errors.
a3 Verification is also termed as white box Validation can be termed as black box
testing or static testing as work product testing or dynamic testing as work product
goes through reviews. is executed.
7. Verification is based on the opinion of Validation is based on the fact and is often
reviewer and may change from person to stable.
| person.
8. The verification verifies the problem The validation validates the requirements,
statements, decisions taken during the functionalities and features of the product. }
! development and execution paths.
7 Review Questions
2. What is software testing ? Explain the software testing strategy for software development.
SPPU : Dec.-13,18, May-19, Marks 8
e Testing needs to be conducted from the beginning of the software development process.
e It is desired that the software developer should test the individual unit of software system
for its proper functioning. This is called unit testing. That means, there must be an
involvement of software developers for unit testing activities.
e In many cases, the software developers also perform the integration testing. Thus the
complete software architecture is been tested by the software developers during
development phases.
e Then the independent test group(ITG) gets involved in the software testing activity.
e The role of ITG is to remove other inherent problems and conflicts associated with the
software system.
e The software developers and the ITG work together to remove all possible errors from the
software system and a thorough testing must be performed.
e While testing is conducted, the developer must be available to correct errors that are
uncovered.
e The ITG is part of the software development project team in the sense that it becomes
involvedduring analysis and design and stays involved throughout a large project.
e In many cases, the ITG reports to software quality assurance organization so that the
independent testing can be performed.
Entry criteria
e Software testing should start early in the Software Development Life Cycle. This helps to
capture and eliminate defects in the early stages of SDLC i.e requirement gathering and
design phases.
e An early start to testing helps to reduce the number of defects and ultimately the rework
cost in the end.
e Definition : Entry criteria for testing can be defined as “Specific conditions or on-going
activities that must be present before a process can begin.” The Software Testing Life Cycle
(STLC) specifies the entry criteria required during each testing phase.
e It also defines the time interval or the expected amount of lead-time to make the entry
criteria item available to the process.
e Following are the inputs necessary for the entry criteria —
o The requirements documents
Exit criteria
e Definition : It can be defined as “The specific conditions or on-going activities that should
be fulfilled before completing the software testing life cycle.”
e The following exit criteria should be considered for completion of a testing phase:
o Ensuring all critical Test Cases are passed
Strategic Issues
¢ Before the testing starts, Specify product requirements appropriately - Certain quality
characteristics of the software such as maintainability, portability and usability should be
specified in order to obtain the unambiguous test results.
e Specify testing objectives clearly - Testing objectives such as effectiveness, mean time to
failure and cost of defects should be stated clearly in the test plan.
© Identify categories of users for the software and their role with reference to software
system - Use cases describe the interactions among different class of users and thereby
testing can focus on the actual use of the product.
© Develop a test plan that emphasizes rapid cycle testing - Test plan is an important
document which helps the tester to perform rapid cycle testing (2 percent of project effort).
© Build robust software which can be useful for testing - The software should be capable of
detecting certain classes of errors. Moreover, the software design should allow automated
testing and regression testing.
e Use effective formal reviews before actual testing process begins - Formal technical
reviews need to be conducted to uncover errors. The effective technical reviews conducted
before testing, reduce significant amount of testing efforts.
© Conduct formal technical reviews to assess the test strategy and test cases - The formal
technical review helps to detect any the lacuna in testing approach. Hence it is necessary to
assess the test strategy and test cases by technical reviewers to improve the quality of
software.
e Throughout the testing process adopt the continuous development strategy - The
measured test strategy should be used as part of statistical process control approach for
software testing.
1. Unit testing - In this type of testing techniques are applied to detect the errors from
each software component individually.
2. Integration testing - It focuses on issues associated with verification and program
construction as components begin interacting with one another.
3. Validation testing - It provides assurance that the software validation criteria
(established during requirements analysis) meets all functional, behavioural and
performance requirements.
4. System testing - In system testing all system elements forming the system is tested as
a whole.
Testing Software
strategies development stages
: V
System
testing System engineering
Validation
testing
Integration
testing
In unit testing the individual components are tested independently to ensure their quality.
e The focus is to uncover the errors in design and implementation.
e The various tests that are conducted during the unit test are described as below.
1 Module interfaces are tested for proper information flow in and out of the program.
Local data are examined to ensure that integrity is maintained.
N
Boundary conditions are tested to ensure that the module operates properly at
boundaries established to limit or restrict processing.
All the basis (independent) paths are tested for ensuring that all statements in the
module have been executed only once.
Things to be tested
Source program
AGT // *Interfaces a
odule : ¢ Local data \ ‘
_+I to be He ttichines \ Generating
Various tested (* Boundary condition |
modules We i
in program Independent path /
J \¢ Error handling paths’
be Test
eee cases
6. Drivers and stub software need to be developed to test incomplete software. The
“driver” is a program that accepts the test data and prints the relevant results. And the
“stub” is a subprogram that uses the module interfaces and performs the minimal data
manipulation if required. This is illustrated by following Fig. 6.6.3.
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.
Stubs and drivers are two such elements used in software testing process, which act as a
temporary replacement for a module.
The driver and stubs are generally dummy
codes or fake codes that help to simulate the
behavior of existing code. Module under unit
testing
The stubs and drives are specifically
developed to meet the necessary
requirements of the unavailable modules and
are useful in getting expected results. 5 [stub 2] [stub 3] Stub 4]
e A group of dependent components are tested together to ensure their quality of their
integration unit.
The objective is to take unit tested components and build a program structure that has been
dictated by software design.
The focus of integration testing is to uncover errors in :
= Design and construction of software architecture.
= Integrated functions or operations at subsystem level.
= Interfaces and interactions between them.
= Resource integration and/or environment integration.
Regression testing
Smoke testing
Fig. 6.6.5 Integration testing approach
e The non-incremental integration is given by the “big bang” approach. All components are
combined in advance. The entire program is tested as a whole. And chaos usually results. A
set of errors is tested as a whole. Correction is difficult because isolation of causes is
complicated by the size of the entire program. Once these errors are corrected new ones
appear. This process continues infinitely.
Regression testing
Smoke testing
For example :
In top down integration if the depth first approach is adopted then we will start integration
from module M1 then we will integrate M2 then M3, M4, MS, M6 and then M7.
If breadth first approach is adopted then we will integrate module M1 first then M2, M6.
Then we will integrate module M3, M4, MS and finally M7.
For example :
—
Cluster 1
Cluster2
First components are collected together to form cluster | and cluster 2. Then each cluster is
tested using a driver program. The clusters subordinate the driver module. After testing the
driver is removed and clusters are directly interfaced to the modules.
e Regression testing is used to check for defects propagated to other modules by changes
made to existing program. Thus regression testing is used to reduce the side effects of the
changes.
e There are three different classes of test cases involved in regression testing -
© Representative sample of existing test cases is used to exercise all software functions.
© Additional test cases focusing software functions likely to be affected by the change.
© Tests cases that focus on the changed software components.
e After product had been deployed, regression testing would be necessary because after a
change has been made to the product an error that can be discovered and it should be
corrected. Similarly for deployed product addition of new feature may be requested and
implemented. For that reason regression testing is essential.
The smoke testing is a kind of integration testing technique used for time critical projects
wherein the project needs to be assessed on frequent basis.
Following activities need to be carried out in smoke testing -
1. Software components already translated into code are integrated into a “build”. The
“build” can be data files, libraries, reusable modules or program components.
2. A series of tests are designed to expose errors from build so that the “build” performs
its functioning correctly.
3. The “build” is integrated with the other builds and the entire product is smoke tested
daily.
The system test is a series of tests conducted to fully the computer based system.
Various types of system tests are :
Recovery testing
Ae, o
Security testing
Stress testing
Performance testing
The main focus of such testing is to test
System functions and performance.
System reliability and recoverability (recovery test).
System installation (installation test).
Recovery testing is intended to check the system’s ability to recover from failures.
In this type of testing the software is forced to fail and then it is verified whether the system
recovers properly or not.
For automated recovery then reinitialization, checkpoint mechanisms, data recovery and
restart are verified.
Security testing verifies that system protection mechanism prevent improper penetration or
data alteration.
It also verifies that protection mechanisms built into the system prevent intrusion such as
unauthorized internal or external access or willful damage.
System design goal is to make the penetration attempt more costly than the value of the
information that will be obtained.
Performance testing evaluates the run time performance of the software, especially real
time software.
In performance testing resource utilization such as CPU load, throughput, response time,
memory usage can be measured.
For big systems (e.g. banking systems) involving many users connecting to servers (e.g.
using internet) performance testing is very difficult.
Beta testing is useful for performance testing.
7% Review Questions
Explain in detail :
. What do you understand by system testing ? What are the different kinds of system testing
that are usually performed on large software testing. [QQgOR eS VAR mvc cms
. What is software testing ? Explain the software testing strategies for software development.
SPPU : May-18, End Sem, Marks 7
14. What do you understand by integration testing ? Explain the objectives of integration
testing SPPU : May-16, Dec.-19, End Sem, Marks 6
e The primary objective of testing for object oriented software is to uncover as much errors
as possible with manageable amount of efforts in realistic time span.
e The object oriented testing strategy is identical to conventional testing strategy. The
strategy is start testing in small and work outward to testing in large. The basic unit of
testing is class that contains attributes and operations. These classes integrate to form
object oriented architecture. These are called collaborating classes.
and for testing whole group of classes. The stub can be used in the situations in which
collaborations of the classes is required and one collaborating class is not fully
implemented.
e The cluster testing is one step in integration testing in OO context. In this step all the
collaborating classes are tested in order to uncover the errors.
e The testing strategies applied to conventional software are based on unit testing,
integration testing, validation testing and system testing. But in object oriented testing,
the unit testing loses some of its meaning and integration testing changes significantly.
e The object oriented testing strategy is also based on the principle - "test in small" and then
work "in the large".
1. Testing in the small involves class attributes and operations; the main focus is on
communication and collaboration within the elass.
2. Testing in the large involves a series of regression tests to uncover errors due to
communication and collaboration among classes
Finally, the system as a whole is tested to detect errors in fulfilling requirements
e The integrated software is tested based on requirements to ensure that the desired product is
obtained.
e In validation testing the main focus is to uncover errors in
System input/output
System functions and information data
- System interfaces with external parts
User interfaces
System behaviour and performance
e Software validation can be performed through a series of black box tests.
e After performing the validation tests there exists two conditions.
1. The function or performance characteristics are according to the specifications and
are accepted.
The requirement specifications are derived and the deficiency list is created. The
No
deficiencies then can be resolved by establishing the proper communication with the
customer.
e Finally in validation testing a review is taken to ensure that all the elements of software
configuration are developed as per requirements. This review is called configuration review
or audit.
The acceptance testing is a kind of testing conducted to ensure that the software works
correctly in the user work environment.
The acceptance testing can be conducted over a period of weeks or months.
The types of acceptance testing are :
1. Alpha test - The alpha testing is a testing in which the version of complete software is
tested by the customer under the supervision of developer. This testing is performed at
developer’s site. The software is used in natural setting in presence of developer. This test
is conducted in controlled environment.
2. Beta test - The beta testing is a testing in which the version of software is tested by the
customer without the developer being present. This testing is performed at customer’s site.
As there is no presence of developer during testing, it is not controlled by developer. The
end user records the problems and report them to developer. The developer then makes
appropriate modification.
6 Less time consuming as developer can More time consuming. As user has to
make necessary changes in giventime. —_ report bugs if any via appropriate channel.
Validation is a technique, to evaluate whether the final built software product fulfils the
customer requirements.
A test plan is created that contains the classes of tests to be conducted and test procedure
defines the specific tests to be conducted.
After each validation testing one of the two possible conditions exists:
1) The function or performance characteristics conforms to specification and is accepted.
or
2) A deviation from specification is represented. In other words the list of requirements
that does not get fulfilled by the system is represented.
% Review Question
Types of Testing
In this method the procedural design using basis set of execution path is tested. This basis
set ensures that every execution path will be tested at least once.
Path testing is a structural testing strategy. This method is intended to exercise every
independent execution path ofa program atleast once.
Following are the steps that are carried out while performing path testing.
Step 1 : Design the flow graph for the program or a component.
Step 2 : Calculate the cyclomatic complexity.
Step 3 : Select a basis set of path.
Step 4 : Generate test cases for these paths.
Let us discuss each in detail.
Statement 1
Sequence
Statement 2
qT if
ue false
Tf- else
while
True
Fess While
Case
Fig. 6.11.1
For example : Following program is for searching a number using binary search method.
Draw a flow graph for the same.
int mid;
1) int bottom = 0;
2) int top
= n-1;
3) while (bottom <=top)
4) { mid = (top + bottom) / 2;
5) if (a [mid] = = key)
{
6) printf ("Element is present");
7) return;
} // end of if
else
{
8) if (a [mid] < key)
9) bottom = mid + 1;
else
10) top = mid-1;
} // end of else
} // end of while
11) }// end of search
regions
Fig. 6.11.2
After computing cyclomatic complexity and finding independent basis paths, the test cases
has to be executed for these paths. The format for test case is -
Preconditions :
Test Test case Test case Test steps Test case status Test Defect
Test Test case Test case Test steps Test Test Test Defect
case id name description case status priority severity
status (P/F)
Step Expected Actu
al
Validating Checking Set bottom _ Initially
the list the =0top=n_ bottom Design
boundary bottom 1 check < = top
and top ifbottom< will be
values for = top by true. But
the list of while loop. during
elements —_ This iterations
condition list's
defines the length
length of will be
the list reduced
from and if
which the entire list
key is gets
searched. scanned
at one
point
(bottom >
ve top)
will be
reached
then
return to
main.
Checking Checking Set mid = If a[{mid]
list if middle (top + = key Design
element element bottom)/2 value then
with key. of array is Then print
equal to compare if message
key value a[mid] is "Element
equal to is
key. present"
and return
to main.
if a[mid] Set bottom The right
is < key = mid +1 sublist Design
value if and then will be
a[mid] is goto searched.
> key "while" set The left
value top = mid sublist
+1 and go will be
back to searched
"while" for key
loop element
Solution :
The flow graph for given program is - (From Fig. 6.11.3)
Predicate
node
node
Definition : Graph matrix is a square matrix whose size is equal to number of nodes of the
flow graph.
For example consider a flow graph -
The graph matrix will be
For computing the cyclomatic complexity. Following steps are adopted -
Step 1 : Create a graph matrix. Mark the corresponding entry as | if node A is connected to
node B.
Step 2: Count total number of 1's from each row and subtract | from each corresponding row.
t F
1 2 3 4 5 6
2-1-1
a
1-1=0
on
{=i =o
2-121
Oar
1-1=0
2+1=3
the results of each row and add | to it. The resultant value is the cyclomatic complexity.
Loop testing is a white box testing technique which is used to test the loop constructs.
Basically there are four types of loops.
1. Simple loops:
The tests can be performed for n number of classes.
where
i) n=O that means skip the loop completely.
ii) n= 1 that means one pass through the loop is tested.
iii) n= 2 that means two passes through the loop is tested.
iv) n=m that means testing is done when there are m passes where m <n.
v) Perform the testing when number of passes are n— 1, n,n + 1.
2. Nested loops :
The nested loop can be tested as follows.
i) Testing begins from the innermost loop first. At the same
time set all the other loops to minimum values.
ii) The simple loop test for innermost loop is done.
iii) Conduct the loop testing for the next loop by keeping the
outer loops at minimum values and other nested loops at
some specified value.
iv) This testing process is continued until all the loops have
been tested.
4. Unstructured loops:
The testing cannot be effectively conducted for unstructured loops. Hence these types of
loops needs to be redesigned. (Refer Fig. 6.11.8)
%. Review Questions
1. Explain the following : i) Condition testing ii) Loop testing. SPPU : May-11, Marks 8
2. What is basis path testing ? What is cyclomatic complexity ? How is it determined for a
flow graph ? Illustrate with an example. SPPU : May-12, Marks 8
3. Basis path testing covers all statements in a program module. Justify with example.
SPPU : Dec.-12, Marks 8
4. Explain the graph matrix and loop testing methods. SPPU : May-13, Marks 8
5. What is cyclomatic complexity ? How is it determined for a flow graph ? Illustrate with
example.
SPPU : May-14, Marks 8
6. What do you mean by white box testing ? SPPU : Dec.-16, End Sem, Marks 7
e It isa black box technique that divides the input domain into classes of data. From this data
test cases can be derived.
e An ideal test case uncovers a class of errors that might require many arbitrary test cases to
be executed before a general error is observed.
e In equivalence partitioning the equivalence classes are evaluated for given input condition.
Equivalence class represents a set of valid or invalid states for input conditions.
e Equivalence class guidelines can be as given below :
= If input condition specifies a range, one valid and two invalid equivalence classes are
defined.
Input set
oo o0°0
oo °°
° 0°
Valid input Invalid input
° °°
a f°
Output generated
Fig. 6.12.1
If an input condition requires a specific value, one valid and two invalid equivalence
classes are defined.
If an input condition specifies a member of a set, one valid and one invalid
equivalence class is defined.
If an input condition is Boolean, one valid and one invalid equivalence class is
defined.
For example :
Area code : Input condition, Boolean - The area code may or may not be present.
Input condition, range - Value defined between 200 and 700.
Password : Input condition, Boolean - A password may or may not be present.
Input condition, value - Seven character string.
Command : Input condition, set - Containing commands noted before.
with minimum and maximum values as well as with the values that are just above and
below the maximum and minimum should be tested.
If the output condition specified the range bounded by values x and y, then test cases
should be designed with values x and y. Also test cases should be with the values
above and below x and y.
If output condition specifies the number of values then the test cases should be
designed with minimum and maximum values as well as with the values that are just
above and below the maximum and minimum should be tested.
5. Ifthe internal program data structures specify such boundaries then the test cases must
be designed such that the values at the boundaries of data structure can be tested.
For example :
Integer D with input condition [-— 2, 10],
Test values :—2, 10, 11,—1,0
If input condition specifies a number values, test cases should developed to exercise the
minimum and maximum numbers. Values just above and below this min and max should be
tested.
Enumerate data E with input condition : {2, 7, 100, 102}
e Inthe graph based testing, a graph of objects present in the system is created.
e The graph is basically a collection of nodes and links. Each node represents the object that
is participating in the software system and links represent the relationship among these
objects.
e The node weight represents the properties of object and link weight represents the
properties or characteristics of the relationship of the objects.
e After creating the graph, important objects and their relationships are tested.]
Node
weight
Undirected
link Parallel
links
e Orthogonal array testing is a kind of testing method which can be applied to the
applications in which input domain is relatively small but there could be large number of
test cases.
e Using orthogonal array testing method, only faulty regions can be tested and thus the
number of test cases can be reduced.
e Orthogonal arrays are two dimensional arrays of numbers which possess the interesting
quality that by choosing any two columns in the array you receive an even distribution of
all the pair-wise combinations of values in the array.
e Following are some important terminologies used in orthogonal testing methods -
Runs
It denotes the number of rows in the array. These can be directly translated to the test
cases.
Factors
It denotes the number of columns in the array. These can be directly translated to
maximum number of variables that can be handled by the array.
Level
This number denotes the maximum number of values that a single factor(column) can take.
L9 orthogonal array
This array is used to generate the test cases. This array has a balancing property. That
means the testing can be done uniformly by executing the test cases generated by the L9
orthogonal array.
Example
Consider that we want to develop an application which has three sections - top, bottom
and middle.
e Associated with each section we will consider one variable. That means now we have to
analyse only three variables.
e These variables can be assigned with Boolean values and hence the values can be true or
false.
If we decide to test it completely then there would be 2° = 8 test cases
e By orthogonal array testing method, mapping the values to L9 orthogonal array would be -
Advantage
The orthogonal array testing approach enable the developer to provide good test coverage
with very few test cases.
2 Review Question
Black box testing is called behavioural | White box testing is called glass box testing.
testing.
Black box testing examines some In white box testing the procedural details, all
fundamental aspect of the system with _ the logical paths, all the internal data structures
little regard for internal logical are closely examined.
structure of the software.
Ds During black box testing the program White box testing lead to test the program
cannot be tested 100 percent. thoroughly.
4. This type of testing is suitable for large This type of testing is suitable for small projects.
projects.
Advantages :
1. The black box testing focuses on fundamental aspect of system without being concerned
for internal logical structure of the software.
2. The advantage of conducting black box testing is to uncover following types of errors.
i. Incorrect or missing functions
ii. Interface errors
iii. Errors in external data structures
iv. Performance errors
v. Initialization or termination errors
Disadvantages :
1. All the independent paths within a module cannot be tested.
2. Logical decisions along with their true and false sides cannot be tested.
3. All the loops and the boundaries of these loops cannot be exercised with black box testing.
4. Due to knowledge of internal coding structure it is easy to find out which type of input data
can help in testing the application efficiently.
Disadvantages :
The knowledge of internal structure and coding is desired for the tested. Thus the skilled
tester is required for whitebox testing. Due to this the testing cost is increased.
2. Sometimes it is difficult to test each and every path of the software and hence many paths
may go untested.
3. Maintaining the white box testing is very difficult because it may use specialized tools like
code analyzer and debugging tools are required.
wa Review Question
1. Differentiate between white box and black box testing. SPPU : Dec.-12, Marks 4
users developers
the faults have been fixed [b] all the tests run
[c | the time completed the risk are resolved
defects
Q.6 Test cases are designed during which of the following stages ?
Test recording [b] Test configuration
Q.10 Testing of software with actual data and in actual environment is known as A
regression testing beta testing
OoOW
Notes
Q.1 (a) What is software engineering ? What are the characteristics of software ?
(Refer section 1.5) [4]
(b) What is meant by ‘blocking states’ in linear sequential model ?
(Refer example 1.13.2) [3]
(c) Explain with neat diagram incremental model and state its advantages and
disadvantages. (Refer section 1.14.2) [8]
OR
Q.2 (a) Elaborate how software engineering is a layered technology.
(b) Write an use case for ‘login’ with a template and diagram. (Refer example 2.5.2)[4]
(c) What are requirements engineering tasks ? Explain in detail. (Refer section 2.2) [8]
OR
Q.4 (a) Explain the tasks done during elicitation and requirement management.
(c) Create the swimlane diagram for, monitoring of sensor in a ‘Safehome security
system’ from control panel. (Refer example 2.8.5) [7]
(M - 1)
SOLVED MODEL QUESTION PAPER (End Sem)
Software Engineering
S.E.(Computer) Semester - IV (As per 2019 Pattern)
1
Time :2 2 Hours] [Maximum Marks : 70
Instructions :
1. Attempt Q.1 or Q.2, Q.3 or Q.4, 0.5 or Q.6, O.7 or Q.8.
2. Make suitable assumptions wherever necessary.
3. Figures to the right indicate full marks.
4. Neat diagrams must be drawn wherever necessary.
Q.1 (a) What is the need for defining a software scope ? What are the categories of software
engineering resources. (Refer section 3.2) [8]
(b) Explain the FP based estimation technique. (Refer section 3.5) [10]
OR
Q.2 (a) Explain COCOMO model for project estimation with suitable example.
(Refer section 3.6) [10]
(b) What is project scheduling ? What are the basic principles of project scheduling.
(Refer section 3.8) [8]
Q.3 (a) Explain design within the context of software engineering. (Refer section 4.1.1) [5]
(b) Explain different design concepts. (Refer section 4.4) [12]
OR
Q.4 (a) What are the deployment level design elements ? (Refer section 4.7) [3]
(b) Explain data centered and layered architectures with neat diagrams.
(Refer section 4.13) [8]
(c) Explain the types of design classes. (Refer section 4.6) [6]
Q.5 (a) Write short note on - RMMM. (Refer section 5.7) [4]
(b) Explain the risk identification and assessment process for a software project.
(Refer section 5.4) [8]
(c) What are the types of risks ? Explain in brief. (Refer section 5.2) [6]
(M - 2)
Software Engineering M-3 Solved Model Question Papers
OR
Qé (a) What do you understand by Software Configuration Management (SCM) ? Discuss
the importance of SCM. (Refer section 5.9) [8]
(b) Explain change control mechanism in SCM. (Refer section 5.11) [6]
(c) How risk projection is carried out using risk table ? (Refer section 5.5) [4]
Q7 (a) What is importance of testing practices ? What are the principles of testing practices.
(Refer section 6.1) [6]
(c) Differentiate between verification and validation. (Refer section 6.2) [5]
OR
Qs (a) Differentiate between alpha testing and beta testing. (Refer section 6.9) [6]
(b) Explain testing strategies for object oriented software. (Refer section 6.7) [8]
(c) What is entry and exit criteria for completion of testing. (Refer section 6.4) [3]
Ooo