Академический Документы
Профессиональный Документы
Культура Документы
Information of software
Acknowledgment
Data
Sender Receiver
Update
Data Data
Base Base
The original formulation for computing the function point uses the count of five different parameters,
namely external input types, external output types, logical internal files, external interface file, external
inquiry types. According to the function approach, these five parameter capture the entire functionality
of system. However, two element of the same amount to the functionality of the system. To account
for complexity, each parameter in a type is classified as simple, average or complex. The definition of
each of these types and the interpretation of their complexity level.
Each unique input type that is given as input to the application from outside is considered of external
input type and is counted. An external is considered unique if the format is different from other or if the
specification requires a different processing for this type from other inputs of requires a different
processing for this type from other inputs of the same format. The source of external input can be the
user or different application, files.
An external type is considered simple if it has a few data element and affects only a few internal files of
application. It is considered as complex if it has many internal logical files are needed for processing
them. The complexity is average if it is in between. Note that files needed by operating system or
hardware are not counted as external input files because they do not belong to application but are
needed due to the underlying technology.
Each application maintains information internally for performing its functions. Each logical group of
data or control information that is generated, used and maintained by application is counted as logical
internal file type .a logical internal file is simple if it contain a few record types, complex if it has many
record type, and average if it is in between. Files are passed or shared between applications are count
external interface file type. Note that each such type file is counted for all the application sharing it. The
complexity levels are defined as for logical file type.
A system may queries also, where a query is defined as an input output combination where the input
causes the output to be generated almost immediately. Each unique input output pair is counted as an
external inquiry type. a query is unique if it differ from other in format of input or output or if it requires
different processing .for external output type, respectively .the query complexity is the larger of the two.
Once the counts for all five different types are known for all three different complexity classes, the raw
or unadjusted function point (UFP) can be computed as a weighted sum as follows:
Where I reflects the row and j reflects the column, wij is the entry in the ithrow and jth column of the
table and cij is the count of the number of element of type that have been classified as having the
complexity corresponding to column j,
Once the UFP is obtained, it is adjusted for the environment complexity. For this, 14 different
characteristics of the system are given. These are data communication, distributed processing,
performance objective, operation configuration load, transaction rate, on line data entry, end user
efficiency, on line update, complex processing logic, re-usability, installation ease, operational ease,
multiple sites, and desire to facilitate change, the degree of each of these factor is taken to be from 1 to
5,representing the six different level,
External Input 3 4 6
External Output 4 5 7
External Inquiry 3 4 6
Caf=0.65+0.01N
With this equation, the value of CAf ranges between 0.65and 1.35. The delivered function points
(DFP)
Are simply computed by multiplying the UFP by CAF. That is:
As we can see, by adjustment for environment complexity, the DFP can differ from the UFP at
most by at 35%. The final function is the computed DFP.
OBJECTIVE: Suggest an action plan for the following risk without compromising the project,
process or product parameters.
SOLUTION:
a) The two people have full knowledge in their field. They have only language skill problem.
So shifting them to other department will create shortage of personnel. Taking two new
appointments will increase cost. Some ways to manage this risk is to get top talent possible
to match the needs of the project with skills of available personnel. Some key personnel
for critical areas of the project should be appointed. In this case to maintain the budget
proper training should be given to these two people according to project.
b) If project depends on these H/W & S/W either to be provided by client or to be procured,
the project runs some risk. Schedule will be disturbed by the late delivery. By the time
when they are available, project will also suffer if quality of these components is poor or
components turns out to be incompatible with the project component or with the
environment in which s/W is developed.
c) This type of risk occurs if requirement analysis is not done properly and if development
begins too early or there is improper user interface is developed. To reduce this type of
risk proper SRS and User interface should be prepared in advance. This risk requires
extension rework of user interface later. This need adding some features is S/W for this
requirement changes should be applied. This affects the cost and schedule.
d) Staff should be given proper training according to new technology. Time to time inspect ion
and compatibility analysis should be done.
Objective: Implement a Testing strategy for the following software development cases:
(a) Rule based deterministic closed large but simple payroll system for a company.
(b) Development or a customer relation management system lor a retail distribution chain. The retail
organization is not sure about the scope, and failure feature.
(c) Modification to existing order processing system for a multi-location, multi-product company.
SOLUTION:
To perform testing in a planned and systematic manner, software testing strategy is developed. A testing
strategy is used to identify the levels of testing which are to be applied along with the methods, techniques, and
tools to be used during testing. This strategy also decides test cases, test specifications, test case decisions, and
puts them together for execution.
Developing a test strategy, which efficiently meets the requirements of an organization, is critical to the
success of software development in that organization. Therefore, a software testing strategy should contain
complete information about the procedure to perform testing and the purpose and requirements of testing.
The choice of software testing strategy is highly dependent on the nature of the developed software. For
example, if the software is highly data intensive then a strategy that checks structures and values properly to
ensure that all inputs given to the software are correct and complete should be developed. Similarly, if it is
transaction intensive then the strategy should be such that it is able to check the flow of all the transactions. The
design and architecture of the software are also useful in choosing testing strategy. A number of software testing
strategies are developed in the testing process. All these strategies provide the tester a template, which is used
for testing. Generally, all testing strategies have following characteristics.
Testing proceeds in an outward manner. It starts from testing the individual units, progresses to integrating these
units, and finally, moves to system testing.
Testing techniques used during different phases of software development are different.
Testing is conducted by the software developer and by an ITG.
Testing and debugging should not be used synonymously. However, any testing strategy must accommodate
debugging with itself.
Methodical testing strategy: It tests the functions and status of software according to the checklist, which is
based on user requirements. This strategy is also used to test the functionality, reliability, usability, and
performance of the software.
Process-oriented testing strategy: It tests the software according to already existing standards such as the
IEEE standards. In addition, it checks the functionality of the software by using automated testing tools.
Dynamic testing strategy: This tests the software after having a collective decision of the testing team. Along
with testing, this strategy provides information about the software such as test cases used for testing the errors
present in it.
Philosophical testing strategy: It tests the software assuming that any component of the software can stop
functioning anytime. It takes help from software developers, users and systems analysts to test the software.
A testing strategy should be developed with the intent to provide the most effective and efficient way of testing
the software. While developing a testing strategy, some questions arise such as: when and what type of testing is
to be done? What are the objectives of testing? Who is responsible for performing testing? What outputs are
produced as a result of testing? The inputs that should be available while developing a testing strategy are listed
below.
Hardware and S/W Requirements: Pentium 90-MHz or better, 2GB RAM, Windows 7 or above,
Ms-Word.
SOLUTION:
a) The software to be delivered should be of high quality and according to the needs of the
customers. Software development includes a series of steps known as a software development
life cycle. Each phase has a defined output, entry criteria and exit criteria. The entry criteria of
a phase specify the condition that the input to the phase should satisfy in order to initiate the
activities of that phase. The exit criteria specify the condition that the work product of this
phase should satisfy to terminate the activities of the phase. There are various models for
developing software, each having its own version. Following are the main steps to be followed
in each model:
2) Feasibility Study: depending on the results of the initial investigation, the survey is
expanded to the more detailed feasibility study. It is a test of a software proposal according to
its workability, impact on users, and effective use of resources it focuses on:
i) What are the users needs and how does new software meets them?
ii) What resources are available for given software? Is the problem worth solving?
iii) What is the impact on the organization?
It does the following studies:
4) Technical Feasibility: It studies that whether the new software is feasible or not mean all
the tools, developer, or the required environment is available or not. In future it can adopt
changes or not.
3) Software Design: It is first step in moving from the problem domain to the solution domain. Starting
with what is needed; design takes us toward how to satisfy the needs. Design activity is divided in two
parts: System design and detailed design. System design is also called top level design aims to identify the
modules that should be in the system, specifications of these modules and how they interact with other to
produce the result. At the end of design all the major data structure, file format, output formats and major
modules and their specifications are decided. Detailed design, the internal logic of the system is decided.
During this phase further details of data structures and algorithms of each module are decided logic is
specified in high level language. Design can be function oriented or object oriented.
4) Coding: the goal of the coding phase is to translate the design of the system into code in a given
programming language. During coding the focus should be on developing programs that are easy to read
and understand and not simply on developing programs that are easy to write. Simplicity and clarity should
be there. The coding affects the both testing and maintenance.
5) Testing: After coding phase computer programs are available for execution. For testing purpose. This
implies that testing not only has to uncover errors introduced during coding but also errors introduced
during previous phases.
Thus its goal is to uncover requirement, design and coding errors in the programs. The starting point of
testing is unit testing. In it a module is tested separately and is often performed by the coder himself. The
purpose is to exercise the different parts of the module code to detect coding errors. After this modules are
gradually integrated into subsystems which are then integrated to form the entire system. It finds the design
errors. So integration testing is performed.
After the system is put together system testing is performed .here the system is tested against the system
requirement to see if all the requirements are met and if the system performs as specified by the
requirements. Finally acceptance testing is performed to demonstrate to the client, real life data of the
client, the operation of the system.
TESTING
6)Maintenance: Software maintenance denotes the process of modifying a software product after it has
been delivers to the customer. Due to hardware obsolescence, the immortality of a software product and the
demand of the user community to see existing software products run on newer platforms, run in newer
environments and with enhanced features gives birth to the maintenance phase. When hardware changes
and a software product performs some low level functions maintenance is necessary. Whenever the
software support environment changes the software product requires rework to cope with new interface eg.,
when operating system changes the software product need to be maintained. It is needed due to following
reasons:
a) Corrective: it is necessary either to rectify some bugs observe while the system is in use
or to enhance the performance of the system.
b) Adaptive: A software product might need maintenance when the
MIET Mohri, Kurukshetra Page | 9
Software development
life cycle
Design Coding
System design
Detailed Design
before development of actual software, a working prototype of the system should be built first. the model
starts with an initial requirements gathering phase. A quick design is carried out and prototype model is
built using several shortcuts which involve inefficient or dummy functions. The prototype is submitted to
the customer for his evaluation. Based on user feedback requirements are refined. This cycle is continued
until the user approves the prototype. The actual system is then developed using waterfall model. The
code for model is not written. An important purpose is to make input format, message, reports and user
interface.
Customer
Customer Suggestions evaluation Acceptance by the
of customer
prototype
Design
Implement
Test
Maintain
c) Development of a process for a function is done using evolutionary model. The system is
first broken down into several modules or functional units that can be incrementally
implemented and delivered as in fig c. The developer first develops the core modules of the
system. This initial product is refined into increasing levels of capability by adding new
features. Each successive version of the product is functioning system capable of
performing some more useful work. It is useful only for large systems. But isis difficult to
divide problem into several functional units. Eg., as in fig c, to develop a function c. make
core module A, make additions in it to ,make B then finally add all the feature and
complete the function C.
A
A A
B
Hardware & S/W Requirements: Pentium 90-MHz or better, 2GB RAM, Windows7 or above, Ms-Word.
Solution:
Hospital management system has the following activities:
Connects people, processes and data in real time across all the hospital on a single platform.
Workflow routes documents and Information electronically.
Flexibility and Integration abilities manage change.
Customized Clinical data according to each Department, Laboratory etc
Access to Financial information and Performance indicators help in managing resources, costs and margins.
Fast and reliable information storage, querying and retrieval. Retrieval could be either for generation of reports
based on demographics, gender, and age or for research & library classification.
Features
Registration
every patient who approaches a hospital has to get registered prior to getting any consultation, treatment, and
investigations done from the hospital. Registration of patients involves accepting certain general and
demographic information about the patient and assigning a unique central registration number (CR No) to the
Patient.
Out-Patient-Management
The outpatient module deals with the entire gamut of activities pertaining to the management of out-patients. It
consists of the creating Patient Visit and storing details like complaints, history, clinical summary, provisional
diagnosis, drugs etc corresponding to each visit.
Pharmacy-Management
The Pharmacy Module deals with the maintenance of drugs and consumables in the hospital. The functions of
this module include, online drug prescription, inventory management of drugs, consumables and sutures.
Objective:-Draw three level DFDs for CLPS. Modularize the CLPS and structure them top-down
functional model.
Hardware and Software requirements:- Pentium 90-MHZ or better, 2GB RAM, Windows7 or above,
MS-Word.
CLPS offers a very high level of abstraction & a declarative nature with an extreme flexibility in the
design of the execution model. CLPS allows variable to be constrained rather than bound.
For eg. In the game of ladders & snake, there are many ways to reach the goal. Either by steps & by ladders.
There is no particular path defined to win the game.
Solution to CLPS can be derived from the KB(knowledge base).CLPS incorporates various constraints solving
algorithm for the constraints allowed in the language. CLPS combines elements of constraints satisfaction
algorithm, logic programming & deductive database.
The DFD (also known as the bubble chart) is a simple graphical notation that can be used to represent a system
in terms of the input data to the system, various processing carried out on these data and the output data
generated by the system.
The DFD model uses a very limited number of the primitive symbols to represent the function performed by a
system and data flow among the functions.
External Entity
Process
Data Flow
Data Store
Out Put
Example of a Restaurant
A restaurant owner feels that some amount of automation will help make her business more efficient. She also
believes that an automated system might be added attraction for the customers. So she wants to automate the
operation of her restaurant as much as possible. Here we will perform the analysis of this problem. Details
regarding interviews, questionnaires, or how the information was extracted are not described. First let us
identify the different parties involved.
Now we must draw a DFD that models the new system to be built. After many meetings and discussions with
restaurant owner, the following goals for the new system were established:
Automate much of the order processing and billing.
Automate accounting.
Make supply ordering more accurate so that leftovers at the end of the day are minimized and the orders
that cannot be satisfied due to no availability are also minimized. This was currently being done without a
careful analysis of sales.
The owner also suspects that the staff might be stealing/eating some food/supplies. She wants the new
system to help detect and reduce this.
The owner would also like to have statistics about sales of different items.
With these goals, we can define the boundaries for the change in DFD. The DFD is largely self-explanatory.
The major files in the system are: supplies file, accounting file, order file and the start menu. Note that the
processes are consistent in that the input given to them are sufficient to produce the outputs.
The definitions of the different data flows and files are self-explanatory. Once this DFD and the data
dictionary have been approved by the restaurant owner, the activity of understanding the problem is
complete. After taking with the restaurant owner the man machine boundary was also defined (it is shown
in the DFD). Now remain such tasks as determining the details requirement of each bubble shown in the
DFD, determining the non-functional requirements, deciding codes for that task to perform can be done
with the help of DFD.
Hardware and Software requirements:- Pentium 90-MHZ or better, 2GB RAM, Windows7 or above,
MS-Word.
Task Analysis:-
Task analysis analyzes what a user is required to do in terms of actions and/or cognitive processes to achieve a
task. A detailed task analysis can be constructed to understand the current system and the information flows
within it. These information flows are important to the maintenance of the existing system and must be
incorporated or substituted in new system. Task analysis makes it possible to design and allocate tasks
appropriately within the new system. The functions to be included within the system and the user interface can
then be accurately specified.
The aim of high level task decomposition is to decompose the high level tasks and break them down into their
constituent subtasks and operations. This will show an overall structure of main user tasks. At a lower level it
may be desirable to show the task flows, decision processes and even screen layouts.
Enquiry:-
Officer will answer all the questions of the passengers asked regarding ticket reservation. In this he tells about
the train name, train no., time of boarding etc and help the passenger to fill up the ticket reservation form
according to the requirements of the passengers. All the queries are made clear to the passengers.
Train Information:-
Train information includes the information regarding the train whether the train is super fast or an express train
and all the trains which are going to the destination from the source of the passengers. It also includes the
queries of boarding and reaching time at the destination. With the help of the train information the passenger
can easily fill the railway ticket reservation form.
Ticket Window:-
At the ticket window passenger will give the reservation form. Officer will give the ticket if there is seat in that
train on the required day. If there is no seat available he will tell the passenger you are getting so and so waiting
no. in this train. If the passenger wants then he will give the waiting no. Ticket otherwise he will suggest him
for other trains which are going to the same destination and give the ticket according to the satisfaction of the
passenger.
Ticket:-
In this section we can say that thatwhether the passenger got the ticket reserved or waiting.In which class he
gets the seats if he got a reserved ticket than simply get the train on the desired day otherwise he has to
check.The waiting no. If his no. is confined than he will get a seat otherwise he has to travel in a general class
coach or can cancel the ticket.
Settlement:-
According to the rules and regulation of the insurance company officer will proceed for the further verification
at the settlement table. As described above according to the category of the case he will asks the question. He
will verify according to the requirement of the insurance company. After the discussion of the case the
insurance settlement officer he will decide whether the case is approved for the insurance claim or not. If the
case had been approved by the officer than the company will do its own formalities and pay the amount
according to their insurance scheme.
Claim:-
Settlement officer after hearing the views and verifying the documents decide whether the case is approved for
the claim or not. So, after deciding that case is approved for the insurance claim or not, if case is approved for
the claim than the amount will be paid otherwise will be closed after proving that the case is invalid.
Amount Paid:-
At last after all the discussions made at the settlement table. For those cases which are approved for the claim of
the insurance, it is checked that whether the appropriate amount is paid or not.
General Life
Vehicle Insurance
Insurance Insurance
SETTLEMENT
Amount
Claim
Paid
After purchasing a car customer can have many queries related to the car. They may be technical as well as
general queries.We make task flow diagram in fig.( c) to explain the queries of the car.
With the help of task flow diagram we can easily understand the problem by decomposing.Firstaf all the queries
are categorized according to the technical and general queries.Further we divide them according to their
level.Following of thr levels of the task flow diagram.
Technical Queries:-
In this category we have the queries which are related to the technical problem. Under this category one can
have the queries about the mileage, top speed and wheel balancing etc. One can ask about the current mileage
and mileage after first servicing. He may ask about the queries related to the wheel balancing. After how much
kilometers one can go for the wheel balancing, also about the top speed the car on which it will give the better
mileage. So one can have many more queries related to the technical issues.
General Queries:-
In the general queries one can have many queries related to the accessories and its features. In this we can have
the queries related to the accessories like stereo system, safety guards, air bags etc. We can ask about any effect
on the car due to the respective accessories. We can ask about the stereo system in the car, how it is going to
effect the battery and also can ask about the time period of time forfilling up of water in the battery. One can
have the queries on the safety guards like air bags.Customer can also ask about queries related to the alloy
wheel of the car.In this way we can study the queries of a car with help of task flow diagram.
QUERIES
Technical General
Safety
Alloys
Guards
Stereo
System