For more IGNOU Solved Assignments visit – www.IGNOUHelp.

in

Get Daily Updates by Facebook:

https://www.facebook.com/IGNOUHelp.in

Course Code : MCS-034

Course Title : Software Engineering
Assignment Number : MCA(3)/034/Assign/13
Maximum Marks :
100 Weightage : 25%
This assignment has one question for 80 marks. 20 marks are for viva-voce. You may use illustrations and
diagrams to enhance the explanations. Please go through the guidelines regarding assignments given in the
Programme Guide for the format of presentation.
Question 1:
Assume that you are assigned responsibility of developing a Web based Examination Form Submission and
Processing System (WEFSPS). WEFSPS accepts data from the learners as well as staff of RC who receive paper
based examination forms. After the last date for submission of form is completed, WEFSPS should generate hall
tickets for the applicants. However, it needs to check the registration validity, fee payment status and then
generated hall ticket. The candidate should be assigned examination center that is nearest to his/her residence.

For developing WEFSPS as specified above,

(a) Which SDLC paradigm will be selected. Justify your answer. Solution
: The Spiral model seems as an ideal choice here. No other model seems a
reasonable alternative to accept as a different answer. This model combines the
features of the prototyping & the waterfall model. As Web based Examination Form
Submission and Processing System (WEFSPS) for a university is a large project, therefore spiral
model is intended for large,
complex, expensive & complicated projects.
Page 1
The steps in the spiral model can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This
usually involves interviewing a number of users representing all learners as well as staff of RC

the and other aspects of the existing system.

3. A first prototype of the new system is constructed from the preliminary

design. This is usually a scale down system, and represents an approximation
of the characteristics of the final product.

4. A second prototype is evolved by a fourfold procedure:

(1) Evaluating the first prototype in terms of its strengths, weaknesses, and risks;
(2) Defining the requirements of the second prototype;
(3) Planning and designing the second prototype;
(4) Constructing and testing the second prototype.

Strength:
1. Estimates (i.e. budget, schedule, etc.) become more realistic as
work progresses, because important issues are discovered earlier.
2. It is more able to cope with the (nearly inevitable) changes that
software development generally entails.
3. Software engineers (who can get restless with protracted design processes)
can get their hands in and start working on a project earlier.
Page 2
Weakness:
1. Highly customized limiting re-usability
2. Applied differently for each application

3. Risk of not meeting budget or schedule

4. Risk of not meeting budget or schedule

