MCS-034 Solved Assignment 2015-16

MCS-034
Qst.1 Assume that you are assigned responsibility of developing an Examination Form Submission
System (EFSS). EFSS will have all necessary fields that are essential for generation of a Hall Ticket
without any errors. After Examination Form is submitted, the data needs to be validated by EFSS. If the
data is valid, then Hall Ticket should be generated. Appropriate e-mail should be sent to student in all
cases. Make necessary assumptions.
For developing EFSS as specified above,
Qst.1 (a) Which SDLC paradigm will be selected. Justify your answer.
Ans: In this project, the spiral model is used for development. Spiral model has features of prototyping and
linear sequential model. It helps to develop incremental versions of the software rapidly. Because software
evolves as the process progresses, the developer and user better understand and react to risks at each
evolutionary level. This is a very powerful model to develop large-scale system and software.
Each of the regions is populated by a set of work tasks called a task set that are done according to the
requirement of the project to be developed. For small projects the number of tasks and their formality is low.
Conversely, for large projects the reverse is true.
These task regions of spiral model are:
Customer communication:-In this task region user is asked about his requirements from the system, through a
dialog between developer and the user.
Planning:-In this task region, resources, timelines and other project related information are considered and
appropriate decision taken.
Risk analysis:-In this region technical and management risks are identified and suitable measures taken
wherever feasible.
Engineering:-In this region one or more representations of application are built.
Construction and Release:-In this region, application is constructed, tested, installed and user support is
provided.
User evaluation:- In this region, feedback is taken from the user about the overall performance of the
application built during the engineering and implemented during installation stage.
The evolutionary process begins at the centre position and moves in a clockwise direction. Each traversal of the
spiral typically results in a deliverable. For example, the first and second spiral traversals may result in the
For More Solutions Contact To Mr. Bilal Ali : Brain Caf Computer Classes, Near U.P.
Tech. Chowk Lucknow. Contact Number:+91 9984736691,+91 9450148850
E_Mail_ID- belaal.ali@gmail.com@gmail.com, FB Page- facebook.com/bilalali0786
1
MCS-034
production of a product specification and a prototype, respectively. In this way a more stochastic version of the
software is produced after some subsequent traversal.
A key difference between the spiral model and other software models is that risk analysis is performed in
former and not in later.
Advantages of the Spiral Model:
The spiral model is a very good approach to develop large-scale software because of its evolutionary approach
to develop software. Besides this both user and developer can identify and remove the risks that can occur
during the software development.
Prototyping is used to reduce the risk as it can be developed at any stage of the evolutionary level.Due to
its demand to consider technical risks at all stages, it reduces risks that may become a big problem in future.
Its combined iterative and linear feature results in better software. Thus following the steps of spiral
model first of all I collected the requirements and developed partial site fulfilling basic requirements (based on
the requirement collected). As I discussed with users what information they want to put on web site and the
manner in which they want to fetch the information, the technical risk were reduced. After designing and
creation of some pages of site, I asked for feedback from the users. According to the feedback of users, I further
refined the pages of the site, wherever required. This procedure was followed until the whole site was
completely developed. Thus the complete website was developed in an iterative and sequential way to the entire
satisfaction of the users of Treasurehunt.com.
To develop the system Proto Type Modal is applied as the company wanted to see the software development
process and appearance of the software so that the idea of functionality of the system can be understood. The
software developed in three phases in first phase the dry proto type is developed in which after the analysis the
screens are designed and no validations are performed and also no database functionality is incorporated. After
the demonstration of dry proto type suggestions from the client are noted and the development process is moved
to the second phase i.e. wet prototype the actual designed is incorporated, validations are performed and the
software is submitted to the user for acceptance and testing and then after final submission of the software is
produced with user manual.
To understand the better functionality of the Prototype modal the applied modal is described here given
below:
Prototype Type Model:In general Customer defines a set of objectives for software, but does not identify detailed input, processing, or
output requirements. In other cases, the developer may be unsure of the efficiency of an algorithm, the
adaptability an operating system or the form the human machine interaction should have.
In such situations, a prototyping paradigm offers the best approach. The prototyping paradigm starts with
requirements gathering. Developer and customer define the overall objectives for the software, identify
requirements and outline areas where definition is necessary. A quick design than focuses on aspects of the
software that are visible to the customer /user. The quick design leads to the construction of a prototype. The
prototype is evaluated by the customer/user and is used of refine requirement for the software to be developed.
Iteration occurs, as the prototype is developed to satisfy the needs of the customer and enabling the developer to
better understanding what needs to be done.
The prototype serves as a mechanism for identifying software requirements if a working prototype is built, the
developer uses existing program fragments or applies tools to make working program quickly.
Qst.1 (b) List the functional and non-functional requirements.
2
MCS-034
Ans: i) Functional requirements: They define the factors like, I/O formats, storage structure, computational
capabilities, timing and synchronization. It present description of each function required to solve the
problem. A processing narrative is provided for each function, design constraints are stated and justified,
performance characteristics are stated, and one or more diagrams are included to graphically represent
the overall structure of the software and interplay among software functions and other system elements
under this topic, the functional working of the various modules where give the complete picture for the
data flow from one location to other.
The official definition of a functional requirement is that it essentially specifies something the system should
do. Typically, functional requirements will specify a behaviour or function, for example:
Display the name, total size, available space and format of a flash drive connected to the USB port. Other
examples are add customer and print invoice.
For the above project functional requirement are :
Fill Examination Form
Transaction corrections, adjustments and cancellations
Administrative functions
Authentication
Authorization levels
Audit Tracking
External Interfaces
Certification Requirements
Reporting Requirements
Historical Data
Legal or Regulatory Requirements
Generate Report
ii) Non-functional requirements: They define the properties or qualities of a
product including usability, efficiency, performance, space, reliability,
portability etc.
Simply put, the difference is that non-functional requirements describe how the system works, while
functional requirements describe what the system should do.
The definition for a non-functional requirement is that it essentially specifies how the system should behave
and that it is a constraint upon the systems behaviour. One could also think of non-functional requirements as
quality attributes for of a system.
Non-functional requirements cover all the remaining requirements which are not covered by the functional
requirements. They specify criteria that judge the operation of a system, rather than specific behaviours, for
example: Modified data in a database should be updated for all users accessing it within 2 seconds.
Some typical non-functional requirements are:
Performance for example Response Time, Throughput, Utilization, Static Volumetric
Scalability
Capacity
Availability
Reliability
Recoverability
Maintainability
Serviceability
Security
3
MCS-034
Regulatory
Manageability
Environmental
Data Integrity
Usability
Interoperability
As said above, non-functional requirements specify the systems quality characteristics or quality attributes.
Many different stakeholders have a vested interest in getting the non-functional requirements right particularly
in the case of large systems where the buyer of the system is not necessarily also the user of the system.
The importance of non-functional requirements is therefore not to be trifled with. One way of ensuring that as
few as possible non-functional requirements are left out is to use non-functional requirement groups. For an
explanation on how to use non-functional requirement group, read this blog post which will give you four of the
main groups to use.
Qst1. Estimate cost.
Ans: For a given set of requirements it is desirable to know how much it will cost to develop the software to
satisfy the given requirements, and how much time development will take. These estimates are needed before
development is initiated. The primary reason for cost and schedule estimation is to enable the client or
developer to perform a cost benefit analysis and for project monitoring and control. A more practical use of
these estimates is in bidding for software projects, where the developers must give cost estimates to a potential
client for the development contract.
For a software development project, detailed, and accurate cost and schedule estimates are essential
prerequisites for managing the project. Otherwise, even simple question like is the project late, are there cost
overruns, and when is the project likely to complete cannot be answered. Cost and schedule estimate are also
required to determine the staffing level for a project a deferent phase. It can be safely said that cost and schedule
estimates are fundamental to any form of management and are generally always required for a project .
Cost in a project is due to the requirement for software, hardware, and human resources. Hardware resources are
such thing as the computer time, terminal time, and memory required for the project, whereas software
resources include the tool and compilers needed during development .The bulk of the cost of software
development is due to the human resources needed, and most cost estimation procedure focus on this aspect.
Most cost estimates are determined in terms of person-month (PM). By properly including the overheads in
rupees cost of a person-month, besides including the direct cost of the person month, most costs for a project
can be incorporated by using PM as the basic measure. Estimates can be based on subjective opinion of some
person or determined through the use of models.
The costs associated with the system are expenses, outlays or losses arising from developing and using a
system. But the benefits are the advantages received from installing and using this system.
Cost and benefits can be classified as follow:
Tangible or intangible
Cost that are known to exist but their financial value cannot be exactly measured are referred to as intangible
costs. The estimate is only an approximation. It is difficult to fix exact intangible costs. For example, employee
movable problems because of installing new system are an intangible cost. How much moral of an employee
has be affected can not be exactly measured in terms of financial value.
Fixed or variable
Some costs and benefits remain constant, regardless of how a system is used. Fixed costs are considered as sunk
costs. Once encountered, they will not recur. For example, the purchase of an equipment for a computer centre
4
MCS-034
is called as fixed cost as it remains constant whether in equipment is being is called as fixed cost as it remains
constant whether in equipment is being used extensively or not. Similarly, the insurance, purchase of software
etc. Contrast, variable costs are incurred on a regular basis. They are generally proportional to work volume and
continue as long as the system is in operation. For example, the cost of forms varies in proportion to the
amount of processing or the length of the reports desired.
Direct or indirectDirect cost are those which are directly associated with a system. They are applied directly to the operator. For
example, the purchase of floppy for Rs 500/- is a direct cost because we can associate the floppy box with
money spent.Direct benefits also can be specifically attributable to a given project. For example, a new system
that can process 30 percent more transactions per day is a direct benefit.
Indirect cost are not directly associated with a specific activity in the system. They are often referred to as
overhead expenses. For example, cost of space to install a system, maintenance of computer center, heat, light
and air-conditioning are all tangible costs, but it is difficult to calculate the proportion of each attributable to a
specific activity such as a report.The estimation of cost of the project is a difficult task but we can estimate the
cost of the project by various methods. I am using the COCOMO (Constructive Cost Model). The model has
following hierarchy: Model 1: The basic COCOMO model computed software development effort land
cost as a function of
program size expressed in estimated lines of code.
Model 2: The intermediate COCOMO model computer software development effort as a function of
program size and a set of cost drivers that include subjective assessments of vehicle, hardware personnel and
project attributes.
Model 3: The advanced COCOMO model incorporates all characteristics of the intermediate version with
an assessment of the cost drivers impact on each step (analysis, design etc.) of the software engineering process.
The COCOMO model is defined for three classes of software projects are: 1)
Organic Mode:- Relatively small, simple projects in which small teams with good application
experience work to a set of less than rigid requirements.
2)
Semidetached Mode:- An intermediate (in size and complexity) software project in which teams with
mixed experience levels must meet a mix of rigid and less than rigid requirements.
3)
Embedded Mode:- A software project that must developed within a set of tight hardware, software and
operational constraints.
The basis COCOMO equation takes the form.
E
=
ab KLOCbb
D
=
Cb Edb
When E is the effort applied in person months, D is the development time in chronological months, and KLOC
is the estimated number of delivered lines of code for the project. (Express in thousands). The coefficients ab
and cb and the exponents bb and db where taken as.
This project is an organic project so: ab
=
4
bb
=
1.05
cb
=
2.5
b
d
=
0.38
LOC =
1555
KLOC =
3000/1000
=
3.0
E
=
2.4 (KLOC)1.05
=
2.4(3.0)1.05
5
MCS-034
=
7.6
=
7 person-months
New calculate the D is the development time in chronological months
D
=
2.5 E 0.35
=
2.5 (8) 0.35
=
5.2 months
=
5 months approximately
The computer project duration we use the effort estimated described above
N
=
E/D
=
7/5
=
1.4 person
=
1 person
When N is the recommended number of people for the project.
Qst1. (d) Estimate effort
Ans: Once the size of software is estimated, the next step is to estimate the effort based on
the size. The estimation of effort can be made from the organisational specifics of
software development life cycle. The development of any application software system
is more than just coding of the system. Depending on deliverable requirements, the
estimation of effort for project will vary. Efforts are estimated in number of manmonths.
The best way to estimate effort is based on the organisations own historical data
of development process. Organizations follow similar development life cycle for
developing various applications.
If the project is of a different nature which requires the organisation to adopt a
different strategy for development then different models based on algorithmic
approach can be devised to estimate effort.
Estimating Schedule
The next step in estimation process is estimating the project schedule from the effort
estimated. The schedule for a project will generally depend on human resources
involved in a process. Efforts in man-months are translated to calendar months.
Schedule estimation in calendar-month can be calculated using the following model
[McConnell]:
Schedule in calendar months = 3.0 * (man-months) 1/3
The parameter 3.0 is variable, used depending on the situation which works best for
the organisation.
COCOMO Model
COCOMO stands for Constructive Cost Model. It was introduced by Barry Boehm.
It is perhaps the best known and most thoroughly documented of all software cost
estimation models. It provides the following three level of models:
Basic COCOMO : A single-value model that computes software development
cost as a function of estimate of LOC.
Intermediate COCOMO : This model computes development cost and effort as
a function of program size (LOC) and a set of cost drivers.
Detailed COCOMO : This model computes development effort and cost which
incorporates all characteristics of intermediate level with assessment of cost
implication on each step of development (analysis, design, testing etc.).
This model may be applied to three classes of software projects as given below:
Organic : Small size project. A simple software project where the development
team has good experience of the application
6
MCS-034
Semi-detached : An intermediate size project and project is based on rigid and
semi-rigid requirements.
Embedded : The project developed under hardware, software and operational
constraints. Examples are embedded software, flight control software.
In the COCOMO model, the development effort equation assumes the following form:
E = aSb m
w here a and b are constraints that are determined for each model.
E = Effort
S = Value of source in LOC
m = multiplier that is determined from a set of 15 cost drivers attributes.
The following are few examples of the above cost drivers:
Size of the application database
Complexity of the project
Reliability requirements for the software
Performance constraints in run-time
Capability of software engineer
Schedule constraints.
Qst.1 (e) Develop SRS using IEEE format
Ans: Software Requirement Specification
The software requirements specification is produced at the culmination of the analysis task. The function and
performance allocated to software as part of system engineering are refined by establishing a complete
information description a detailed functional and behavioural description, a indications of performance
requirements and design constraints, appropriate validation criteria and other data pertinent to requirements.
1.
Overview:a.
Purpose
b.
Scope
c.
Definition, Acronyms, Abbreviations
d.
References
e.
Developers Responsibilities Overview
2.
General Description
a.
Vehicle Functions Overview
b.
User Characteristics
c.
General Constraints
d.
General Assumptions and Dependencies
3.
Specific Requirements
a.
Inputs and Outputs
b.
Functional Requirements
c.
External Interface Requirements
d.
Performance Constraints
e.
Design Constraints
Software Constraints
Hardware Constraints
4.
Validation and Criteria
a.
Performance bounds
7
MCS-034
5.
b.
Classes of tests
c.
Expected Software response
d.
Special Considerations
Acceptance Criteria
Overview:This is the requirements document for the project that will be used throughout the work. The system to be
developed is for front office and financial work of agency, based on the inputs given. This document follows the
IEEE standard for a requirement specification document, with some variations.
a). Purpose:
The purpose of this document is to describe the requirements of agency. It also describes the interfaces for the
system.
b). Scope:
This document is the only one that describes the requirements of the system. It is meant for use by the
developers and will be the basis for validating the final delivered system. Any changes made to the
requirements in the future have to go through a formal change approval process. The developer is responsible
for asking for clarifications, where necessary, and will not make any alterations without the permission of the
client.
c). Definitions, Acronyms, Abbreviations:
Not applicable.
d). References:
Not applicable.
e). Developers Responsibilities Overview:
The developer is responsible for
Developing the system,
Installing the software on the clients hardware,
Conducting any user training that might be needed for using the system, and
Maintaining the system for a period of one year after installation.
General Description: a). Functions Overview:
In agency there is a counter for booking and various queries of the customers can be solved with ease on one
table. As the software provide all information customer, registration etc provided by the agency.
b). User Characteristics:
The main users of this system will be the registration department and accounts department, who are
somewhat literate with computers and can use programs efficiently.
c). General Constraints:
The system should run on win 95 /98/2000 or above.
d). General Assumptions and Dependencies:
Not applicable.
Specific Requirements:
a). Inputs and Outputs:
The system has all the details regarding the Customer, Agents, Product, Kit, employee, etc are
maintained etc. The system has several inputs in form of data entry and several outputs in form of bills,
reports etc.
8
MCS-034
The forms under the heading General Entries are registration; salary, leave etc are maintained.
From one the bill is generated and the other helps in report generation. Here also, the customer gets the
desired registration and accordingly the bills and report are generated.
b). Functional Requirements:
It present description of each function required to solve the problem. A processing narrative is provided
for each function, design constraints are stated and justified, performance characteristics are stated, and
one or more diagrams are included to graphically represent the overall structure of the software and
interplay among software functions and other system elements under this topic, the functional working of
the various modules where give the complete picture for the data flow from one location to other.
c). External Interface Requirements:
Only one user command is required. The file name must be prompted by the system in status bar.
d). Performance Constraints:
The reports and bills should be printed in less than 1 minute.
e). Design Constraints:
The system is to run under the WINDOWS operating system.
Validation Criteria:
Probably the most important section of a software requirements specification is validation Criteria. The
specification of validation criteria acts as an implicit review of all other requirements. The tests must be
conducted to validate function, performance and constraints.
In this project I have try the various steps in testing the links and connectivity of the data Directorate of public
grievances takes up a grievances where it is satisfied that eh matter has not been dealt with by the concerned
SSA in a fair, just or objective manner or has been unduly delayed. It may take up such a care for investigation,
call for a report and or file from the concerned SSA and ask them to reconsider the matter and to arrive at a fair
decision in a time bound manner.
Acceptance Criteria:
Before accepting the system, the developer must demonstrate that the system works on the course data for the
last 4 semesters. The developer will have to show through test cases that all conditions are satisfied.
SOFTWARE REQUIREMENTS
Front End
Operating system
Back End
For documentation
Reporting tool
:
:
:
:
:
ASP.Net 3.5, C#
Microsoft Windows9X or upgrade
SQL Server 2005
MS Office 97 or Later Version
Crystal Reports 8.0
9
MCS-034
HARDWARE REQUIREMENTS
Processor
RAM
HDD
Monitor
CD drive
Floppy drive
Keyboard
Mouse
:
:
:
:
:
:
:
:
300 MHz (500 MHz recommended) Intel Pentium or other

32 MB min (128 MB rec. for higher version of Windows)
75 MB of free Hard Disk space (10 MB virtual space reco..)
14 SVGA Monitor
32X or later
1.44 MB 3.5 Floppy Drive
Microsoft standard 102 keys normal Keyboard
Microsoft standard 2 buttons or 3 Button mouse.
10

MCS-034 Solved Assignment 2015-16

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

MCS-034 Solved Assignment 2015-16

Caricato da

Copyright:

Formati disponibili

MCS-034

300 MHz (500 MHz recommended) Intel Pentium or other

Potrebbero piacerti anche