Thursday 23 October 2014
Tuesday 21 October 2014
SQA
Software Quality Assurance
Rishabh Baid
Graduate Student
MATS University
School of Information Technology
Email: rishabhbaid96@gmail.com
Abstract
Software Quality Assurance (SQA) involves the entire software
development process - monitoring and improving the process, making
sure that any agreed-upon standards and procedures are followed, and
ensuring that problems are found and dealt with. It's aimed towards
prevention and if followed will result in the production of quality
software. This paper emphasizes the importance of a quality process
and also discusses about the ways in which it could be achieved.
1 Introduction
Though billions of dollars are spent trying to develop quality
software, software bugs are very common. For most computer systems,
the cost of software constitutes a major part of the cost of the
system. Since software is so important and valuable, if software
development process lacks quality, then the software that's developed
will surely lack quality. "Software Quality Assurance (SQA) involves
the entire software development PROCESS - monitoring and improving the
process, making sure that any agreed-upon standards and procedures are
followed, and ensuring that problems are found and dealt with. It is
oriented towards prevention [1]". Software Quality Assurance is aimed
at developing a sound software development methodology that will
produce quality software.
2 Importance of SQA
There is an increasing use of software, in all walks of life. From
electronic devices like watches, and cell phones to applications like
ecommerce, banking, medical and what not? Computer Systems are
omnipresent and all computers run some software. So, software is
omnipresent. Due to the widespread acceptance, and use of software
systems, in various areas, software bugs are proving to be costly, and
sometimes fatal. The Sustainable Computing Consortium, a collaboration
of major corporate IT users, university researchers and government
agencies, estimates that buggy or flawed software cost businesses $175
billion worldwide in 2001 [3]. Interested readers are referred to [1]
for a list of some of the recent, major computer system failures,
caused by software bugs, and its consequences. Bugs have affected
banking systems, stock exchanges, medical institutions, educational
institutions and even the Social Security Administration. Most bugs,
encountered during software development, can be avoided, by adopting a
sound software development process, and having strict software quality
control using Software Quality Assurance. The process of SQA is
comparable to Software Testing.
3 Software Quality Assurance VS Software Testing
Software Testing involves operating a system, or an application, under
controlled conditions, and evaluating the results. In most cases,
software testing will involve the development of a test bed, which
tests the given software, upon a set of test cases. The test bed will
feed the test input to the software system, get the result that's
generated by the software system, and compares the generated result
with the expected result. If the generated result is same as the
expected result, then the software is bug free else, it has bugs that
need to be fixed.
Software testing is normally carried out under controlled conditions.
The controlled conditions should include both normal and abnormal
conditions. The aim of testing is to try to break the software, and
find the bugs in it. Successful testing will discover all the bugs in
the software. Developing automated test tools to perform testing is an
active area of research. Testing is oriented towards 'detection' of
bugs in the software (An interesting article that discusses about how
extensive testing should be can be found in [4]). On the other hand,
SQA is aimed at avoiding bugs.
Software Quality Assurance is oriented towards 'prevention' of bugs in
the software, by following a software development methodology. SQA is
more concerned with developing a quality process for software
development, which will prevent the generation of bugs, and will
result in the production of quality software. SQA, when practiced,
makes sure that all the standards are followed, and that all the
problems that arise during development are detected and are dealt
with. Both SQA and Software testing are non- trivial tasks.
Software Quality Assurance is more challenging than Software Testing
because, solving problems is a high-visibility process; preventing
problems is a low-visibility process. During Software Testing, we know
what the problem is, and we are trying to fix the problem, which is
easier than, preventing the problem before it occurred, or even showed
signs of occurrence.
Given the importance of software testing and SQA is one is left
wondering why is software so error prone. Why do we always have
software bugs?
4 Reasons for Software Bugs
Microsoft Chief Executive, Steve Ballmer said that any code of
significant scope and power will have bugs in it. And only 1% of bugs
in MS Software is causing half of all reported errors [2].
Find and fix 1% of your software bugs, and 90% of your system problems
go away, say experts [3].
The term "Software Crisis" [10] is used in the software industry to
emphasize the complexity in developing quality software. There are
five common problems in the software development process. They are
miscommunication, software complexity, programming errors, changing
requirements and unrealistic schedule [1].
• Miscommunication: There is widespread miscommunication of
information during all the phases of software development, because
humans tend to assume and misinterpret a lot of things when
communicating.
• Software Complexity: Any software, that's developed to serve some
useful purpose, is enormously complex and no single person can fully
understand it [2].
• Programming Errors: Software is created by people, and people are
inherently prone to making errors. So, software bugs are also created
due to programming errors.
• Changing requirements: Software functionality changes, when the
requirements change. When we have a system with rapidly changing
requirements, additional functionality that's added to the system, can
affect the already existing modules in unforeseen ways. High level of
interdependencies between the modules, makes the system error prone.
• Time pressure and deadlines: The software development industry is
highly competitive, and schedule slippages are not acceptable. Some
projects have unrealistic schedules, which make the development
methodology far from perfect and the developed software lacks quality.
Given these problems, it's apparent that software bugs are very
common. One is surely left wondering, "Did any one do anything to
reduce software bugs?" and make software more reliable. The answer is
"yes". The next section discusses one such successful attempt.
5 Capability Maturity Model (CMM)
The 'Software Engineering Institute' (SEI) [5] at Carnegie-Mellon
University, was initiated by the U.S. Defense Department, to help
improve the software development processes. The SEI came up with a
model with five levels. These levels are used to gauge the maturity of
a software development organization. The CMM model was mainly aimed at
making sure that organizations, which bid for contracts with the US
Department of Defense (DOD), followed a good process, and developed
quality software. Organizations receive CMM rankings, by undergoing
assessment by qualified auditors. Any organization, that does a
contract for the DOD, must reach at least level 3 in the CMM model
[1].
The five levels quantify the software development methodology,
followed by the organization. The following subsection will discuss on
what ratings at each level mean.
5.1 Level 1 - Initial or chaotic
Level 1 means that the software development methodology, followed by
an organization is in its novice stage, and is filled with chaos, and
periodic panics. Due to lack of any methodology, heroic effort is
required by individuals, to successfully complete projects. No
software process is in place, and even if the organization meets with
success in a project, successes may not be repeatable in other
projects. [1]
5.2 Level 2 – Repeatable
Level 2 in the CMM model means that, some software development process
is in place, and is being followed. Software project tracking,
requirements management, realistic planning, and
configuration management are part of the process in place. The success
achieved by the organization in a project is repeatable in other
projects. [1]
5.3 Level 3 – Defined
Level 3 in the model signifies that standard software development, and
maintenance processes are integrated throughout an organization. It
also means that, a Software Engineering Process Group is in place, to
oversee software processes, and training programs are used to ensure
understanding, and compliance. Any organization that does contracts
for the US Department of defense, must reach this level. [1]
5.4 Level 4 – Managed
If an organization reaches level 4 in the CMM model, then it means
that metrics are used, to track productivity, processes, and products.
Project performance is predictable, and quality is
consistently high. [1]
5.5 Level 5 – Optimized
At level 5 of the CMM model, the focus is on continuous process
improvement. The impact of new processes, and
technologies, can be predicted, and effectively implemented when
required. Moreover, as and when required, the software development
methodology that's practiced is optimized to suit the changing needs.
[1]
Organizations which comply with the CMM process (Level 3 and higher);
will surely produce quality software, when compared to organizations
at lower levels of the model. Software developed by organizations,
that have attained level 3, or higher, is less likely to be error
prone. Despite its advantages, CMM also has some disadvantages.
CMM describes what an organization should have, does not say how to
get there. Also, a clearly defined process is not equal to a good
process. For a discussion on the drawbacks of CMM refer [12].
CMM is not the only methodology, that's in place to improve the
software development process. There are also other approaches
suggested by IEEE, ANSI and the ISO [1]. But the CMM model is the most
popular, and is an industry standard, with wide spread use and
acceptance.
6 Conclusion
Software development is complex, and is error prone. Many problems
that are faced during software development can be tackled, by adopting
a good software development process. From our discussion, it's
apparent that good processes are essential. The software industry is
still learning, about good processes for software development. CMM was
developed, to assess, and to give organizations, a framework to
improve. Despite some flaws, CMM is a significant contribution to the
software industry. The second version of CMM (CMMv2) is currently in
progress at the Software Engineering Institute at the Carnegie Mellon
University.
7 References:
1. Rick Hower's "Software QA and Testing Resource Center" (Source:
www.software qatest.com)
2. Any software code will have bugs- Microsoft (Source:
http://www.ciol.com/content/ news/repts/102100302.asp)
3. Biting Back (Source:
http://www.computerworld.com/softwaretopics/software
/appdev/story/0,10801,77381,00.html)
4. Finding Your Sweet Spot (Source:
http://www.computerworld.com/softwaretopics/ software/story/0,
10801,77374,00.html)
5. Carnegie Mellon Software Engineering Institute (Source:
http://www.sei.cmu.edu/)
6. Resources for Busy Testers (Source: http://www.qacity.com/front.htm)
7. Software Testing Hotlist (Source: http://www.io.com/~wazmo/qa/)
8. Storm (Source: http://www.mtsu.edu/~storm/)
9. Internet/Software Quality Hotlist (Source:
http://www.soft.com/Institute/HotList/)
10. The Software Crisis (Source:
http://www.unt.edu/benchmarks/archives/1999/july99 /crisis.htm)
11. Software Testing and Quality Assurance (Source:
http://www.software-quality-assurance.info/)
12. CMM information (source:
http://www.cs.concordia.ca/~faculty/paquet /teaching/342/CMM.ppt)
13. Bca Notes (source : http://bcaraipur.blogspot.in)
Rishabh Baid
Graduate Student
MATS University
School of Information Technology
Email: rishabhbaid96@gmail.com
Abstract
Software Quality Assurance (SQA) involves the entire software
development process - monitoring and improving the process, making
sure that any agreed-upon standards and procedures are followed, and
ensuring that problems are found and dealt with. It's aimed towards
prevention and if followed will result in the production of quality
software. This paper emphasizes the importance of a quality process
and also discusses about the ways in which it could be achieved.
1 Introduction
Though billions of dollars are spent trying to develop quality
software, software bugs are very common. For most computer systems,
the cost of software constitutes a major part of the cost of the
system. Since software is so important and valuable, if software
development process lacks quality, then the software that's developed
will surely lack quality. "Software Quality Assurance (SQA) involves
the entire software development PROCESS - monitoring and improving the
process, making sure that any agreed-upon standards and procedures are
followed, and ensuring that problems are found and dealt with. It is
oriented towards prevention [1]". Software Quality Assurance is aimed
at developing a sound software development methodology that will
produce quality software.
2 Importance of SQA
There is an increasing use of software, in all walks of life. From
electronic devices like watches, and cell phones to applications like
ecommerce, banking, medical and what not? Computer Systems are
omnipresent and all computers run some software. So, software is
omnipresent. Due to the widespread acceptance, and use of software
systems, in various areas, software bugs are proving to be costly, and
sometimes fatal. The Sustainable Computing Consortium, a collaboration
of major corporate IT users, university researchers and government
agencies, estimates that buggy or flawed software cost businesses $175
billion worldwide in 2001 [3]. Interested readers are referred to [1]
for a list of some of the recent, major computer system failures,
caused by software bugs, and its consequences. Bugs have affected
banking systems, stock exchanges, medical institutions, educational
institutions and even the Social Security Administration. Most bugs,
encountered during software development, can be avoided, by adopting a
sound software development process, and having strict software quality
control using Software Quality Assurance. The process of SQA is
comparable to Software Testing.
3 Software Quality Assurance VS Software Testing
Software Testing involves operating a system, or an application, under
controlled conditions, and evaluating the results. In most cases,
software testing will involve the development of a test bed, which
tests the given software, upon a set of test cases. The test bed will
feed the test input to the software system, get the result that's
generated by the software system, and compares the generated result
with the expected result. If the generated result is same as the
expected result, then the software is bug free else, it has bugs that
need to be fixed.
Software testing is normally carried out under controlled conditions.
The controlled conditions should include both normal and abnormal
conditions. The aim of testing is to try to break the software, and
find the bugs in it. Successful testing will discover all the bugs in
the software. Developing automated test tools to perform testing is an
active area of research. Testing is oriented towards 'detection' of
bugs in the software (An interesting article that discusses about how
extensive testing should be can be found in [4]). On the other hand,
SQA is aimed at avoiding bugs.
Software Quality Assurance is oriented towards 'prevention' of bugs in
the software, by following a software development methodology. SQA is
more concerned with developing a quality process for software
development, which will prevent the generation of bugs, and will
result in the production of quality software. SQA, when practiced,
makes sure that all the standards are followed, and that all the
problems that arise during development are detected and are dealt
with. Both SQA and Software testing are non- trivial tasks.
Software Quality Assurance is more challenging than Software Testing
because, solving problems is a high-visibility process; preventing
problems is a low-visibility process. During Software Testing, we know
what the problem is, and we are trying to fix the problem, which is
easier than, preventing the problem before it occurred, or even showed
signs of occurrence.
Given the importance of software testing and SQA is one is left
wondering why is software so error prone. Why do we always have
software bugs?
4 Reasons for Software Bugs
Microsoft Chief Executive, Steve Ballmer said that any code of
significant scope and power will have bugs in it. And only 1% of bugs
in MS Software is causing half of all reported errors [2].
Find and fix 1% of your software bugs, and 90% of your system problems
go away, say experts [3].
The term "Software Crisis" [10] is used in the software industry to
emphasize the complexity in developing quality software. There are
five common problems in the software development process. They are
miscommunication, software complexity, programming errors, changing
requirements and unrealistic schedule [1].
• Miscommunication: There is widespread miscommunication of
information during all the phases of software development, because
humans tend to assume and misinterpret a lot of things when
communicating.
• Software Complexity: Any software, that's developed to serve some
useful purpose, is enormously complex and no single person can fully
understand it [2].
• Programming Errors: Software is created by people, and people are
inherently prone to making errors. So, software bugs are also created
due to programming errors.
• Changing requirements: Software functionality changes, when the
requirements change. When we have a system with rapidly changing
requirements, additional functionality that's added to the system, can
affect the already existing modules in unforeseen ways. High level of
interdependencies between the modules, makes the system error prone.
• Time pressure and deadlines: The software development industry is
highly competitive, and schedule slippages are not acceptable. Some
projects have unrealistic schedules, which make the development
methodology far from perfect and the developed software lacks quality.
Given these problems, it's apparent that software bugs are very
common. One is surely left wondering, "Did any one do anything to
reduce software bugs?" and make software more reliable. The answer is
"yes". The next section discusses one such successful attempt.
5 Capability Maturity Model (CMM)
The 'Software Engineering Institute' (SEI) [5] at Carnegie-Mellon
University, was initiated by the U.S. Defense Department, to help
improve the software development processes. The SEI came up with a
model with five levels. These levels are used to gauge the maturity of
a software development organization. The CMM model was mainly aimed at
making sure that organizations, which bid for contracts with the US
Department of Defense (DOD), followed a good process, and developed
quality software. Organizations receive CMM rankings, by undergoing
assessment by qualified auditors. Any organization, that does a
contract for the DOD, must reach at least level 3 in the CMM model
[1].
The five levels quantify the software development methodology,
followed by the organization. The following subsection will discuss on
what ratings at each level mean.
5.1 Level 1 - Initial or chaotic
Level 1 means that the software development methodology, followed by
an organization is in its novice stage, and is filled with chaos, and
periodic panics. Due to lack of any methodology, heroic effort is
required by individuals, to successfully complete projects. No
software process is in place, and even if the organization meets with
success in a project, successes may not be repeatable in other
projects. [1]
5.2 Level 2 – Repeatable
Level 2 in the CMM model means that, some software development process
is in place, and is being followed. Software project tracking,
requirements management, realistic planning, and
configuration management are part of the process in place. The success
achieved by the organization in a project is repeatable in other
projects. [1]
5.3 Level 3 – Defined
Level 3 in the model signifies that standard software development, and
maintenance processes are integrated throughout an organization. It
also means that, a Software Engineering Process Group is in place, to
oversee software processes, and training programs are used to ensure
understanding, and compliance. Any organization that does contracts
for the US Department of defense, must reach this level. [1]
5.4 Level 4 – Managed
If an organization reaches level 4 in the CMM model, then it means
that metrics are used, to track productivity, processes, and products.
Project performance is predictable, and quality is
consistently high. [1]
5.5 Level 5 – Optimized
At level 5 of the CMM model, the focus is on continuous process
improvement. The impact of new processes, and
technologies, can be predicted, and effectively implemented when
required. Moreover, as and when required, the software development
methodology that's practiced is optimized to suit the changing needs.
[1]
Organizations which comply with the CMM process (Level 3 and higher);
will surely produce quality software, when compared to organizations
at lower levels of the model. Software developed by organizations,
that have attained level 3, or higher, is less likely to be error
prone. Despite its advantages, CMM also has some disadvantages.
CMM describes what an organization should have, does not say how to
get there. Also, a clearly defined process is not equal to a good
process. For a discussion on the drawbacks of CMM refer [12].
CMM is not the only methodology, that's in place to improve the
software development process. There are also other approaches
suggested by IEEE, ANSI and the ISO [1]. But the CMM model is the most
popular, and is an industry standard, with wide spread use and
acceptance.
6 Conclusion
Software development is complex, and is error prone. Many problems
that are faced during software development can be tackled, by adopting
a good software development process. From our discussion, it's
apparent that good processes are essential. The software industry is
still learning, about good processes for software development. CMM was
developed, to assess, and to give organizations, a framework to
improve. Despite some flaws, CMM is a significant contribution to the
software industry. The second version of CMM (CMMv2) is currently in
progress at the Software Engineering Institute at the Carnegie Mellon
University.
7 References:
1. Rick Hower's "Software QA and Testing Resource Center" (Source:
www.software qatest.com)
2. Any software code will have bugs- Microsoft (Source:
http://www.ciol.com/content/ news/repts/102100302.asp)
3. Biting Back (Source:
http://www.computerworld.com/softwaretopics/software
/appdev/story/0,10801,77381,00.html)
4. Finding Your Sweet Spot (Source:
http://www.computerworld.com/softwaretopics/ software/story/0,
10801,77374,00.html)
5. Carnegie Mellon Software Engineering Institute (Source:
http://www.sei.cmu.edu/)
6. Resources for Busy Testers (Source: http://www.qacity.com/front.htm)
7. Software Testing Hotlist (Source: http://www.io.com/~wazmo/qa/)
8. Storm (Source: http://www.mtsu.edu/~storm/)
9. Internet/Software Quality Hotlist (Source:
http://www.soft.com/Institute/HotList/)
10. The Software Crisis (Source:
http://www.unt.edu/benchmarks/archives/1999/july99 /crisis.htm)
11. Software Testing and Quality Assurance (Source:
http://www.software-quality-assurance.info/)
12. CMM information (source:
http://www.cs.concordia.ca/~faculty/paquet /teaching/342/CMM.ppt)
13. Bca Notes (source : http://bcaraipur.blogspot.in)
Thursday 16 October 2014
SAD
Sad part _II
__________ spend most of the time in between stages of the SDLC, talking with end user, gathering information, documentation system, and proposing solution
A. System analyst
B. Project Managers.
C. Network engineers
D. Data base administrator
_______ is the process of translating a task into series of command that a computer will use to perform that task
A. Project design
B.Installation
C.System analysis
D. Programming
translating the problem statement into series of sequential step describing, what the program must do is known as
A. Coding
B. Debbuging
C. Creating the algorithm
D. writing documentation
Among the attribute of system analyst the following are the most important
A. knowledge of computer system and currently available hardware
B. good interpersonal relation.
C. broad knowledge about various organisation
D. Very good accountancy knowledge
(i)a,c,d
(ii)a and b
(iii)a,b, and d
(iv) a,b,c
Sad part-I
Requirement specification os carried out
A. After requirement are determined
B. Before requirement are determined.
C. Simultaneously with requirements determination.
D. Independent of requirement determination.
The main objective of feasibility study is
A. To assess if it possible to meet the requirement specification.
B. To assess if it possible to meet the requirement Specified subject to constraints of budget , human resource and hardware.
C. To assit the management in implementing the desired system.
D. To remove bottlenecks in implementing the desired system.
System test plan is specified
A. When the final specification are drawn up.
B.During feasibility study.
C. During the requirement specification stage .
D.During system study stage.
Good system design prevent data entry on by
(i) developing good form with plenty of space to write in block capitals.
(ii) By giving clear induction to user on how to fill form.
(iii) Reddening keystrokes of an operator.
(iv) Designing good keyboard
A.i,iii,ii
B.i,ii,iv
C.i,ii
D.iv,iii
The organised process or set of steps that need to be followed to develop an information system is known as the :-
A. Analytical cycle
B. Design cycle
C. Program specification
D. System development life cycle
Enhancement, update, and bug fixes are done during the_________
A. Maintenance and Evaluation
B. Problem / opportunity identification
C. Design
D. Development and documentation
s
Multimedia MCQ
Q.1) ____________ refers to any
type of application or presentation
that involves more than one type of media, such as text, graphics,
video, animation, and sound.
A. An executable file
B. Desktop
publishing
C. Multimedia
D. Hypertext
Q.2) One of the disadvantages
of multimedia is:
A. Cost
B. adaptability
C. usability
D. relativity
Q.3) The text color in a
presentation should contrast with
the ________ color.
A. CPU
B. Frame
C. Stack
D. Background
Q.4) Images included in many
software titles are called _________.
A. Clipart
B. Popups
C. .jpg files
D. .tiff files
Q.5) A smaller version of an
image is called a:
A. Clipart
B. Bitmap
C. Portable network
graphic
D. Thumbnail
Q.6) The process of planning
your multimedia presentation is
known as a:
A. Design
B. Storyboard
C. Development
D. Layout
Q.7) In slide ______ view, you see
the entire presentation displayed
in miniature. This view is used to
arrange the slides in your
presentation, as well as, to add
animations, transitions and timing.
A. Arranger
B. Creator
C. Shaper
D. Sorter
Q.8) The slide ________ controls
text characteristics, background
color and special effects, such as
shadowing and bullet style.
A. Presentation
B. Master
C. Show
D. Sorter
Q.9) Designed to create a
particular look, a __________ contains color schemes, slide and title masters with custom formatting
and fonts styles.
A. Template
B. Presentation
C. Slide
D. Background
Q.10) Adding _________ to objects
on your slides not only controls the flow of information, but adds
interest to your presentation.
A. Background
B. Transition
C. Animation
D. Popups
Q.11) The ________ master controls
the format and placement of the
titles and text you type on slides,
as well as, background items and
graphics you want to appear on
every slide.
A. Slide
B. Copyright
C. Layout
D. Design
Q.12) The first slide in a
presentation is usually reserved for the _________.
A. Introduction
B. Author
C. Master
D. Title
Q.13) ______________ is the special
effect used to introduce each slide
in a slide presentation.
A. Animation
B. Bulleting
C. Transition
D. Mapping
Q.14) Notes that include the slide
as well as key comments and
points you may want to emphasis
while you present your slide show
are know as:
A. Speaker handouts
B. Speaker notes
C. Sstudent notes
D. Cheat sheet
Q.15) A ________ displays a list of
commands and usually appears in
the toolbar at the top of the
screen.
A. View
B. Menu
C. Kit
D. List
Q.16) Slide and title masters
contain ___________ that reserve
spaces for text and footers such as
date, time and slide number.
A. Reservations
B. Placeholders
C. Spaces
D. Documents
Q.17) Changing the appearance of
your slide _________ can alter the
slide’s color, shade, pattern, or
texture.
A. Background
B. Foreground
C. Watermark
D. Design
Q.18) A ____________ is a series of
slides displayed in a particular
sequence.
A. Placeholder
B. Layout
C. Template
D. Slide show
Q.19) Quick access to frequently
used commands can be found in
the ________ toolbar.
A. View
B. Drawing
C. Kit
D. Menu
Q.20) A ____________ can be added
to your presentation and then used to go to a variety of locations ---- for example, a web address, an e-mail address, a custom show or document, just to name a few.
A. Menulink
B. Hyperlink
C. Toollink
D. Super Link
Q.21) A process of changing the
position of an object in a straight
line path from one coordinate
location to another is called______
A. Translation
B. Rotation
C. Motion
D. Both b and c
Q.22. A multimedia file
a) Is same as any other
regular file.
b) Must be accessed at
specific rate.
c) Stored on remote server can not be delivered to its client.
d) None of the mentioned.
Q.23 Which one of the
following is the
characteristic of a
multimedia system?
a) High storage
b) High data rates
c) Both (a) and (b)
d) None of the mentioned
Q.24 In which type of
streaming multimedia file
is delivered to the client,
but not shared?
a) Real-time streaming
b) Progressive download
c) Compression
d) None of the mentioned
Q.25 The delay that occur during the playback of a
stream is called
a) Stream delay
b) Playback delay
c) Jitter
d) Event delay
Q.26. Multimedia system
require hard real time
scheduling
a) To ensure critical tasks
will be serviced within
timing deadlines
b) To deliver the media
file to the client
c) To minimize the delay
d) For security
Wednesday 15 October 2014
Data Structure MCQ
Question's
• the name of array
• the data type of array
• the first data from the set to be stored
• the index set of the array
2. The complexity of the average case of an algorithm is
• Much more complicated to analyze than that of worst case
• Much more simpler to analyze than that of worst case
• Sometimes more complicated and some other times simpler than that of worst case
• None or above
3. Which of the following case does not exist in complexity theory
• Best case
• Worst case
• Average case
• Null case
4. The complexity of linear search algorithm is
• O(n)
• O(log n)
• O(n2)
• O(n log n)
5. The complexity of merge sort algorithm is
• O(n)
• O(log n)
• O(n2)
• O(n log n)
6. Which of the following data structure is not linear data structure?
• Arrays
• Linked lists
• Both of above
• None of above
7. Linked lists are best suited
• for relatively permanent collections of data
• for the size of the structure and the data in the structure are constantly changing
• for both of above situation
• for none of above situation
8. The elements of an array are stored successively in memory cells because
• by this way computer can keep track only the address of the first element and the addresses of other elements can be calculated
• the architecture of computer memory does not allow arrays to store other than serially
• both of above
• none of above
9. Arrays are best data structures
• for relatively permanent collections of data
• for the size of the structure and the data in the structure are constantly changing
• for both of above situation
• for none of above situation
10. Which of the following data structure is linear data structure?
• Trees
• Graphs
• Arrays
• None of above
11. The operation of processing each element in the list is known as
• Sorting
• Merging
• Inserting
• D. Traversal
12. The indirect change of the values of a variable in one module by another module is called
• internal change
• inter-module change
• side effect
• side-module update
13. The space factor when determining the efficiency of algorithm is measured by
• Counting the maximum memory needed by the algorithm
• Counting the minimum memory needed by the algorithm
• Counting the average memory needed by the algorithm
• Counting the maximum disk space needed by the algorithm
14. The time factor when determining the efficiency of algorithm is measured by
• Counting microseconds
• Counting the number of key operations
• Counting the number of statements
• Counting the kilobytes of algorithm
15. The complexity of Binary search algorithm is
• O(n)
• O(log )
• O(n2)
• O(n log n)
16. The Average case occur in linear search algorithm
• When Item is somewhere in the middle of the array
• When Item is not in the array at all
• When Item is the last element in the array
• When Item is the last element in the array or is not there at all
17. The Worst case occur in linear search algorithm when
• Item is somewhere in the middle of the array
• Item is not in the array at all
• Item is the last element in the array
• Item is the last element in the array or is not there at all
18. Two main measures for the efficiency of an algorithm are
• Processor and memory
• Complexity and capacity
• Time and space
• Data and space
19. The complexity of Bubble sort algorithm is
• O(n)
• O(log n)
• O(n2)
• O(n log n)
20. Finding the location of the element with a given value is:
• Traversal
• Search
• C. Sort
• D. None of above
Monday 13 October 2014
Software prototyping
Software prototyping
Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.
A prototype typically simulates only a few aspects of, and may be completely different from, the final product.
Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s.
Overview
The original purpose of a prototype is to allow users of the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions. Prototyping can also be used by end users to describe and prove requirements that have not been considered, and that can be a key factor in the commercial relationship between developers and their clients. Interaction design in particular makes heavy use of prototyping with that goal.
This process is in contrast with the 1960s and 1970s monolithic development cycle of building the entire program first and then working out any inconsistencies between design and implementation, which led to higher software costs and poor estimates of time and cost.[citation needed] The monolithic approach has been dubbed the "Slaying the (software) Dragon" technique, since it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone. Prototyping can also avoid the great expense and difficulty of changing a finished software product.
The practice of prototyping is one of the points Frederick P. Brooks makes in his 1975 book The Mythical Man-Month and his 10-year anniversary article No Silver Bullet.
An early example of large-scale software prototyping was the implementation of NYU's Ada/ED translator for the Ada programming language.[2] It was implemented in SETL with the intent of producing an executable semantic model for the Ada language, emphasizing clarity of design and user interface over speed and efficiency. The NYU Ada/ED system was the first validated Ada implementation, certified on April 11, 1983.
Outline of the prototyping process
The process of prototyping involves the following steps
1. Identify basic requirements
Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.
2.Develop Initial Prototype
The initial prototype is developed that includes only user interfaces. (See Horizontal Prototype, below)
3. Review
The customers, including end-users, examine the prototype and provide feedback on additions or changes.
4. Revise and Enhance the Prototype
Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 and #4 may be needed.
Dimensions of prototypes
Nielsen summarizes the various dimension of prototypes in his book Usability Engineering
Horizontal Prototype
A common term for a user interface prototype is the horizontal prototype. It provides a broad view of an entire system or subsystem, focusing on user interaction more than low-level system functionality, such as database access. Horizontal prototypes are useful for:
•Confirmation of user interface requirements and system scope
• Demonstration version of the system to obtain buy-in from the business
• Develop preliminary estimates of development time, cost and effort.
Vertical Prototype
A vertical prototype is a more complete elaboration of a single subsystem or function. It is useful for obtaining detailed requirements for a given function, with the following benefits:
• Refinement database design
• Obtain information on data volumes and system interface needs, for network sizing and performance engineering
• Clarifies complex requirements by drilling down to actual system functionality
Types of prototyping
Software prototyping has many variants. However, all the methods are in some way based on two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.
Throwaway prototyping
Also called close-ended prototyping.Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.
Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.
The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.
Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.
…it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models.
Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.
Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look.
Summary: In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are:
1.Write preliminary requirements
2.Design the prototype
3.User experiences/uses the prototype, specifies new requirements
4.Repeat if necessary
5.Write the final requirements
Evolutionary prototyping
Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.
When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.
"…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."
This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase.
For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most familiar frame of reference---where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.
Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.
"It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at all."
In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.
To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.
Incremental prototyping
The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.By the help of incremental prototyping we can reduce the time gap between user and software developer.
Extreme prototyping
Extreme Prototyping as a development process is used especially for developing web applications. Basically, it breaks down web development into three phases, each one based on the preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the second phase, the screens are programmed and fully functional using a simulated services layer. In the third phase, the services are implemented. The process is called Extreme Prototyping to draw attention to the second phase of the process, where a fully functional UI is developed with very little regard to the services other than their contract.
Advantages of prototyping
There are many advantages to using prototyping in software development – some tangible, some abstract.
Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers. Because changes cost exponentially more to implement as they are detected later in development, the early determination of what the user really wants can result in faster and less expensive software.
Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications.The presence of the prototype being examined by the user prevents many misunderstandings and miscommunications that occur when each side believe the other understands what they said. Since users know the problem domain better than anyone on the development team does, increased interaction can result in final product that has greater tangible and intangible quality. The final product is more likely to satisfy the users desire for look, feel and performance.
Disadvantages of prototyping
Using, or perhaps misusing, prototyping can also have disadvantages.
Insufficient analysis: The focus on a limited prototype can distract developers from properly analyzing the complete project. This can lead to overlooking better solutions, preparation of incomplete specifications or the conversion of limited prototypes into poorly engineered final projects that are hard to maintain. Further, since a prototype is limited in functionality it may not scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if developers are too focused on building a prototype as a model.
User confusion of prototype and finished system: Users can begin to think that a prototype, intended to be thrown away, is actually a final system that merely needs to be finished or polished. (They are, for example, often unaware of the effort needed to add error-checking and security features which a prototype may not have.) This can lead them to expect the prototype to accurately model the performance of the final system when this is not the intent of the developers. Users can also become attached to features that were included in a prototype for consideration and then removed from the specification for a final system. If users are able to require all proposed features be included in the final system this can lead to conflict.
Developer misunderstanding of user objectives: Developers may assume that users share their objectives (e.g. to deliver core functionality on time and within budget), without understanding wider commercial issues. For example, user representatives attending Enterprise software (e.g. PeopleSoft) events may have seen demonstrations of "transaction auditing" (where changes are logged and displayed in a difference grid view) without being told that this feature demands additional coding and often requires more hardware to handle extra database accesses. Users might believe they can demand auditing on every field, whereas developers might think this is feature creep because they have made assumptions about the extent of user requirements. If the developer has committed delivery before the user requirements were reviewed, developers are between a rock and a hard place, particularly if user management derives some advantage from their failure to implement requirements.
Developer attachment to prototype: Developers can also become attached to prototypes they have spent a great deal of effort producing; this can lead to problems like attempting to convert a limited prototype into a final system when it does not have an appropriate underlying architecture. (This may suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)
Excessive development time of the prototype: A key property to prototyping is the fact that it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try to develop a prototype that is too complex. When the prototype is thrown away the precisely developed requirements that it provides may not yield a sufficient increase in productivity to make up for the time spent developing the prototype. Users can become stuck in debates over details of the prototype, holding up the development team and delaying the final product.
Expense of implementing prototyping: the start up costs for building a development team focused on prototyping may be high. Many companies have development methodologies in place, and changing them can mean retraining, retooling, or both. Many companies tend to just jump into the prototyping without bothering to retrain their workers as much as they should.
A common problem with adopting prototyping technology is high expectations for productivity with insufficient effort behind the learning curve. In addition to training for the use of a prototyping technique, there is an often overlooked need for developing corporate and project specific underlying structure to support the technology. When this underlying structure is omitted, lower productivity can often result.
Best projects to use prototyping
It has been argued that prototyping, in some form or another, should be used all the time. However, prototyping is most beneficial in systems that will have many interactions with the users.
It has been found that prototyping is very effective in the analysis and design of on-line systems, especially for transaction processing, where the use of screen dialogs is much more in evidence. The greater the interaction between the computer and the user, the greater the benefit is that can be obtained from building a quick system and letting the user play with it.
Systems with little user interaction, such as batch processing or systems that mostly do calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.
Prototyping is especially good for designing good human-computer interfaces. "One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human-computer interface design."
Next Topic
Requirement Engineering :-
Requirement Engineering :-
Requirement Engineering is the systematic use of proven principle and approaches ,techniques ,language, and tool for the cost effective analysis, documentation and ongoing evolution of the user needs and specification of the external behaviour of a system or software to satisfy these user needs.
Both the software engineering and the customer take an active role in software Requirement Engineering . A set of activities i.e often referred to as analysis . Hence it is also called as Software Requirement Engineering.
Introduction to Analysis Concept And Principles
Introduction to Analysis Concept And Principles
After system and software engineering is completed , software engineering need to look at the rule of software in the proposed system for this purpose , Software Requirement Analysis(SRA) should be done.
Software Requirement Analysis(SRA) is needed to avoid creating a software product that fails to meet the customers needs.
It checks for the data , functional and behavioural requirement are gathered from the customer and refine to create a specification that can be used to design the system . Its worth product must be reviewed for clarity completeness and , consistency.
Click here-->Requirement Engineering :-
Saturday 11 October 2014
Sad assignment
Q1. What is system testing ?
Explain the different types of
system testing ?
Ans :-
System testing is the process of
evaluation a software item to detect differences between given input and expected output. Also to assess the feature of A software item. Testing assesses the quality of the product. System testing is a process that should be done during the development process. In other words system testing is a verification and validation process.
Verification:-
Verification is the process to make
sure the product satisfies the
conditions imposed at the start of
the development phase. In other
words, to make sure the product
behaves the way we want it to.
Validation:-
Validation is the process to make sure the product satisfies the specified requirements at the end of the development phase. In other words, to make sure the product is built as per customer requirements.
Basics of software testing
There are two basics of software
testing:-
1.Blackbox testing
2.Whitebox testing.
Blackbox Testing
Black box testing is a testing
technique that ignores the internal
mechanism of the system and
focuses on the output generated
against any input and execution of
the system. It is also called functional testing.
Whitebox Testing
White box testing is a testing
technique that takes into account
the internal mechanism of a system. It is also called structural testing and glass box testing.
Black box testing is often used for
validation and white box testing is
often used for verification.
Types of testing
There are many types of testing like
1.Unit Testing
2.Integration Testing
3.Functional Testing
4.System Testing
5.Stress Testing
6.Performance Testing
7.Usability Testing
8.Acceptance Testing
9.Regression Testing
10.Beta Testing
Unit Testing
Unit testing is the testing of an
individual unit or group of related
units. It falls under the class of
white box testing. It is often done
by the programmer to test that the unit he/she has implemented is producing expected output against given input.
Integration Testing
Integration testing is testing in
which a group of components are
combined to produce output. Also,
the interaction between software
and hardware is tested in
integration testing if software and
hardware components have any
relation. It may fall under both
white box testing and black box
testing.
Functional Testing
Functional testing is the testing to
ensure that the specified
functionality required in the system requirements works. It falls under the class of black box testing.
System Testing
System testing is the testing to
ensure that by putting the software in different environments (e.g., Operating Systems) it still works.
System testing is done with full
system implementation and
environment. It falls under the class of black box testing.
Stress Testing Stress testing is the testing to evaluate how system behaves under unfavorable conditions. Testing is conducted at beyond limits of the specifications. It falls under the class of black box testing.
Performance Testing
Performance testing is the testing to assess the speed and effectiveness of the system and to make sure it is generating results within a specified time as in performance requirements. It falls under th class of black box testing.
Usability Testing
Usability testing is performed to the perspective of the client, to evaluate how the GUI is user-friendly? How easily can the client learn? After learning how to use, how proficiently can the client perform? How pleasing is it to use its design? This falls under the class of black box testing.
Acceptance Testing:-
Acceptance testing is often done by the customer to ensure that the delivered product meets the
requirements and works as the
customer expected. It falls under
the class of black box testing.
Regression Testing Regression testing is the testing after modification of a system,
component, or a group of related
units to ensure that the modification is working correctly and is not damaging or imposing other modules to produce unexpected results. It falls under the class of black box testing.
Beta Testing
Beta testing is the testing which is
done by end users, a team outside
development, or publicly releasing
full pre-version of the product which is known as beta version. The aim of beta testing is to cover unexpected errors. It falls under the class of black box testing.
Q2. Explain the goal of quality assurance in SDLC? Explain level of SQA?
Ans:-
Following are the SQA Goals:-
• Requirements quality
o Ambiguity
o Completeness
o Volatility
o Traceability
o Model clarity
• Design quality
o Architectural integrity
o Component completeness
o Interface complexity
o Patterns
• Code quality
o Complexity
o Maintainability
o Understandability
o Reusability
o Documentation
• Quality control effectiveness
o Resource allocation
o Completion rate
o Review effectiveness
o Testing effectiveness
Following are the various levels of SQA:-
Level 1 - Initial or chaotic
Level 1 means that the software development methodology, followed by an organization is in its novice stage, and is filled with chaos, and periodic panics. Due to lack of any methodology, heroic effort is required by individuals, to successfully complete projects. No software process is in place, and even if the organization meets with success in a project, successes may not be repeatable in other projects.
Level 2 – Repeatable
Level 2 in the CMM model means that, some software development process is in place, and is being followed. Software project tracking, requirements management, realistic planning, and configuration management are part of the process in place. The success achieved by the organization in a project is repeatable in other projects.
Level 3 – Defined
Level 3 in the model signifies that standard software development, and maintenance processes are integrated throughout an organization. It also means that, a Software Engineering Process Group is in place, to oversee software processes, and training programs are used to ensure understanding, and compliance. Any organization that does contracts for the US Department of defense, must reach this level.
Level 4 – Managed
If an organization reaches level 4 in the CMM model, then it means that metrics are used, to track productivity, processes, and products. Project performance is predictable, and quality is consistently high. [1]
Level 5 – Optimized
At level 5 of the CMM model, the focus is on continuous process improvement. The impact of new processes, and technologies, can be predicted, and effectively implemented when required. Moreover, as and when required, the software development methodology that’s practiced is optimized to suit the changing needs.
Q3. Explain the
implementation and maintenance
of software system? ?
Deadline 18/10/14
Friday 10 October 2014
Multimedia assignment
1. Write steps for following :-
a. Recording Sound.
b. Increasing and decreasing volume of audio file .
c. Triming a audio file .
d. Adding echo to audio file .
e. Merging two septate audio file (sound mixing) .
f. Converting the file format from one audio to another .
2. Create a simple video using different still images and appropriate background sound use following effects,:-
1. Give title of the video.
2. Insert different title at different point of video.
3.Mute sound of video at particular point .
4.Use transition effects .
5.Convert one video format to other.
6.Shaking various properties of video.
For answers you can download the zip file
To extract .zip files you need
File manager on android like
Aico File Manager, androzip,winzip e.t.c
On PC just right click and click uncompress here..
Subscribe to:
Posts (Atom)