((b) List the functional and non-functional requirements.

1. Functional requirements
Ans. In software engineering, a functional requirement defines a function of a
software system or its component. A function is described as a set of inputs,
the behavior, and outputs (see also software). Functional requirements may
be calculations, technical details, data manipulation and processing and other
specific functionality that define what a system is supposed to accomplish..

User Interfaces:

1. Login screen
2. menu selection screen
3.Examination Form Entry
4. Examination Instruction information
5. Examination eligibility check
Page 3
6. Hall ticket Generation
7. registration validity,
8. fee payment status

Hardware Interfaces Server Configuration:

Minimum 2GB Hard Disk
P-III processor or equivalent
Ram 512 MB
Windows with Apache preloaded. Client Configuration
A terminal with Internet Explorer and Printer.

Software Interfaces Operating system – WindowsXP,

OracleNetwork -- LAN

2. Non-functional requirements

Performance Requirements
System can withstand even though many number of users requested the desired
service. As we are keeping office level server of the automated payroll system.
Page 4
And access is given to the only registered users of office who requires the services

of viewing, Updating etc. It can withstand the load.

Security Requirements
Sensitive data is protected from unwanted access by users
appropriate technology and implementing strict user access criteria.

Software Quality Attributes

Menu-driven programs with user friendly interface with simply hyper links. It is
very easy to use. Backup mechanisms are considered for maintainability of
software as well as database. As it is object oriented reusability exists. As
project is based on MVC architecture, testability exists.

Safety & Reliability Requirements

By incorporating a robust and proven SQL into the system, reliable performance
and integrity of data is ensured. There must be a power backup for server system.

(c) Estimate cost

Ans. Software Cost Estimation is widely considered to be a weak link in software

project management. It requires a significant amount of effort to perform it
correctly. Errors in Software Cost Estimation can be attributed to a variety of
factors. Various studies in the last decade indicated that 3 out of 4 Software
Page 5
projects are not finished on time or within budget or both

Who is responsible for Software Cost Estimation? The group of people

responsible for creating a software cost estimate can vary with each
organization. However the following is possible in most scenarios –
People who are directly involved with the implementation are involved in
the estimate. - Project Manager is responsible for producing realistic cost
estimates. - Project Managers may perform this task on their own or consult
with programmers responsible. - Various studies indicate that if the
programmers responsible for development are involved in the estimation it
was more accurate. The programmers have more motivation to meet the
targets if they were involved in the estimation process.

Factors contributing to inaccurate estimation

Scope Creeps, imprecise and drifting requirements · New software
projects pose new challenges, which may be very different from the past
projects. · Many teams fail to document metrics and lessons learned
from past projects · Many a times the estimates are forced to match the
available time and resources by aggressive leaders · Unrealistic estimates
may be created by various „political under
currents‟
Page 6
Impact of Under-estimating:
Under-Estimating a project can be vary damaging
It leads to improper Project Planning - It can also result in under-
staffing and may result in an over worked and burnt out team
Above all the quality of deliverables may be directly
affected due insufficient testing and QA
Missed Dead lines cause loss of Credibility and goodwill

(d) Estimate effort

Ans.
Estimating
• The process of forecasting or approximating the time and cost
of completing project deliverables.
• The task of balancing the expectations of stakeholders and the need
for control while the project is implemented
• The two primary elements in test estimation are time and resources.
Your estimation needs to take both into account.
• There are many questions you need to answer in order to do test estimation.
The more accurate and thorough your answers to these questions the better your
test estimation.
• What modules or functionalities will be tested and how many testers are
available to test them? Of course as functionalities increase and/or number
Page 7
of testers decrease the more time it will take to throughly test
the application.
• What is the complexity of each of these modules or functionalities? As the
complexity increases the more time and effort will be required to understand
the application create test plans create test cases execute test
cases regress test cases and retest defects.
• How many test iterations (test runs) will be required to complete the
test project? This is also related to complexity. As an application becomes
more complex it will typically require more test iterations to reach the
company's exit critera (the number of open defects by severity and priority
that a company can live with).
• How much time will be required by developers to produce fixes for new
builds between test runs? Complexity is also a factor here. As an application
becomes more complex there are often more dependencies between
modules and functionalities. This often requires coordination between
developers. Consequently this takes more time. This is important because
your estimation must also include the amount of time testers are waiting
for the next build between test runs.
• What is the average number of defects that you anticipate will be found
during each test run? You may have already guessed that complexity is a
factor here too. The more complex an application the greater number of
defects will reach the test team when the application is released to them.

In addition the more complex the application the more likely that severe
and high priority defects will be found in later stages of the test process.
Page 8
 P

(e) Develop SRS Using IEEE format

Pr e fa ce
This docum ent cont ains t he Soft w ar e Requirem ent s Specificat ion
( SRS) of Web based Examination Form Submission and Processing System (WEFSPS). The m ain
aim of t his proj ect is t o add funct ionalit y t o t he ex ist ing SUMS sy st em in
or der t o pr ovide an online facilit y for m anaging and r egist ering
st udent account s and fill for m .
This docum ent has been prepared in accor dance w it h t he I EEE St
d 830- 1998, I EEE Recom m ended Pr act ice for Soft w ar e
Requirem ent s Specificat ions [ I EEE 1998] .
1 . I n t r od u ct ion
This Soft w ar e Requir em ent Specificat ion is w rit t en accor
dance w it h t he I EEE St d 830- 1998 m odel.
1 .1 . Pu r p ose

This SRS Docum ent cont ains t he com plet e soft w are r equir em ent s
for t he Web based Examination Form Submission and Processing System (WEFSPS). and describes
t he design decisions, ar chit ect ur al design and t he det ailed design needed t
o im plem ent t he sy st em . I t prov ides t he visibilit y in t he design and
1.2. pr ovides inform at ion needed for soft w ar e suppor t .

