EASWARI ENGINEERING COLLEGE CHENNAI 600 089

M.C.A. (MASTER OF COMPUTER APPLICATIONS)

SEMESTER III
MC9233 SOFTWARE ENGINEERING
L T P C
3 0 0 3
UNIT I INTRODUCTION 9
Software Engineering paradigms Waterfall Life cycle model Spiral Model
Prototype Model fourth Generation Techniques Planning Cost Estimation
rgani!ation Structure Software Pro"ect Scheduling# $is% analysis and management
$equirements and Specification $apid Prototyping&
UNIT II SOFTWARE DESIGN 9
'(straction Modularity Software 'rchitecture Cohesion Coupling )arious
*esign Concepts and notations $eal time and *istri(uted System *esign
*ocumentation *ataflow riented design +ac%son System de,elopment *esigning
for reuse Programming standards&
UNIT III SOFTWARE METRICS 9
Scope Classification of metrics Measuring Process and Product attri(utes *irect
and -ndirect measures $elia(ility Software .uality 'ssurance Standards&
UNIT IV SOFTWARE TESTING AND MAINTENANCE 9
Software Testing /undamentals Software testing strategies 0lac% 0o1 Testing
White 0o1 Testing System Testing Testing Tools Test Case Management
Software Maintenance rgani!ation Maintenance $eport Types of Maintenance&
UNIT V SOFTWARE CONFIGURATION MANAGEMENT (SCM) & CASE
TOOLS 9
2eed for SCM )ersion Control SCM process Software Configuration -tems
Ta1onomy Case $epository /eatures&
TOTAL !"
REFERENCES#
3& $oger S& Pressman# 4Software Engineering5 ' Practitioner 'pproach6# Si1th
edition# McGraw7ill# 899:&
8& -& Summer,ille# 4Software Engineering6# Si1th Edition# 'ddison Wesley;Longman#
899<&
=& Pan%a" +alote# 4'n -ntegrated approach to Software Engineering6# Second
Edition# Springer )erlag# 3>>?&
MC9233 SOFTWARE ENGINEERING
UNIT I
Software
Software is 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 range of different
customers
2. Custom That means developed for a single customer according to
their specification.
Software Engineering
Software engineering is a discipline in which theories, methods and tools are
applied to develop professional software product.
n software engineering the systematic and organi!ed approach is adopted.
"ased on the nature of the problem and development constraints various
tools and techni#ues are applied in order to develop #uality software.
The definition of software engineering is based on two terms$
1. %iscipline$ &or finding the solution to the problem an engineer applies
appropriate theories, methods and tools. 'hile finding the solutions,
engineers must thin( of the organi!ational and financial constraints.
'ithin these constraints only one has to find the solution.
2. )roduct$ The software products gets developed after following
systematic theories, methods and tools along with the appropriate
management activities.
Software Proce
The software process can be defined as the set of activities that has to be
carried out in order to get the software product.
2
Software )rocess *ctivities$
1. Software Specification$ This is generally a document in which
customer and the software developer define the purpose and use of
the software product that is to be developed in this specification, it
is necessary to specify various constraints on operation of the
software.
2. Software %evelopment$ t is a core process in which the re#uired
software is built.
+. Software ,alidation$ *fter developing the software product it is
necessary to chec( the software in order to validate it.
-. Software .volution$ Sometimes there are ma/or changes on
organi!ational or technological front and in such a situation the
e0isting software product needs to be changes. Sometimes due to
mar(et demands the software has to be modified.
Software Proce Mo!e"
The software process model can be defined as an abstract representation of
process. The software process model consists of various process activities,
role of people involved in process development and software product.
Attri#$te of Goo! Software
1. 1ser Satisfaction$ Satisfying the user re#uirements is the ultimate
goal of good software.
2. 2aintainability$ Sometimes there is a need to ma(e some
modifications in the e0isting software. Good software is software
which can be easily modified in order to meet the changing needs of
the customer.
+. 1sability$ t is the ability of the software being useful. &or ma(ing
the software useful it is necessary that it should have proper G1 and
documentation.
-. %ependability$ The dependability is a property that includes
reliability, security and safety of software. n other words, the
developed software product should be reliable and safe to use, it
should not cause any damage or destruction.
3. .fficiency. The software should be efficient in its performance and
it should have the optimal use of memory.
3
Goa"%O#&ecti'e of Software Engineering
'hile developing software following are common ob/ectives$
1. Satisfy 1ser 4e#uirements 5 2any programmers simply don6t do what
the end user wants because they do not understand user
re#uirements. 7ence it becomes necessary to understand the demand
of end user and accordingly software should be developed.
2. 7igh 4eliability 2ista(es or bugs in a program can be e0pensive in
terms of human lives, money, and customer relation. &or instance
2icrosoft has faced many problems because earlier release of
'indows has many problems. Thus software should be delivered only
if high reliability is achieved.
+. 8ow 2aintenance Costs 2aintenance of software is an activity that
can be done only after delivering the software to the customer. *ny
small change in software should not cause restructuring of whole
software. This indicates that the design of software has poor #uality.
-. %elivery on Time 5 t is very difficult to predict the e0act time on
which the software can be completed. "ut a systematic development
of software can lead to meet the given deadline.
3. 8ow )roduction Costs The software product should be cost
effective.
9. 7igh )erformance The high performance software are e0pected to
achieve optimi!ation in speed and memory usage.
:. .ase of 4euse 1se same software in different systems and
software.
.nvironments reduce development costs and also improve the reliability.
7ence reusability of developed software is an important property.
Software C(aracteritic
Software development is a logical activity and therefore it is important to
understand basic characteristics of software. Some important
characteristics of software are$
1. Software is engineered, not manufactured
2. Software does not wear out
+. 2ost software is custom built rather than being assembled from
components.
4
1. Software is engineered, not manufactured Software development
and hardware manufacturing are two different activities. * good
design is a bac(bone for both the activities. ;uality problems that
occur in hardware manufacturing phase cannot be removed easily. <n
the other hand, during software development process such problems
can be rectified. n both the activities, developers are responsible
for producing #ualitative product.
2. Software does not wear out n early stage of hardware development
process the failure rate is very high because of manufacturing
defects. "ut after correcting such defects the failure rate gets
reduced. The failure rate remains constant for some period of time
and again it starts increasing because of environmental maladies
=e0treme temperature, dusts and vibrations>.
<n the other hand software does not get affected from such
environmental maladies. 7ence ideally it should have an ?ideali!ed curve6. "ut
due to some undiscovered errors the failure rate is high and drops down as
soon as the errors get corrected. 7ence in failure rating of software the
?actual curve6 is as shown below$
5
%uring the life of software if any change is made, some defects may
get introduced. This causes failure rate to be high. "efore the curve can
return to original steady state another change is re#uested and again the
failure rate becomes high. Thus the failure curve loo(s li(e a spi(e. Thus
fre#uent changes in software cause it to deteriorate.
*nother issue with software is that there are no spare parts for
software. f hardware component wears out it can be replaced by another
component but it is not possible in case of software. Therefore software
maintenance is more difficult than the hardware maintenance.
+. 2ost software is custom built rather than being assembled from
components.
'hile developing any hardware product at first the circuit design with
desired functioning properties is created. Then re#uired hardware
components such as Cs, capacitors, and registers are assembled according
to the design, but this is not done while developing software product. 2ost
of the software is custom built.
7owever, now the software development approach is getting changed
and we loo( for reusability of software components. t is practiced to reuse
algorithms and data structures. Today software industry is trying to ma(e
library of reusable components. &or e0ample$ in today6s software, G1 is
built using the reusable components such as message windows, pull down
menus and many more such components. The approach is getting developed
to use in5built components in the software. This stream of software is
popularly (nown as component engineering.
)in! of Software
System software, 4eal5time software, "usiness software, .ngineering and
Scientific software, embedded software, )ersonal Computer software, and
*rtificial ntelligence software
6
Software Engineering Para!ig*
Software .ngineering )aradigm or )rocess 2odel is an abstract
representation of a process.
The process model is chosen based on nature of software pro/ect and
application and then to obtain deliverable product method and tools are
applied.
1sing problem solving loop the software development can be done.
The e0isting status represents current state of affairs. n the problem
identification phase particular problem is identified. The technical
development stage is for solving the identified problem using an appropriate
technology. &inally solution integration is responsible for delivering the
results.
"ut applying such problem solving loop in software development process is
very difficult because we cannot strictly categori!e the development in
these phases. There may be a re#uirement of cross tal( within and across
stages. 7ence some software process models are suggested depending upon
nature of software. Such models are called generic software models.
7
Generic software process models are
1. The 'aterfall 2odel Separate and distinct phases of specification
and development
2. )rototyping 2ode * #uic( design approach is adopted
+. ncremental 2odels t emphasi!es on short development cycle
4apid *pplication and %evelopment =4*%> 2odel
-. .volutionary )rocess 2odels Specification, development and
validation are interleaved
ncremental 2odel
Spiral 2odel
'in5'in Spiral 2odel
Concurrent %evelopment
+ife C,c"e Mo!e"
* 8ife Cycle is a se#uence in which a pro/ect specified, prototypes, designs,
implements, tests, and maintains a piece of software. n software
engineering, the life cycle model depicts various stages of software
development process. 1sing life cycle model various development issues can
be solved at the appropriate time.
Waterfa"" Mo!e"
The 'aterfall model is also called as ?8inear5se#uential model6 or ?Classic life
cycle model6. t is the oldest software paradigm. This model suggests a
systematic, se#uential approach to software development.
The software development starts with re#uirements gathering phase. t
then progresses through analysis, design, coding, testing and maintenance.
n re#uirement gathering and analysis phase the basic re#uirements of the
system must be understood by software engineer, who is also called *nalyst.
The information domain, function, behavioural re#uirements of the system is
understood. *ll these re#uirements are then well documented and discussed
further with the customer for reviewing.
The design is an intermediate step between re#uirements analysis and
coding. %esign focuses on program attributes such as
8
%ata Structure
Software architecture
nterface representation
*lgorithmic details
The re#uirements 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 machine5readable form. f
design is done in sufficient detail then coding can be done effectively.
)rograms are created in this phase.
Testing begins when coding is done. 'hile performing testing the ma/or
focus is on logical internals of the software. The testing ensures e0ecution
of all the paths, functional behaviors. The purpose of testing is to uncover
errors, fi0 the bugs and meet the customer re#uirements.
9
2aintenance is the longest life cycle phase. 'hen the system is installed
and put in practical use then error may get introduced, correcting such
errors and putting it in use is the ma/or purpose of maintenance activity.
Similarly enhancing system6s services as new re#uirements are discovered is
again maintenance of the system.
This model is widely used model, although it has many benefits and
drawbac(s.
-enefit of Waterfa"" Mo!e"
1. The waterfall model is simple to implement
2. &or implementation of small systems, waterfall mode is useful.
.raw#ac/ of Waterfa"" Mo!e"
1. t is difficult to follow the se#uential flow in software development
processes. f some changes are made at some phases then it may
cause some confusion.
2. The re#uirement analysis is done initially and sometimes it is not
possible to state all the re#uirements e0plicitly in the beginning. This
causes difficulty in the pro/ect.
+. The customer can see the wor(ing model of the pro/ect only at the
end. *fter reviewing of the wor(ing model, if the customer gets
dissatisfied then it causes serious problems.
-. 8inear nature of waterfall model induces bloc(ing states, because
certain tas(s may be dependant on some previous tas(s. 7ence it is
necessary to accomplish all the dependant tas(s first. t may cause
long waiting time.
S0ira" Mo!e"
The spiral models possess the iterative nature of prototyping model and
controlled and systematic approaches of the linear se#uential model. This
model gives efficient development of incremental versions of software.
7ere, the software is developed in series of increments.
10
The spiral model is divided into a number of framewor( activities. These
framewor( activities are denoted by tas( regions.
1sually there are si0 tas(s regions.
11
Spiral model is realistic approach to development of large5scale systems and
software. "ecause customer and developer better understand the problem
statement at each evolutionary level. *lso ris(s can be identified or
rectified at each such level.
n the initial phase, product specification is built and in subse#uent passes
around the spiral the prototype gets developed and then more improved
versions of software gets developed.
%uring planning phase, the cost and schedule of software can be planned and
ad/usted based on feedbac( obtained from customer evaluation.
n spiral model, pro/ect entry point a0is is defined. This a0is represents
starting point for different types of pro/ects.
&or instance concept development pro/ect will start at core of spiral and will
continue along the spiral path. f the concept has to be developed into
actual pro/ect then at entry point 2 the product development process starts.
7ence entry point 2 is called product development pro/ect entry point. The
development of the pro/ect can be carried out in iterations.
The tas( regions can be described as
1. Customer Communication n this region it is suggested to establish
customer communication.
2. )lanning *ll planning activities are carried out in order to define
resources time line and other pro/ect related activities.
+. 4is( *nalysis The tas(s re#uired calculating technical and
management ris(s are carried out.
-. .ngineering n this tas( region, tas(s re#uired to build one or more
representations of applications are carried out.
3. Construct and release *ll the necessary tas(s re#uired constructing,
testing, install the application are conducted. Some tas(s that are
re#uired to provide user $00ort are also carried out in this tas(
region.
n each region, number of wor( tas(s is carried out depending upon the
characteristics of pro/ect. &or a small pro/ect relatively small number of
wor( tas(s is adopted but for a comple0 pro/ect large number of wor( tas(s
can be carried out. n spiral model, the software engineering team moves
around the spiral in a cloc(wise direction beginning at the core.
12
A!'antage of S0ira" Mo!e"
1. 4e#uirement change can be made at every stage
2. 4is(s can be identified and rectified before they get problematic
.raw#ac/ of S0ira" Mo!e"
1. t is based on customer communication. f the communication is not
proper then the software product that gets developed will not be up
to the mar(.
2. t demands considerable ris( assessment. f the ris( assessment is
done properly then only the successful product can be obtained.
WIN1WIN S0ira" Mo!e"
*s in spiral model the customer communication is important for obtaining the
re#uirements of the pro/ect, the '@5'@ model also suggests proper
communication with customer. n reality customer and developers undergo
through the process of negotiation. Successful negotiation occurs when
both the sides win. This is called win5win result.
Customer6s win means <btaining the system that satisfies most of
the needs.
%eveloper6s win means Getting the wor( done with realistic and
achievable budgets and deadlines.
n the win5win spiral model negotiation activities are carried out at
the beginning of each pass of the spiral.
,arious activities that can be carried out in win5win spiral model are
1. dentification of sta(eholders
2. %etermination of sta(eholders wins condition
+. @egotiations of sta(eholders striving for win condition. 'ith
the concerned software product team reconcile for win5win
result. Then determine ne0t level ob/ectives, constraints and
alternatives.
-. .valuate process and product. *naly!e and resolve the ris(s.
3. %efine ne0t level of product and process
9. ,alidate process and product definitions
:. Ta(e a review of product and give necessary comments on it.
13
There are three anchor points that can be defined in win5win spiral mode.
1. 8C< That means 8ife Cycle <b/ective. t defines the ob/ectives for
ma/or software engineering activities.
2. 8C* That means 8ife Cycle *rchitecture. t defines the software
architectures that can be produced with all the ob/ectives are set.
+. <C That means nitial <perational Capability. t represents
software with all the desired initial operational capabilities.
Protot,0ing Mo!e"
n )rototyping model initially the re#uirement gathering is done.
%eveloper and customer define overall ob/ectivesA identify areas needing
more re#uirement gathering. Then, a #uic( design is prepared. This design
represents what will be visible to user in input and output format.
&rom the #uic( design a prototype is prepared. Customer or user evaluates
the prototype in order to refine the re#uirements. teratively prototype is
tuned for satisfying customer re#uirements. Thus prototype is important to
identify the software re#uirements.
'hen wor(ing prototype is built, developer use e0isting program fragments
or program generators to throw away the prototype and rebuild the system
to high #uality.
Certain classes of mathematical algorithms, subset of command driven
systems and other applications where results can be easily e0amine without
real time interaction can be developed using prototyping paradigm.
W(en to c(ooe Protot,0ing2
Software applications that are relatively easy to prototype almost always
involve human5machine interaction =7C> the prototyping model is suggested.
* general ob/ective of software is defined but not detailed input, processing
or output re#uirements. Then in such a case prototyping model is useful.
'hen the developer is unsure of the efficiency of an algorithm or the
adaptability of an operating system then prototype serves as a better
choice.
.raw#ac/ of Protot,0ing
14
1. n the first version itself, customer often wants ?few fi0es6 rather
than rebuilding of the system. 'hereas rebuilding of new system
maintains high level of #uality.
2. The first version may have some compromises
+. Sometimes developer may ma(e implementation compromises to get
prototype wor(ing #uic(ly. 8ater on developer may become
comfortable with compromises and forget why they are inappropriate.
A!'antage of Protot,0ing Mo!e"
1. The wor(ing model of the system can be #uic(ly designed by
construction of prototype. This gives the idea of final system to the
user.
2. The prototype is evaluated by the user and the re#uirements can be
refined during the process of software development
+. This method encourages active participation of developer and user
-. This model is cost effective
3. The model helps to refine the potential ris(s associated with the
delivery of the final system
9. The system development speed can be increased with this approach.
3erification an! 3a"i!ation
The purpose of verification and validation is to confirm system specification
and to meet the re#uirements of system customers. ,erification represents
the set of activities that are carried out to confirm that the software
correctly implements the specific functionality. ,alidation represents set of
activities that ensure that the software that has been built is satisfying the
customer re#uirements.
The verification and validation involve chec(ing and review of processes and
system testing. System testing means e0ecuting the system with various
test cases. The test cases are derived from specification of input data
which is to be processed by the system.
The testing can be carried out using following steps$
1. 1nit testing n this type of testing individual components are tested
15
2. 2odule Testing 4elated collection of independent components are
tested
+. Sub5system Testing This is a (ind of integration testing. ,arious
modules are integrated into a subsystem and the whole subsystem is
tested. The focus is to test the integration or to test an interface.
-. System Testing n this testing, the whole system is tested.
3. *cceptance Testing This type of testing involves testing of the
system with customer data. f the system behaves as per customer
need then it is acceptable.
Fo$rt( Generation Tec(ni4$e 56GT7
The term fourth generation techni#ues =-GTs> encompass a broad array of
software tools. .ach tool enables the software engineer to specify some
characteristic of software at a high level. The tool then automatically
generates source code based on the developer6s specification. There is little
debate that the higher the level at which software can be specified to a
machine, the faster a program can be built. The -GT paradigm for software
engineering focuses on the ability to specify software using speciali!ed
language forms or a graphic notation that describes the problem to be
solved in terms that the customer can understand.
Currently, a software development environment that supports the -GT
paradigm includes some or all of the following tools$
@onprocedural languages for database #uery
4eport generation
%ata manipulation
Screen interaction and definition
Code generation
7igh5level graphics capability
Spreadsheet capability
*utomated generation of 7T28 used for web5site creation
nitially, many of the tools noted previously were available only for very
specific application domains, but today -GT environments have been
e0tended to address most software application categories.
16
8i(e other paradigms, -GT begins with a re#uirements gathering step.
deally, the customer would describe re#uirements and these would be
directly translated into an operational prototype. "ut this is unwor(able.
The customer may be unsure of what is re#uired, may be ambiguous in
specifying facts that are (nown, and may be unable or unwilling to specify
information in a manner that a -GT tool can consume. &or this reason, the
customerBdeveloper dialog described for other process models remains an
essential part of the -GT approach.
8i(e al software engineering paradigms, the -GT model has advantages and
disadvantages. )roponents claim dramatic reduction in software
development time and greatly improved productivity for people who build
software. <pponents claim that current -GT tools are not all that much
easier to use than programming languages, that the resultant source code
produced by such tools is ?inefficient6.
There is some merit in the claims of both sides and it is possible to
summari!e the current state of -GT approaches$
1. The use of -GT is a viable approach for many different application
areas. Coupled with computer5aided software engineering tools and
code generators, -GT offers a credible solution to many software
problems.
2. %ata collected from companies that use -GT indicates that the time
re#uired producing software is greatly reduced for small and
intermediate applications and that the amount of design and analysis
for small applications is also reduced.
+. The use of -GT for large software development efforts demands as
much or more analysis, design, and testing to achieve substantial time
savings that result from the elimination of coding.
P"anning
.ffective management of a software pro/ect depends on thoroughly planning
the progress of the pro/ect. 2anagers must anticipate problems that must
arise and prepare tentative solutions to those problems. * plan, drawn up at
the start of a pro/ect, should be used as the driver for the pro/ect. This
initial plan should be the best possible plan given the available information.
17
t evolves as the pro/ect progresses and better information becomes
available.
T,0e of P"an
1. ;uality )lan %escribes the #uality procedures and standards that
will be used in a pro/ect.
2. ,alidation )lan %escribes the approach resources and schedule used
for system validation.
+. Configuration 2anagement )lan %escribes the configuration
management procedure and structures to be used.
-. 2aintenance )lan )redicts the maintenance re#uirements of the
system, maintenance costs and effort re#uired.
3. Staff %evelopment )lan %escribes how the s(ills and e0perience of
the pro/ect team members will be developed.
The pro/ect plan sets out the resources available to the pro/ect, the wor(
brea(down and a schedule for carrying out the wor(. n some organi!ations,
the pro/ect plan is a single document that includes the different types of
plan. n other cases, the pro/ect plan is solely concerned with the
development process. The details of the pro/ect plan vary depending on the
type of pro/ect and organi!ation. 7owever, most plans should include the
following sections$
1. ntroduction This briefly describes the ob/ectives of the pro/ect
and sets out the constraints =eg. "udget, time> that affect the
pro/ect management.
2. )ro/ect organi!ation This describes the way in which the
development team is organi!ed, the people involved and their roles in
the team.
+. 4is( *nalysis This describes possible pro/ect ris(s, the li(elihood of
these ris(s arising and the ris( reduction strategies that are
proposed.
-. 7ardware and software resource re#uirements This specifies the
hardware and the support software re#uired to carry out the
development. f hardware has to be bought, estimates of the prices
and the delivery schedule may be included.
18
3. 'or( "rea(down this sets out the brea(down of the pro/ect into
activities and identifies the milestones and deliverables associated
with each activity.
9. )ro/ect Schedule This shows the dependencies between activities,
the estimated time re#uired to reach each milestone and the
allocation of people to activities.
:. 2onitoring and reporting mechanism This defines the management
reports that should be produced, when these should be produced and
the pro/ect monitoring mechanisms used.
)ro/ect plan should regularly be revised during the pro/ect. Some parts,
such as the pro/ect schedule, will change fre#uentlyA other parts will be
more stable.
Software Cot eti*ation
The software cost estimation is the process of predicting the resources
re#uired for software development process.
&undamental #uestions that are as(ed to /udge the estimation are$
1. 7ow much effort is re#uired to complete the pro/ect or an activityC
2. 7ow much calendar time is needed to complete an activityC
+. 'hat is the total cost computed for an activityC
The software cost components are
1. 7ardware and software costs
2. Travel and software or technology training costs
+. .ffort Costs =the dominant factor in most pro/ects> which includes
Salaries of employees involved in the pro/ect and Social and nsurance
costs.
-. Costs of building, heating and lighting
3. Costs of networ(ing and communications
9. Costs of shared facilities such as library, staff.
Eti*ation Tec(ni4$e
t is not possible to ma(e the accurate estimate of efforts re#uired to
develop a software system because
19
1. The initial estimates are based on inade#uate information in a user
re#uirements definition.
2. The software may run on unfamiliar computers or uses new technology
+. The people in the pro/ect may be un(nown
)ro/ect cost estimates may be self5fulfilling. The estimate defines the
budget and the product is ad/usted to meet the budget.
,arious estimation techni#ues are$
1. *lgorithmic cost modeling The cost estimation is based on the si!e
of the software
2. .0pert /udgment The e0perts from software development and the
application domain use their e0perience to predict software costs
+. .stimation by analogy The cost of a pro/ect is computed by
comparing the pro/ect to a similar pro/ect in the same application
domain and then cost can be computed.
-. )ar(inson6s 8aw5 The cost is determined by available resources rather
than by ob/ective assessment.
3. )ricing to win The pro/ect costs whatever the customer ready to
spend on it.
There are two approaches used in cost estimation.
1. Top5down n this approach we start estimation at the system level
and assess the overall system functionality and focuses on how this is
delivered through sub5systems
2. "ottom5up n this approach we start at the component level and
estimate the effort re#uired for each component. *dd these efforts
to reach a final estimate.
Organi8ationa" Str$ct$re
<rgani!ational structure may be defined as relationship between certain
functions, resources, and organi!ational positions. t is based on
determining and itemi!ing the activities or tas(s re#uired achieving the
ob/ectives of the organi!ation and the arrangement of these activities
according to type, si!e and other similar characteristics.
The most widespread organi!ational structure in the world today is the basic
hierarchical structure. This is the standard with top management at the top
of the chart and middle and lower management spreading out down the
20
structure. The organi!ation is usually bro(en down into different functional
units, such as engineering, research, accounting, and administration.
The hierarchical structure was originally based on such management theories
as speciali!ation, line and staff relations, authority and responsibility, and
span of control. *ccording to the principle of speciali!ation, the ma/or
functional subunits are staffed by such disciplines as engineering and
accounting. t is considered easier to manage specialists if they are grouped
together and if the department head has training and e0perience in that
particular discipline.
The strength of the functional organi!ation is in its centrali!ation of similar
resources. &or e0ample, the engineering department provides a secure and
comfortable organi!ational arrangement with well5defined career paths for a
young engineer. 2utual support is provided by physical pro0imity.
The functional organi!ation also has a number of wea(nesses. 'hen it is
involved in multiple pro/ects, conflicts invariably arise over the relative
priorities of these pro/ects in the competition for resources. *lso, the
functional department based on a technical specialty often places more
emphasis on its own specialty than on the goals of the pro/ect. 8ac( of
motivation and inertia are other problems.
7owever, many companies use the functional organi!ation for their pro/ect
wor( as well as their standard operations. The world is a complicated place.
n addition to discipline and function, other center for organi!ational
structures includes products, technologies, customers, and geographic
location.
Matri9 Organi8ation
The matri0 organi!ation is a multidimensional structure that tries to
ma0imi!e the strengths and minimi!e the wea(nesses of both the pro/ect
and the functional structure. t combines the standard vertical hierarchical
structure with a superimposed lateral or hori!ontal structure of a pro/ect
coordinator.
21
The ma/or benefits of the matri0 organi!ation are the balancing of
ob/ectives, the coordination across functional department lines, and the
visibility of the pro/ect ob/ectives through the pro/ect coordinator6s office.
The ma/or disadvantage is that the man in the middle is wor(ing for two
bosses. ,ertically, he reports to his functional department head.
7ori!ontally, he reports to the pro/ect coordinator or pro/ect manager. n a
conflict situation he can be caught in the middle.
The pro/ect manager often feels that he has little authority with regard to
the functional departments. <n the other hand, the functional department
head often feels that the pro/ect coordinator is interfering in his territory.
The solution to this problem is to define the roles, responsibility, and
authority of each of the actors clearly. The pro/ect coordinator specifies
what is to be done and the functional department is responsible for how it is
done.
Pro&ect Sc(e!$"ing
)ro/ect scheduling involves separating the total wor( involved in a pro/ect
into separate activities and /udging the time re#uired to complete these
activities. 1sually, some of these activities are carried out in parallel.
<ne has to coordinate these parallel activities and organi!e the wor( so that
the wor(force is used optimally. t is important to avoid a situation where
the whole pro/ect is delayed because a critical tas( is unfinished. 'hile
estimating schedules, one should not assume that every stage of the pro/ect
will be problem free. )eople wor(ing on a pro/ect may fall ill or may leave,
hardware may brea( down, and essential support software or hardware may
be delivered late. f the pro/ect is new and technically advanced, certain
parts of it may turn out to be more difficult and ta(e longer than originally
anticipated.
*part from calendar time, we have to estimate the resources needed to
complete each tas(. The principal resource is the human effort re#uired.
<ther resources may be the dis( space re#uired on a server, the time
re#uired on speciali!ed hardware such as a simulator, and the travel budget
22
re#uired on speciali!ed hardware such as a simulator, and the travel budget
re#uired for pro/ect staff.
* good rule of thumb is to estimate as if nothing will go wrong, and then
increase your estimate to cover anticipated problems. * further
contingency factor to cover unanticipated problems may also be added to the
estimate. This e0tra contingency factor depends on the type of pro/ect, the
process parameters =deadline, standards> and the #uality and e0perience of
the software engineers wor(ing on the pro/ect. )ro/ect schedules are
usually represented as a set of charts showing the wor( brea(down,
activities dependencies and staff allocations.
Ti*e +ine C(art 5Gantt c(art7
n software pro/ect scheduling the time line chart is created. The purpose
of timeline chart is to emphasi!e the scope of individual tas(. 7ence set of
tas(s are given as input to the time line chart. The timeline chart is also
called as Gantt chart.
The time line chart can be developed for entire pro/ect or it can be
developed for individual functions.
n time line chart
1. *ll the tas(s are listed at the leftmost column
2. The hori!ontal bars indicate the time re#uired by the corresponding
tas(
+. 'hen multiple hori!ontal bars occur at the same time on the calendar,
then that means concurrency can be applied for performing the tas(s
-. The diamonds indicate the milestones.
n most of the pro/ects, after generation of time line charts the pro/ect
tables are prepared. n pro/ect tables all the tas(s are listed along with
actual start and end dates and related information.
23
Ri/ Ana",i an! Manage*ent
The purpose of ris( analysis is to discover the cause, effects, and magnitude
of the ris( perceived and to develop and e0amine alternative options.
4is( 2anagement is the process of identifying ris(s, assessing their
severity, planning measures to put in place if the ris(s arise and monitoring
the software and the software process for ris(s.
*n important tas( of a pro/ect manager is to anticipate ris(s which might
affect the pro/ect schedule or the #uality of software being developed and
to ta(e action to avoid these ris(s. The results of the ris( analysis should
be documented in the pro/ect plan along with an analysis of the conse#uences
of a ris( occurring.
There are three categories of ris(s.
1. )ro/ect ris(s are ris(s which affect the pro/ect schedule or
resources. *n e0ample might be the loss of an e0perienced designer.
2. )roduct ris(s are ris(s which affect the #uality or performance of the
software being developed. *n e0ample might be the failure of a
purchased component to perform as e0pected.
+. "usiness ris(s are ris(s which affect the organi!ation developing or
procuring the software. &or e0ample, a competitor introducing a new
product is a business ris(.
The ris(s that may affect a pro/ect depend on the pro/ect and the
organi!ational environment where the software is being developed. Some of
the most common ris(s are given below$
Poi#"e Software Ri/
Ri/ Ri/ T,0e .ecri0tion
Staff Turnover )ro/ect .0perienced Staff will leave the pro/ect
before it is finished
2anagement
Change
)ro/ect There will be a change of organi!ational
management with different priorities
7ardware
unavailability
)ro/ect 7ardware which is essential for the
pro/ect will not be delivered on schedule
24
4e#uirements
change
)ro/ect and
)roduct
There will be a larger number of changes
to the re#uirements than anticipated
Specification
delays
)ro/ect and
product
Specifications of essential interfaces
are not available on schedule
Si!e underestimate )ro/ect and
product
The si!e of the system has been
underestimated
C*S. Tool under
performance
)roduct C*S. tools which support the pro/ect do
not perform as anticipated
Technology change "usiness The underlying technology on which the
system to built is superseded by new
technology
)roduct
competition
"usiness * competitive product is mar(eted
before the system is completed
4is( management is essential for software pro/ects because of the inherent
uncertainties that most pro/ects face. These stem from loosely defined
re#uirements, difficulties in estimating the time and resources re#uired for
software development, dependence on individual s(ills and re#uirement
changes due to changes in customer needs. <ne has to anticipate ris(s,
understand the impact of these ris(s on the pro/ect, the product and the
business and ta(e steps to avoid these ris(s. t is re#uired to draw up
contingency plans so that, if the ris(s do occur, we can ta(e immediate
recovery action.
The process of ris( management involves several stages$
1. 4is( identification 5 )ossible pro/ect, product and business ris(s are
identified
2. 4is( analysis The li(elihood and conse#uences of these ris(s are
assessed
+. 4is( planning )lans to address the ris( either by avoiding it or
minimi!ing its effects on the pro/ect are drawn up
-. 4is( monitoring The ris( is constantly assessed and plans for ris(
mitigation are revised as more information about the ris( becomes
available.
The ris( management process is an iterative process which continues
throughout the pro/ect. <nce an initial set of plans are drawn up, the
25
situation is monitored. The ris( avoidance and contingency plans may be
modified as new ris( information emerges.
Ri/ I!entification
4is( identification is the first stage of ris( management. t is concerned
with discovering possible ris(s to the pro/ect. 4is( identification may be
carried out as a team process uses a brainstorming approach or many simply
be based on e0perience. To help the process, a chec(list of different types
of ris( may be used. There are at least si0 types of ris( that can arise.
1. Technology ris(s 4is(s that derive from the software or hardware
technologies that are used to develop the system
2. )eople ris(s 4is(s that are associated with the people in the
development team
+. <rgani!ational ris(s 4is(s that derive from the organi!ational
environment where the software is being developed
-. Tools ris(s 4is(s that derive from the C*S. tools and other support
software used to develop the system
3. 4e#uirements ris(s 4is(s that derive from changes to the customer
re#uirements and the process of managing the re#uirements change.
9. .stimation ris(s 4is(s that derive from the management estimates
of the system characteristics and the resources re#uired to build the
system
Ri/ Ana",i
%uring the ris( analysis process, one has to consider each identified ris( and
ma(e a /udgment about the probability and the seriousness of it. The ris(
estimates should not generally be precise numeric assessments but should be
based around a number of bands$
The probability of the ris( might be assessed as very low =D1EF>, low
=1E523F>, moderate =2353EF>, high =3E5:3F> or very high =G:3F>.
The effects of the ris( might be assessed as catastrophic, serious,
tolerable or insignificant.
26
<ne should then tabulate the results of this analysis process using a table
ordered according to the seriousness of the ris(. n practice, to ma(e this
assessment we need detailed information about the pro/ect, the process, the
development team and the organi!ation. <nce the ris(s have been analy!ed
and ran(ed, one should assess which are most significant. The /udgment
must depend on a combination of the probability of the ris( arising and the
effects of that ris(.
Ri/ Ana",i
Ri/ Pro#a#i"it, Effect
<rgani!ational financial problems force
reductions in the pro/ect budget
8ow Catastrophic
t is impossible to recruit staff with the s(ills
re#uired for the pro/ect
7igh Catastrophic
Hey staff are ill at critical times in the pro/ect 2oderate Serious
Software components which should be reused
contain defects which limit their functionality
2oderate Serious
Changes to re#uirements which re#uire ma/or
design rewor( are proposed
2oderate Serious
The organi!ation is restructured so that
different management are responsible for the
pro/ect
7igh Serious
The database used in the system cannot process
as many transactions per second as e0pected
2oderate Serious
The time re#uired to develop the software is
underestimated
7igh Serious
C*S. tools cannot be integrated 7igh Tolerable
Customers fail to understand the impact of
re#uirements changes
2oderate Tolerable
4e#uired training for staff is not available 2oderate Tolerable
The rate of defect repair is underestimated 2oderate Tolerable
The si!e of the software is underestimated 7igh Tolerable
The code generated by C*S. tools is inefficient 2oderate nsignificant
Ri/ P"anning
The ris( planning process considers each of the (ey ris(s that have been
identified and identifies strategies to manage the ris(. There is no simple
27
process that can be followed to establish ris( management plans. t relies
on the /udgment and e0perience of the pro/ect manager. The ris( strategies
fall into three categories$
1. *voidance strategies 2eans that the probability that the ris( will
arise will be reduced. *n e0ample of a ris( avoidance strategy is the
strategy for dealing with defective components.
2. 2inimi!ation strategies 2eans that the impact of the ris( will be
reduced. *n e0ample of a ris( minimi!ation strategy is that for staff
illness.
+. Contingency plans 5 2eans that we are prepared for the worst and
have a strategy in place of deal with it. *n e0ample of a contingency
strategy is the strategy for organi!ational financial problems.
Ri/ Manage*ent Strategie
4is( Strategy
<rgani!ational
financial problems
)repare a briefing document for senior management
showing how the pro/ect is ma(ing a very important
contribution to the goals of the business
4ecruitment
problems
*lert customer of potential difficulties and the
possibility of delays, investigate buying5in components
Staff illness 4eorgani!e team so that there is more overlap of wor(
and people therefore understand each other6s /obs
%efective
components
4eplace potentially defective components with bought5in
components of (nown reliability
4e#uirements
changes
%erive traceability information to assess re#uirements
change impact, ma0imi!e information hiding in the design
<rgani!ational
restructuring
)repare a briefing document for senior management
showing how the pro/ect is ma(ing a very important
contribution to the goals of the business
%atabase
performance
nvestigate the possibility of buying a higher5
performance database
1nderestimated
development time
nvestigate buying5in components, investigate the use of
a program generator
Ri/ Monitoring
28
4is( monitoring involves regularly assessing each of the identified ris(s to
decide whether or not that ris( is becoming more or less probable and
whether the effects of the ris( have changes. This cannot usually be
observed directly, so we have to loo( at other factors that give you clues
about the ris( probability and its effects. These factors are obviously
dependent on the types of ris(. &ollowing table gives some e0amples of
factors that may be helpful in assessing these ris( types.
4is( &actors
Ri/ T,0e Potentia" In!icator
Technology 8ate delivery of hardware or support software, many
reported technology problems
)eople )oor staff morale, poor relationships amongst team
members, /ob availability
<rgani!ational <rgani!ational gossip, lac( of action by senior management
Tools 4eluctance by team members to use tools, complaints about
C*S. tools, demands for higher5powered wor(stations
4e#uirements 2any re#uirements change re#uests, customer complaints
.stimation &ailure to meet agreed schedule, failure to clear reported
defects
4is( monitoring should be a continuous process, and, at every management
progress review, we should consider and discuss each of the (ey ris(s
separately.
Software Re4$ire*ent
4e#uirement engineering is the process of establishing the services that the
customer re#uires from a system and the constraints under which it
operates and is developed.
n re#uirement engineering there is a systematic use of principles,
techni#ues and tools for cost effective analysis, documentation and user
needs. "oth the software engineer and customer ta(e an active role in
re#uirement engineering.
Re4$ire*ent
29
* re#uirement can range from a high5level abstract statement of a service
or of a system constraint to a detailed mathematical functional
specification. The re#uirement must be open to interpretation and it must
be defined in detail.
T,0e of Re4$ire*ent
The re#uirements can be classified as
1. 1ser 4e#uirements t is a collection of statements in natural
language plus description of the services the system provides and its
operational constraints. t is written for customers
2. System 4e#uirements t is a structured document that gives the
detailed description of the system services. t is written as a
contract between client and contractor
+. Software Specification t is a detailed software description that
can serve as a basis for design or implementation.
Re4$ire*ent Ana",i
4e#uirement analysis is an intermediate phase between system engineering
and software design.
4e#uirement analysis produces a software specification and helps as
following$
*nalyst The re#uirement analysis help the analyst to refine software
allocation. 1sing re#uirement analysis various models such as data model,
functional model and behavioral model can be defined.
%esigner *fter re#uirement analysis, the designer can design for data,
architectural interface and component level designs.
%eveloper 1sing re#uirements specification and design the software can be
developed.
Re4$ire*ent Ana",i Effort
1. )roblem 4ecognition The re#uirement analysis done for
understanding the need of the system. The scope of the software in
conte0t of a system must be understood.
30
2. .valuation and Synthesis Given below are the tas(s that must be
done in evaluation and synthesis phase$
%efine all e0ternally observable data ob/ects evaluate data flow
%efine software functions
1nderstand the behavior of the system
.stablish system interface characteristics
1ncover the design constraints
+. 2odeling *fter evaluation and synthesis, using data, functional and
behavioral domains the data model, functional model and behavioral
model can be built
-. Specification The re#uirement specification =S4S> must be built
3. 4eview 5 The S4S must be reviewed by pro/ect manager and must be
refined
F$nctiona" an! Non F$nctiona" Re4$ire*ent
Software system re#uirements can be classified as functional and non
functional re#uirements.
:;F$nctiona" Re4$ire*ent
&unctional re#uirements should describe all the re#uired functionality
or system services.
The customer should provide statement of service. t should be clear
how the system should react to particular inputs and how a particular
system should behave in particular situation
&unctional re#uirements are heavily dependent upon the type of
software, e0pected users and the type of system where the software
is used.
&unctional user re#uirements may be high5level statements of what
the system should do but functional system re#uirements should
describe the system services in detail.
&or e0ample$ Consider a library system in which there is a single interface
provided to multiple databases. These databases are collection of articles
from different libraries. * user can search for, download and print these
articles for a personal study.
31
&rom this e0ample we can obtain functional re#uirements as
1. The user shall be able to search either all of the initial set of
databases or select a subset from it.
2. The system shall provide appropriate viewers for the user to read
documents in the document store
+. * uni#ue identifier =order5id> should be allocated to every order. This
identifier can be copied by the user to the account6s permanent
storage area.
Pro#"e* Aociate! wit( Re4$ire*ent
4e#uirements imprecision
1. )roblems arise when re#uirements are not precisely stated
2. *mbiguous re#uirements may be interpreted in different ways by
developers and users
+. Consider meaning of term ?appropriate viewers6
1ser intention Special purpose viewer for each different
document type
%eveloper interpretation )rovide a te0t viewer that shows the
contents of the document
4e#uirements completeness and consistency
The re#uirements should be both complete and consistent. Complete means
they should include descriptions of all facilities re#uired. Consistent means
there should be no conflicts or contradictions in the descriptions of the
system facilities. n practice, it is impossible to produce a complete and
consistent re#uirements document.
2; Non F$nctiona" Re4$ire*ent
The non functional re#uirements define system properties and
constraints. ,arious properties of a system can be$ 4eliability,
response time, storage re#uirements. Constraints of the system can
be$ nput and <utput device capability, system representations etc.
32
)rocess re#uirements may also specify programming language or
development method.
@on functional re#uirements are more critical than functional
re#uirements. f the non functional re#uirements do not met then the
complete system is of no use.
T,0e of Non F$nctiona" Re4$ire*ent
The classification of non functional re#uirements is$
)roduct 4e#uirements These re#uirements specify how a delivered
product should behave in a particular way. &or instance$ .0ecution
speed, reliability.
<rgani!ational 4e#uirements The re#uirements which are
conse#uences of organi!ational policies and procedures come under
this category. &or instance$ )rocess standards used implementation
re#uirements.
.0ternal 4e#uirements These re#uirements arise due to the factors
that are e0tended to the system and the development process. &or
instance$ nteroperability re#uirements, legislative re#uirements.
n short, non functional re#uirements arise through user needs, budget
constraints, organi!ational policies, interoperability with other software or
hardware systems and e0ternal factors such as safety regulations.
3; Uer Re4$ire*ent
The user re#uirements should describe functional and nonfunctional
re#uirements in such a way that they are understandable by system
users who don6t have detailed technical (nowledge.
1ser re#uirements are defined using natural language, tables and
diagrams because these are the representations that can be
understood by all users.
G$i!e"ine for Writing Uer Re4$ire*ent
)repare a standard format and use it for all re#uirements
33
*pply consistency in the language. 1se ?shall6 for mandatory
re#uirements and ?should6 for desirable re#uirements.
The te0t which is mentioning the (ey re#uirements should be
highlighted
*void the use of computer /argon. t should be written in simple
language.
6; S,te* Re4$ire*ent
System re#uirements are more detailed specifications of system
function, services and constraints than user re#uirements.
They are intended to be a basis for designing the system
They may be incorporated into the system contract
The system re#uirements can be e0pressed using system models
The re#uirements specify what the system does and design specifies
how it does
System re#uirements should simply describe the e0ternal behavior of
the system and its operational constraints. They should not be
concerned with how the system should be designed or implemented
&or a comple0 software system design it is necessary to give all the
re#uirements in detail
1sually, natural language is used to write system re#uirements
specification and user re#uirements.
4e#uirement and design are inseparable System architecture may be
designed to structure the re#uirements. The system may inter5operate with
other systems and that may generate design re#uirements. The use of a
specific design may be domain re#uirements.
3. 4e#uirement .ngineering )rocess
* re#uirement engineering process is a process in which various
activities such as discovery, analysis and validation of system
re#uirements are done.
t begins with feasibility study of the system and ends up with
re#uirement validation. &inally the re#uirement document has to be
prepared
34
This process is a three stage activity where the activities are
arranged in the iterative manner. n the early stage of this process
most of the time is spent on understanding the system by
understanding the high5level non functional re#uirements and user
re#uirements.
Software Re4$ire*ent .oc$*ent
The software re#uirements document is the specification of the system. t
should include both a definition and a specification of re#uirements. t is
not a design document. *s far as possible, it should set of what the system
should do rather than how it should do it.
Software Re4$ire*ent S0ecification 5SRS7
The software re#uirements provide a basis for creating the software
re#uirements specifications =S4S>. The S4S is useful in estimating cost,
planning team activities, performing tas(s, and trac(ing the team6s progress
through the development activity. Typically software developers use ...
ST% I+E51JJI as the basis for the entire software specifications. The
standard template for writing S4S is as given below$
Document Title
Author(s)
Affiliation
Address
Document ersion
Date
1. Introduction
Purpose of this document ! Descri"es the #ur#ose of the document
Scope of this document ! Descri"es the sco#e of this re$uirements definition effort% This
section also details an& constraints that 'ere #laced u#on the re$uirements elicitation
#rocess( such as schedules( costs%
Overview ! )ro*ides a "rief o*er*ie' of the #roduct defined as a result of the
re$uirements elicitation #rocess
2. General Description
35
Descri"es the +eneral functionalit& of the #roduct such as similar s&stem
information( user characteristics( user o",ecti*e( +eneral constraints #laced on
desi+n team
Descri"es the features of the user communit&( includin+ their e-#ected
e-#ertise 'ith soft'are s&stems and the a##lication domain%
3. Functional Requirements
This section lists the functional re$uirements in ran.ed order% A functional
re$uirement descri"es the #ossi"le effects of a soft'are s&stem( in other 'ords( 'hat
the s&stem must accom#lish% /ach functional re$uirement should "e s#ecified in
follo'in+ manner0
Short, imperative sentence stating highest ranked unctional requirement
1% Descri#tion ! A full descri#tion of the re$uirement
2% Criticality ! Descri"es ho' essential this re$uirement is to the o*erall
s&stem
3% Technical issues ! Descri"es an& desi+n or im#lementation issues
in*ol*ed in satisf&in+ this re$uirement
4% Cost and Schedule ! Descri"es the relati*e or a"solute costs of the
s&stem
5% Risks ! Descri"es the circumstances under 'hich this re$uirement
mi+ht not a"le to "e satisfied
6% Dependencies with other requirements 1 Descri"es interactions 'ith
other re$uirements
7. ny other appropriate.
!. Interace Requirements
This section descri"es ho' the soft'are interfaces 'ith other soft'are #roducts or users
for in#ut or out#ut% /-am#les of such interface include li"rar& routines( to.en streams(
shared memor&( data streams( and so forth%
2ser 3nterfaces ! Descri"es ho' this #roduct interfaces 'ith the user
423 ! Descri"es the +ra#hical user interface if #resent% This section should include a set
of screen dum#s to illustrate user interface features
563 ! Descri"es the command1line interface if #resent% 7or each command( a descri#tion
of all ar+uments and e-am#le *alues and in*ocations should "e #ro*ided
A)3 ! Descri"es the a##lication #ro+rammin+ interface( if #resent%
8ard'are 3nterfaces ! Descri"es interfaces to hard'are de*ices
5ommunications 3nterfaces ! Descri"es net'or. interfaces
9oft'are 3nterfaces ! Descri"es an& remainin+ soft'are interfaces not included a"o*e
". #erormance Requirements ! 9#ecifies s#ed and memor& re$uirements
36
9. Design $onstraints ! 9#ecifies an& constraints for the desi+n team such as soft'are
or hard'are limitations
%. &ther 'on Functional (ttri)utes ! 9#ecifies an& other #articular non functional
attri"utes re$uired "& the s&stem such as0
9ecurit&
:inar& 5om#ati"ilit&
;elia"ilit&
<aintaina"ilit&
)orta"ilit&
/-tensi"ilit&
;eusa"ilit&
A##lication 5om#ati"ilit&
;esource 2tili=ation
9er*icea"ilit&
I. &perational Scenarios ! This section should descri"e a set of scenarios that
illustrate( from the user>s #ers#ecti*e( 'hat 'ill "e e-#erienced 'hen utili=in+ the
s&stem under *arious situations%
J. Schedule #reliminar* ! This section #ro*ides an initial *ersion of the #ro,ect #lan(
includin+ the ma,or tas.s to "e accom#lished( their interde#endencies( and their
tentati*e start?sto# dates%
1E. #reliminar* +udget , This section #ro*ides an initial "ud+et for the #ro,ect
::; (ppendices
11%1 Definitions( Acron&ms( A""re*iations ! )ro*ides definitions terms( and acron&ms(
can "e #ro*ided
11%2 ;eferences ! )ro*ides com#lete citations to all documents and meetin+s referenced%
C(aracteritic of SRS
,arious characteristics of S4S are
Correct The S4S should be made up to date when appropriate
re#uirements are identified.
1nambiguous 'hen the re#uirements are correctly understood
then only it is possible to write an unambiguous S4S
Complete To ma(e the S4S complete, it should be specified what
a software designer wants to create a software
Consistent t should be consistent with reference to the
functionalities identified
37
Specific The re#uirements should be mentioned specifically
Traceable 'hat is the need for mentioned re#uirementC This
should be correctly identified.
Software Protot,0ing
Software prototyping is a rapid software development for validating the
re#uirements.
The use of system prototypes is to help customers and developers to
understand the system re#uirements. 1nder software prototyping various
activities being carried out are$
1. 4e#uirements elicitation 1ser can perform various e0periments with
the prototype to chec( the system support
2. 4e#uirements validation )rototype can show errors and omissions in
re#uirement
-enefit of Software Protot,0ing
1. mprovement in software user and developer gets improved
2. f any service is missing or confusing then that can be identified
+. )rototype can serve as a basis for deriving system specification
-. 'or(ing system becomes available as there is a closer match of
prototype with actual system
3. %esign #uality can be improved
9. System can be maintained easily
:. %evelopment efforts may get reduced.
Protot,0ing in Software Proce
There are two approaches.
1. .volutionary prototyping n this approach of system development,
the initial prototype is prepared and it is then refined through number
of stages to final stage
2. Throw away prototyping 1sing this approach a rough practical
implementation of the system is produced. The re#uirement problems
38
can be identified from this implementation. t is then discarded.
System is then developed using some different engineering paradigm.
Ra0i! Protot,0ing Tec(ni4$e
t emphasi!es speed of delivery rather than either system characteristics
such as performance, maintainability or reliability.
There are three types of rapid prototyping techni#ues.
1. %ynamic 7igh 8evel 8anguages the dynamic high level languages with
efficient data management facilities can be used in rapid prototyping.
'hile choosing the prototyping language following issues are to be
considered.
'hat is the application domain of the problemC
'hat (ind of user interaction is re#uiredC
'hat is the supporting environment for the languageC
%ifferent programming languages can be used for different parts of
the system. "ut there should be a proper communication between
these languages.
2. %ata base )rogramming ,arious database supporting languages are
used for management of different databases. These include #uery
languages, screen generators, report generators, spreadsheets. *
database programming is cost effective small to medium si!e business
systems. This techni#ue is also called as fourth generation
techni#ues.
+. Component and *pplication *ssembly Some reusable components can
be used for rapid development of the system. The availability and
functionality of such components should be considered. n this
techni#ue two levels of development are used
*pplication level development .ntire application can be
integrated in the system and its functionality can be shared by
other components of the system.
Component level development ndividual component can be
integrated in standard framewor( of the system. &or e0ample,
Component <b/ect 2odel =C<2> and Common <b/ect 4e#uest
"ro(er *rchitecture =C<4"*>. * large library of such
components is available for rapid prototype development.
39
S,te* Engineering
System engineering is the process that focuses on variety of system
elements, analy!ing, designing and organi!ing those elements into the system
that can be a product, a service or a technology.
The system engineering process is also called business engineering when used
for business enterprises.
The system engineering process is also called product engineering when a
product is to be built.
The system engineering should produce an effective representation of
system. The effective representation can be prototype, specification or a
symbolic model. This representation should have pro/ect operational,
functional and behavioral characteristics of the system to be built.
EASWARI ENGINEERING CO++EGE
.EPARTMENT OF COMPUTER APP+ICATIONS
<UESTION -AN)
S$#&ect Co!e = >??3:2 +ect$re @r= 6A
S$#&ect Na*e = Software Engineering T$toria" @r= Ni"
.egree%-ranc( = MCA Practica"= Ni"
Bear%Se*eter = II%III Gran! Tota"= 6A
Fac$"t, = .r;R;.@ANAPA+ P(;.
.ate = ?>;?C;2?::
UNIT I
Section A
1. %efine Software
40
2. State the types of software products
+. 'hat is software engineeringC
-. 'hat is system engineeringC
3. %efine$ Software process
9. 8ist down the activities of software process
:. 8ist down the characteristics of software
I. @ame the (inds of software
J. 'hat is software engineering paradigmC
1E. 'hat is life cycleC
11. 8ist down the advantages and disadvantages of waterfall model
12. State the advantage of spiral model
1+. 'hat is win5win resultC
1-. 'hen to choose software prototypingC
13. %efine validation and verification
19. State any four -GT tools
1:. 'hat is software cost estimationC
1I. @ame the approaches used in software cost estimation
1J. State the purpose of time line chart
2E.'hat is ris( managementC
21. 8ist down the categories of ris(s
22.'hat is software re#uirement engineeringC
2+.%efine$ Software re#uirements document
2-.8ist down the characteristics of S4S
23.'hat is software prototypingC
29.8ist down the activities carried out in software prototyping
2:. 'hat are the benefits of software prototypingC
Section -
1. a. 8ist and e0plain the attributes of good software
b. .0plain the ob/ectives of software engineering
2. .0plain any two generic software process models
+. .0plain 8inear5se#uential model B 'aterfall software development model
with its benefits and drawbac(s
-. %raw a bloc( diagram and e0plain the Spiral model for software
development
3. %escribe 'in5win spiral model with its anchor points
41
9. .0plain )rototyping model with its advantages and drawbac(s
:. .0plain &ourth Generation Techni#ues =-GT> for software development
I. a. %istinguish between verification and validation
b. .0plain software pro/ect planning with its types
J. .0plain the process of software cost estimation
1E. %escribe the organi!ation structure with matri0 organi!ation
11. %raw the bloc( diagram and e0plain the process of pro/ect scheduling
12. %escribe the process of Software ris( management
1+. Classify the software system re#uirements
1-. .0plain software re#uirements specification with suitable e0ample
13. .0plain the Software prototyping techni#ues
42