1 .2 . Scop e
Web based Examination Form Submission and Processing System (WEFSPS). used t o replace old
paper w or k sy st em . Web based Examination Form Submission and Processing System (WEFSPS).
is t o build upon t he exist ing w eb- based pr oj ect
Page 9
m ar king sy st em PUMS in or der t o im plem ent t he pr oj ect m ar king
pr ocess and allocat ing super visor / ideas t o st udent s. This incr ease
in efficiency of proj ect m ar king, audit t r ails of m ark ing pr ocess, give
feedback t o st udent , finally , publicat ion and em ail st udent
r esult . I t pr ovides a m echanism t o edit t he online m ar king form w
hich m ak es t he sy st em is flexible.
2. 1 .3 . D e fin it ion s, a cr on y m s, a n d a b b r e v ia t ion s

WEFSPS Web based Examination Form Submission and Processing System (WEFSPS)

PUMS Pr oj ect Unit s Managem ent Syst em

SRS Soft w ar e Requirem ent s Specificat ion
SUMS St udent and Unit s Managem ent Sy st em J2EE
Jav a 2 Plat for m Ent er pr ise Edit ion
JSP Jav a Ser v er Page
UP LinkUOP St udent Por t al Facilit y
OS Oper at ing Sy st em

1 .4 . Re fe r e n ce s
Br
igg s
Br iggs, J. ( 2005) . SUMS docum ent at ion. Ret riev ed

3r d Decem ber 2005,

2005 fr om ht t p: / / w w w . t ech. por t .ac. uk / st affw eb/ br iggsj / j

im app/ S UMS/
I EEE
1998
I EEE St d 830- 1998, I EEE Recom m ended Pr act ice for
Soft w are Requir em ent s Specificat ions. I SBN 0 - 7381- 0332-
Page 10
2.
1 .5 . Ov e r v ie w
This docum ent has been prepared in accor dance w it h t he I EEE St
d 830‐1998, I EEE Recom m ended Pr act ice for Soft w ar e
Requir em ent s Specificat ions [ I EEE 830 ‐1998 ( 1998) ] . I t pr ovides t he inform at
ion of Pr oduct per spect iv e, Pr oduct funct ions, User
char act erist ics, Const r aint s, Assum pt ions and dependencies
and specific r equir em ent .
2 . Ov e r a ll de scr ip t ion
This sect ion of t he SRS describes all gener al fact ors of t he
pr oduct and it s requirem ent s.
2 .1 . Pr od u ct pe r sp e ct ive

2 .1 .1 . Sy st e m in t e r fa ce s
The SUMS is t he new updat ed v ersion of PUMS - t he w eb- based pr
oj ect unit m anagem ent sy st em . I t is int ended t o im plem ent all
PUMS's feat ur es for t he adm inist rat ion of st udent pr oj ect s. The
SUMS is using J2EE plat form and St r ut s Model 2. All com ponent s
follow Model- View - Cont r oller pat t er n. SUMS im port Jim App
pack ages t hat can eit her connect ing t o an Or acle dat abase or My
SQL dat abase t hr ough t he Dat abase Ut ilit y com ponent s. The
possible ex t ension is t o int er - connect ion t o UP Link Sy st em w hich
pr ovide st udent w it h m any funct ions, including t he abilit y t o check
assessm ent r esult s. St udent s can connect bot h sy st em s t o r et
rieve inform at ion on t heir academ ic pr ogress.
2 .1 .2 . U se r in t e r fa ce s
All pages of t he sy st em are follow ing a consist ent t hem e and
clear st r uct ure. The occur r ence of er r ors should be m inim ized
t hr ough t he use of check box es, radio but t ons and scr oll dow n in or
der t o r educe t he am ount of t ext input fr om user. Jav aScript im plem
ent in HTML in order t o prov ide a Dat a Check before

subm ission. HTML Tables t o display inform at ion t o give a clear st r

uct ure t hat easy t o under st and by user. Er ror m essage should be
locat ed beside t he err or input w hich clearly highlight and t ell
user how t o solve it . I f sy st em err or , i t should pr ov ide t he cont act m
et hods. The page should display t he pr oj ect process in differ ent colour t
o clearly r eflect t he v arious st at es t hat st udent done. Each level of
user w ill hav e it s ow n int er face and privilege t o m ange
Page 11
and m odify t he pr oj ect inform at ion such as super visor able t o
m onit or / m anage his st udent pr ogress and m ak e com m ent on it ,
st udent can change his det ail, view t he pr ogress, subm it proj ect idea.
The Sy st em should provide a feedback form for all users t o give com m
ent s or ask ing quest ions. I t should pr ovide a FAQ t o m inim ize t he w
ork load of sy st em adm inist r at or .

2 .1 . 3 . H a r d w a r e in t e r
fa ce s a. . Se r v e r Side
The w eb applicat ion w ill be host ed on one of t he depar t m ent 's

Linux ser ver s and connect ing t o one of t he school Or acle

Dat abase ser v er. The w eb ser v er is list ening on t he w eb st andar d
por t , por t 80.
b. . Clie n t Side
The sy st em is a w eb based applicat ion; client s are r equiring using a
m oder n w eb brow ser such as Mozilla Fir ebox 1. 5, I nt er net
Ex plor er 6 and Enable Cookies. The com put er m ust hav e an I nt
er net connect ion in or der t o be able t o access t he sy st em .
2 .1 . 4 . Soft w a r e in t e r
fa ce s a. . Se r v e r Side
The UOP already has t he required soft w are t o host a Jav a w eb
applicat ion. An Apache Web ser ver w ill accept all request s fr om t he
client and forw ar d SUMS specific request s t o Tom cat 5. 5
Ser vlet Cont ainer w it h J2EE 5. 0 and St r ut 1. 2. 8 host ing SUMS. A

dev elopm ent dat abase w ill be host ed locally ( using My SQL) ; t he
pr oduct ion dat abase is host ed cent r ally ( using Or acle) .
b. . Clie n t Side
An OS is capable of r unning a m oder n w eb br ow ser w
hich suppor t s HTML ver sion 3. 2 or higher .
2 .1 .5 . Com m u n ica t ion s in t e r fa ce s
The HTTP prot ocol w ill be used t o facilit at e com m unicat
ions bet w een t he client and ser ver.
2 .1 .6 . M e m or y
Page 12
The UOP already host s a num ber of Jav a w eb applicat ions, it is not
ant icipat ed t hat OPMS w ill requir e any addit ional m em or y st or
age.
g) Oper at ions Procedur es are alr eady in place as par t of t
he UOP's I T policies for dat a securit y and Back up.

h) Sit e adapt at ion r equir em ent s. Ther e should no sit e adapt at ion r
equirem ent since t he Web Applicat ion Ser ver w as set up and
r unning Jav a w eb applicat ion.
2 .2 . Sy st e m fu n ct ion s
This sect ion out lines all t he m ain feat ur e of WEFSPS.
2 .2 .1 . St u d e n t r ole
The St udent can r egist er a SUMS account s and st ar t t he progress

of pr oj ect . On t he r egist er for m , st udent should ent er all t heir det ail
such as HEMI S num ber s, Em ail and cont act num ber . The sy st em w ill
gener at e act iv at ion code and send em ail t o st udent and confirm t he
regist r at ion. Aft er, t he syst em allow st udent t o change infor m at ion
and pr ovide t he funct ion for get passw or d for st udent t o r et r iev e back
t he passw or d.
2 .2 .2 . Ad m in ist r a t ion r ole
The sy st em adm inist r at or m ust be able t o:
1 . deact iv at e and r eact iv at e st udent account login

2 . for ce t he sending of a new passw or d t o a st udent v ia em

ail 3 . change any of a st udent 's det ails
2 .2 .3 . Au d it Tr a ilin g
Each user w ill hav e an associat ed r ecord of hist or y . This w ill
pr ovide infor m at ion on v arious event s such as Pr ev ious
Dev elopm ent - a num ber of com ponent s have been dev eloped by t he
client , Jim Briggs, and previous dev eloper , St ev en J Pow ell. New com
ponent s need t o com pat ible t o t he exist sy st em .
2 .5 Assu m p t ion s a n d d e p e n d e n cie s
Alt hough basic passw ord aut hent icat ion and r ole based securit y m
echanism s w ill be used t o pr ot ect OPMS fr om unaut horised access;
funct ionalit y such as em ail not ificat ions are assum ed t o be
sufficient ly prot ect ed under t he exist ing securit y policies applied by t
he Univer sit y net w or k t eam . Redundant Dat abase is set up as t he
r ole of back up Dat abase Ser v er w hen pr im ar y dat abase is failure.
Page 13
The corr ect funct ioning of OPMS w ill par t ly be dependant on t he cor r
ect ness of t he dat a st ored and m anaged as par t of t he PUMS
sy st em . Also, t he applicat ion w ill be host ed by t he UOP as one of m
any applicat ions; t he event of t he ser v er failing due t o an er r or w it h
one of t hese applicat ions m ight r esult in WEFSPS becom ing t em por
arily unavailable.
3 . Sp e cific r e q u ir e m e n t s
3 .1 . Fu n ct ion a l r e q u ir e m e n t
s 3 .1 .1 . U se r cla ss - Le r n e r
This sect ion is for UOP School of Com put ing St udent
1 . St udent Ex am inat ion r egist r at ion for m . St udent can be regist er on t
he sy st em and fill in all det ail and forw ar d t o choose
pr oj ect / super visor .
2 . Change Det ail. St udent can change det ail if inform at ion is

incor r ect such as t elephone num ber .

3 . Change Passw or d. St udent can change his login passw or d
at any t im e for secur it y r eason.
4 . For get passw or d. St udent can request his passw or d if he/
she for got t en t he passw or d.

3 .1 .2 . U se r cla ss - Aca de m ic St a ff
All st aff can view t he det ails of any st udent .

3 .1 .4 U se r cla ss - U n it Coh or t co- or d in a t or

Cer t ain st aff m ay be designat ed as Unit or Cohor t Co- or dinat or s
and can change t he det ails of any st udent doing t heir unit or
pr oj ect cohor t .
Change St udent Det ail Unit Cohort co- or dinat or can change st
udent det ail for incor r ect inform at ion.
View St udent Det ail
Unit Cohor t co - ordinat or can view st udent infor m at ion and
m onit or t heir pr ogr ess.

List St udent
Page 14
 Unit Cohor t co- ordinat or can list all st udent s in differ ent period of differ
ent gr oup.
Change Passw ord
Unit Cohor t co- ordinat or can reset t he st udent 's passw ord if
r equir ed.
3 .1 .5 U se r cla ss - Sy st e m Ad m in ist r a t or
List St udent
Sy st em Adm inist r at or can list all st udent s in different period of
differ ent gr oup t o check any er r or .
Change Passw ord
Sy st em Adm inist r at or can reset t he st udent 's passw or d if r equired.
3 .1 .6 U se r cla ss - RC St a ff
List St udent
Adm inist r at ion St aff can list all st udent s in different period
of differ ent gr oup.
3 .2 D e sig n con st r a in t s
The sy st em need t o design base on t he exist ed code and dat
abase using J2SE 5. 0, J2EE 1.4 and St r ut s 1. 2.x .
3.3 Soft w a r e sy st e m a t t r ib u t
e s 3.3 .1 Se cu r it y
The sy st em needs t o log client 's infor m at ion of r egist r at ion such
as I P address and t im e for securit y pur pose. Passw or d should encr
y pt ed and st or e in t he dat abase.
3 .3 .2 M a in t a in a b ilit y
The sy st em dev eloping using St r ut s, all act ion is det ailed in st r
ut s- config. xm l and w eb. xm l t hat easy t o m odify and m ak e
updat e.
3 .3 .3 Por t a b ilit y
The w eb applicat ion is coding in J2EE and St r ut s, t her efor e, it
should be t r ansfer able bet w een differ ent OS and Jav a cont ainer.
3 .4 Ot h e r r e q u ir e m e n t s
For fur t her ex t ending, is able t o send not ificat ion by SMS.

For more IGNOU Solved Assignments visit – www.IGNOUHelp.in

Get Daily Updates by Facebook:

https://www.facebook.com/IGNOUHelp.in
Page 15