Question 1: Design Issues
Design fundamentals/concepts
o Abstraction
o Stepwise refinement
o Software architecture
o Modularity
o Control mechanism
o Information hiding
o Software Procedure
Abstraction
o concentrate on a problem at some level of generalization w/o regard to irrelevant
low level details.
o The lowest level of abstraction is reached when source code is generated.
o The process of taking away/removing characteristics from something in order to
reduce it to a set of essential characteristics.
Forms of abstraction:
o Procedural abstraction: named sequence of instructions that has a specific & little
function.
o Data abstraction: named collection of data that describes a data object.
o Control abstraction: implies a program control mechanism w/o specifying internal
details.
Stepwise Refinement
o A process of elaboration.
o The architecture of a program is developed by successively refining levels of
procedural detail.
o one or several instructions are decomposed into more detailed instructions.
Software Architecture
o The overall structure of the sw & the ways in which that structure provides
conceptual integrity for a sys.
Modularity
o sw is divided into separately named & addressable components called module,
that are integrated to satisfy problem req
o Modularity is the single attribute of sw that allows a program to be intellectually
manageable.
o easier to solve a complex problem when you break it into manageable pieces.
The aims of modularity:
o
o
o
o
o
o
o
Architectural design: to determine the structure of the software
Module design: easy to design modules instead of the whole software
Debugging: easier to identify faulty modules and correct the errors
Testing: test each module separately
Maintenance: changes made in each module.
Independent dev: ease of task distribution.
SW re-use: To avoid duplicating efforts & re-developing sub-sys performing
similar tasks.
Control Hierarchy
program structure, represents the organization of program components & implies
a hierarchy of control.
Information Hiding
Information. (procedures & data) contained within a module is inaccessible to
other modules that have no need for such info.
when modifications are made during testing & maintenance, errors introduced are
less likely to propagate to other locations within the sw.
The aims:
o Changeability: changes are done to few, preferably to a single module
only.
o Independent dev: reduce accesses to shared data or file structure.
o Comprehensibility: reduces the need to understand other module or global
data or shared data.
Software Procedure
A means of specifying (for each module) the module interface, the pre & post
conditions and the operations to be performed.
provides a precise spec. of processing, including sequence of events, exact
decision points, repetitive operations, and data organization/structures.
Design issues. In a given scenario. Design factors are also included.
Design principle
o The design process should not suffer from tunnel vision.
o consider alternatives approaches, judging each based on the req of the problem,
the resources available to do the job & the design concepts.
o The design should be traceable to the analysis model.
o The design should not reinvent the wheel.
o The design should minimize the intellectual distance between the sw & the
problem as it exists in the real world.
o The design should exhibit uniformity & integration.
o The design should be structured to accommodate change.
o The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered. A well-designed computer
program should never bomb.
o The design should be assessed for quality as it is being created, not after the fact.
o The design should be reviewed to minimize conceptual errors.
Factors/characteristics
o 3 characteristics of a good design (goal of the design process)
The design must implement and accommodate all of the reqs. in the
analysis model & those desired by the customer.
The design must be readable, understandable guide for programmers,
testers and maintainers.
The design should provide a complete picture of the sw, addressing the
data, functional & behavioral domains.
Question 2: Quality Factors
Correctness
When it comes in the correctness of a software system it refers into the agreement of
program code with specifications and independence of the actual application of the
software system. Developers will use factor of correctness and define a list of the
system required output, the wholeness of the output information that can be
unfavorably, influenced by imperfect data and also the up-to-date oldness of the
information that defines such as the time between the event and it is compensation by
the software system. The accessibility of the information and lastly, the standards for
coding and documenting the software system. In the Hi Tech Company product, the
users should see the location, which will include air, land and height.
Robustness
In computer science, robustness is the ability of a computer system to cope with
errors during execution and cope with erroneous input. Robustness can encompass
many areas of computer science, such as robust programming, robust machine
learning, and Robust Security Network. Formal techniques, such as fuzz testing, are
essential to showing robustness since this type of testing involves invalid or
unexpected inputs. Alternatively, fault injection can be used to test robustness.
Various commercial products perform robustness testing of software systems, and is a
process of failure assessment analysis.
Reliability
Reliability of Hi Tech GPS App is the measure of how long the application continues
to operate as expected under normal circumstances. Hence, the application should be
accessible to customers at any point of time and its results should be as accurate as
possible. In order to achieve this quality for Hi Tech GPS App, the development team
needs to carefully measure the mean-time-to-failure (MTTF) of the AR Mobile App.
This will provide a means to know how reliable the application is and hence
undertake measures to improve its reliability.
Extendibility
Extensibility is the capacity to extend or stretch the functionality of the development
environment to add something to it that didn't exist there before. Ability of a
software system (such as a database system) to allow and accept significant extension
of its capabilities, without major rewriting of code or changes in its basic architecture.
From a hardware point of view, expandability may include additional or larger hard
disks, more memory, or faster video board. From a software point of view, it may
include ability to support more network users, greater number of 'hits' from website
visitors, or faster number crunching.
Reusability
Reusability necessity take care of utilize of software component in an original manner
make plans for one scheme in a new software project most recently existence
[Link] addition, they can make possible that will happen projects to derive
benefit from a granted component or a group of component of the most lately
developed software. The use again of software is anticipated to save development
supply, make shorter the development length of time, and make arrangements loftier
quality modules, by one who uses the original software, and throughout its earlier use
again. The problems within a company of software reutilize be suitable a subordinate
of software manufacturing standards. We must constitute a team when write module
of GPS car navigation system, team can recognize reusable module to use them in
future project
Compatibility
Compatibility is the capacity for two systems to work together without having to be
altered to do so. Compatible software applications use the same data formats. For
example, if word processor applications are compatible, the user should be able to
open their document files in either product.
Compatibility can refer to interoperability between any two products: hardware and
software, products of the same or different types, or different versions of the same
product. Products that are designed to be compatible with future versions of
themselves are referred to as forward compatible; products designed for compatibility
with older versions are said to be backward compatible.
Efficiency
The ability of a software system to fulfill its purpose with the best possible utilization
of all necessary resources is called Efficiency (Fiala & Cawood, 2010), its
requirements can take care of the hardware ability essential to carry out all the duty of
the software system in adaptation to all other something that is needed. The principal
duty in a hardware system be measured are the computers processing ability, its data
storage capability in terms of memory and disk capacity. The requirements may
include the maximum values at which the hardware resources will be applied in the
developed software system or the firmware. In order to make Hi Tech product more
efficiency, we should make hardware requirements in 1GB RAM and in the CPU at
lease 2Gb Hz and SATA 100Gb in Hard.
Portability
Portability necessity protects of the process of making of a software system to other
surroundings comprise of not the same hardware, not the same operating systems, and
so on. These essential accomplished it might be to keep doing applying the same
fundamental software in various condition or to utilize it concurrently in various
operating systems and hardware condition. The Hi Tech product should be able to
install on different platform.
Usability
Usability involves both architectural and non-architectural feature of the system
(Broadbent, 2014). This attribute is very important for Hi Tech GPS application.
where user satisfaction and the rate of user retention within a specific period of time
and user-friendliness can be measured from the ease of learning, rate of errors. This
attribute will be mostly implemented on the Hi Tech GPS application user interface,
so that user interface of GPS App, should be easy to use by all customers and hence
should be easy to learn. This quality attribute could be achieved by making sure that
the Application device is compatible and can be accessible via many different
devices. The customers of Hi Tech should be able to easily access the application
using different OS platform
Integrity
Integrity is the ability of a software to maintain correctness and harmony among all
related pieces of data. AdvOSS delegates the responsibility of integrity to its
Transactional API layer which looks at all cases and ensures that it maintains integrity
of data by either committing a transaction in full at all places or doing a roll back
from all places always leaving the network in a clean state with integrity.
A second integrity verification layer is added through multiple Analytical Processes
running in Background. These processes to designed to identify data integrity
violations and raise appropriate alarms
Verifiability/Testability
This is the ability to Validate the software product requirements. Testability
prerequisite take care of the testing of an information system. Testability necessities
for the comfort of testing are connected to special quality in the programs, which help
the examiner, for example by supplying determined ahead of time intervene outcome
and write a log files. Testability essential related to software operation, which contain
automatic science of identifying problem through signs and symptoms carry out by
the software system before to starting the system, to discover whether all ingredient
of the software system is in working arrangement and to acquire a report about the
discern defect. Other type of these stipulation take care of automatic relating to or
used in diagnosis verify practical by the upkeep technicians to discover the factor of
software inability to succeed. For Instance, when Hi Tech product system is being
tested it should report all detail.
Question 3: Software Security related to Software Quality
Answer
Software security can be thought of as a subclass of reliability. Many programs are plagued with
defects that allow a malicious hacker to seize control of that program, thereby assuming the
"identity" of the user who initially executed that program. This sort of security defect is of real
concern for institutions that are running server programs that can be compromised, providing a
back door to access data that should be otherwise protected from the outside world.
Security, like reliability and performance and usability and maintainability and so on must be
taken into account when building a system; and it is the software quality program that makes
sure that this will all be done correctly. Most software is not secure because it is not built in a
high-quality way: good software is secure, as well as reliable and scalable and fast and
maintainable.
Software quality assurance (SQA) encompasses the entire software development process from
start to finish. So the whole progression of evaluating and monitoring the security of an
application should be part of a software quality assurance program, along with other processes,
such as the design of the software and change and release management.
Moreover, when it comes to security, the goal of software quality assurance is to confirm the
confidentiality and integrity of sensitive data is protected as it is processed, stored and
transmitted, and that the application can resist attack to agreed risk levels. This means that threat
modeling scenarios and acceptable risk levels need to be established up front so developers and
the QA team know what to expect and what to work toward.
Threat modeling, carried out during the application design stage, is the process of identifying and
evaluating the risks to an application. The procedure identifies potential threats by categorizing
the assets or sensitive information an application accesses. By having your security professionals
and developers sit down together to analyze the application from an attacker's point of view,
everyone will gain a better understanding of how and why a hacker may attack it and how the
vulnerabilities can be removed. Threat modeling should take place when the user requirements
for a new application have been gathered and work has started on the architecture and design of
the application. This exercise not only ensures architecture design issues are resolved early on,
but it also creates a set of documents that identify and justify the security requirements of the
application. Countermeasures can then be implemented and tested to ensure the application
doesn't leave sensitive or personal information vulnerable to potential attackers. Any remaining
security-related bugs or weaknesses should be tracked with an agreed escalation policy.
The aim of the software-testing stage is to uncover and locate bugs and also validate and verify
that the software works as expected and meets the business and technical requirements that
guided its design and development. It makes little sense to run security testing and validation as a
completely separate process as it would only delay and disrupt the overall change and fix
processes. Putting security within the software quality assurance program will ensure that it's not
covered as an afterthought or in an ad-hoc fashion. It will also help ensure the security controls
implemented meet any necessary security standards and regulations, such as ISO 27001 or the
Payment Card Industry Data Security Standard.
More: Software Security starts with Software Quality
Cigital's Gray McGraw breaks software security problems down into roughly
equal halves. One half of security problems are security design flaws:
missing authorization or doing encryption wrong? or not using encryption at
all when you are supposed to, not handling passwords properly, not auditing
the right data, relying on client-side instead of server-side data validation,
not managing sessions safely, not taking care of SQL injection properly, and
so
on.
These
are
problems
that
require training and
experience
to
understand and solve properly.
The other half are security coding defects? basic mistakes in coding that
attackers find ways to exploit. Focusing on preventing, finding and fixing
these mistakes is a good place to start a software security program. It's
something that developers and testers understand and something that they
can take ownership of right away.
Although high-quality code is not necessarily secure, you can't write secure code
that isn't good code. There is a direct tie-in between the security of a system, and
the basic quality of the code. This tie-in can be seen by looking at the MITRE
Corporation's Common Weakness Enumeration (CWE), a comprehensive list of
common software problems found in the wild. Too many of these problems are
caused by basic mistakes in coding? mistakes like buffer overflows (still) and integer
overflows and other mistakes in arithmetic, string handling mistakes, mistakes in
error handling and concurrency, resource leaks, leaving debugging code on.
Mistakes that lead to major security and reliability problems.
Question 4: Verification and Validation.
Verification and validation is a systems engineering discipline that determines if work products
comply with their specifications and are fit for their intended use. More specifically:
Verification establishes the truth of correspondence between a work product and its
specification (from the Latin veritas, "truth").
It answers the question: "Are we building the product right?"
Validation establishes the fitness of a software product for its operational mission (from
the Latin valere, "to be worth").
It answers the question: "Are we building the right product?"
Verification vs Validation
Verification: Are we building the product right?
Validation: Are we building the right product?
Verification is the assessment of data completeness, accuracy, and consistency, and
related quality control practices.
Validation is the assessment of whether data are appropriate for the performance measure.
Verification
The purpose of Verification is to ensure that selected work products meet their specified
requirements. Verification is inherently an incremental process because it occurs throughout the
development of the product and work products, beginning with verification of the requirements,
progressing through the verification of the evolving work products, and culminating in the
verification of the completed product.
Validation
The purpose of Validation is to demonstrate that a product or product component fulfills
its intended use when placed in its intended environment. Validation activities can be applied to
all aspects of the product in any of its intended environments, such as operation, training,
manufacturing, maintenance, and support services. The methods employed to accomplish
validation can be applied to work products as well as to the product and product components.
The work products (e.g., requirements, designs, prototypes) should be selected on the basis of
which are the best predictors of how well the product and product component will satisfy user
needs.
Benefits of Verification and Validation
Ensure that requirements are met.
Remove defects from the product through out a projects life cycle, reduce
rework, and reduce the cost of poor quality.
Ensure that user needs are met and ensure the product fulfills its intended use
when placed in its intended environment.
Improve the quality of the process and the product.
Improve productivity and performance.
What Do V&V People Do?
V&V is carried out in parallel with the software/system development process. V&V activities
include traceability analysis, evaluation, review, inspection, assessment, and testing. Refer to
IEEE 1012 - Standard for Software Verification and Validation2 for a comprehensive description
of V&V life cycle activities.
Verification and Validation in Various Standards
V&V tasks during different phases of development lifecycle:
A development phase has different phase. Verification and validation are
performed in each of the phases of the lifecycle. Lets try to have a look at
them.
#1. V & V tasks Planning:
Verification of contract
Evaluation of Concept document
Performing risk analysis
#2. V & V tasks- Requirement phase
Evaluation of software requirements
Evaluation / analysis of the interfaces
Generation of systems test plan
Generation of Acceptance test plan
-----------#3. V&V tasks Design Phase
Evaluation of software design
Evaluation / Analysis of the Interfaces (UI)
Generation of Integration test plan
Generation of Component test plan
Generation of test design
#4. V&V Tasks Implementation Phase
Evaluation of source code
Evaluation of documents
Generation of test cases
Generation of test procedure
Execution of Components test cases
#5. V&V Tasks Test Phase
Execution of systems test case
Execution of acceptance test case
Updating of traceability metrics
Risk analysis
#6. V&V Tasks Installation and checkout phase
Audit of installation and configuration
Final test of the installation candidate build.
Generation of final test report
#7. V&V Tasks Operation Phase
Evaluation of new constraint
Assessment of the change proposed
#8. V&V Tasks Maintenance Phase
Evaluation of the anomalies
Assessment of migration
Assessment of the retrial features
Assessment of proposed change.
Validating the production issues.
V & V Techniques and Methods
Audits, Reviews, and Inspection
Analytic Techniques
Dynamic Techniques
Audits, Reviews and Inspection
V&V use these techniques to verify the software during its development process
Peer Reviews
Documentation inspections
Requirements/design/code reading
Test witnessing
Installation audits
Analytic Techniques
Static analysis of the software (i.e., requirements, design, or code) using graphical,
mathematical formulas or diagrams.
Effective in error detection at the software unit level
Control (data) flow diagramming
Interface input/output/process diagramming
Algorithm and equation analysis
Database analysis
Sizing and timing analysis
Proof of correctness
Dynamic Techniques
Involve the execution of the software.
Effective at error detection when software units are combined at the integrated subsystem
and system levels
Simulation and modeling
Hardware/software benchmark testing
Hardware-in-the loop testing the system config. is heavily instrumented to simulate
different test scenarios to be created.
Scientific testing coding of the target requirements/design using a general-purpose
computer and higher order language.
Types of Testing
-
Unit Testing: Individual classes or types
o Known as Module Testing
o Lowest level of Testing
o The objective of unit testing is to ensure that the unit being tested conforms to its
specification.
o Also ensures that the software unit is ready to be integrated to the other
units/modules.
o There are three ways software units can be tested:
Function testing
Structural testing
Software Inspections.
Functional testing locates errors in the following areas
Incorrect/missing functions.
Interface errors
Errors in data structures
Performance errors
Initialization/ termination errors
o
Component Testing: Group of related classes or types
Integration Testing: Interaction between classes
o End to end testing performed to expose faults in the interfaces and in the
interaction between integrated components.
o Testing performed to expose faults in the interfaces and in the interaction between
integrated components.
o Integration tests for procedural languages. This is easily generalized for OO
languages by using the equivalent constructs for message passing.
o Subroutine calls and returns -- for example, passage of data through global data
structures and/or the use of pointers.
Load Testing. Load testing is a generic term covering Performance Testing and Stress
Testing.
Stress Testing. Testing conducted to evaluate a system or component at or beyond the
limits of its specified requirements to determine the load under which it fails and how.
Conformance Testing. Verifying implementation conformance to industry standards.
Producing tests for the behavior of an implementation to be sure it provides the
portability, interoperability, and/or compatibility a standard defines.
Acceptance Testing
o Involves testing the system before it is accepted for operational use (Somerville
1995)
o Three types
Benchmark testing
Performed in the presence of actual users
User prepares test cases
Pilot testing
System installed in users place
User prepares special test cases
Parallel testing
new system operates in parallel with old system
System Testing
System testing categories
Load/Stress testing.
To identify the peak load conditions at which the system fails
Volume testing.
To determine the level of continuous heavy load at which the system will fail.
Configuration testing.
This test is intended to find those planned legal hardware/software configurations
on which the system will not operate correctly.
Compatibility testing.
This test is intended to expose those areas where the systems has improper
incompatibilities.
Security testing.
This test is to find ways to break the security provisions of the system.
Performance testing.
This test is intended to determine the actual performance of the system against the
performance objectives under peak and normal conditions.
Question 5: Risk Management
Risk involves
Future happenings
Changes
Choices
Project Risks
All project involve risk
Risk stem from work nature
Not practical to eliminate risk
Not desirable to eliminate risk
Acknowledge risk existence
Methods to handle risk
Reactive Risk Management
project team reacts to risks when they occur
mitigationplan for additional resources in anticipation of fire fighting
fix on failureresources are found and applied when the risk strikes
crisis managementfailure does not respond to applied resources and project
is in jeopardy
Proactive Risk Management
formal risk analysis is performed
organization corrects the root causes of risk
TQM concepts and statistical SQA
examining risk sources that lie beyond the bounds of the software
developing the skill to manage change
Managing Risks
Systematic identification, analysis, and response to project risks
Interactive Phases
Risk Planning
Risk Identification and Analysis
Risk Response Planning, Monitoring, and Control
Life Cycle Risk Analysis
Internal risks are more predominant at early phases poorly defined scope, hasty
planning, poor role definition
External risks increase during execution lack of resources, weather, changes to
schedule
Risk management should be carried out from initiation to closure
Typically, there are more risks at the early stages of a project
Identify risks at estimating phase
Amount at stake increases as project draws to a close
Risk types vary as project progresses
Risk Management Paradigm
Risk Management Process
Part of project office
Applied to all projects
Maintain risk database
Ris k
identification
Ris k analys is
Ris k planning
Ris k
monitoring
List of potential
ris ks
Prioritis ed ris k
lis t
Ris k avoidance
and contingency
plans
Ris k
as s es s ment
Risk identification
Identify project, product and business risks;
Easier said than done.
Difficult to ensure full risk identification.
Second/third opinion.
Must highlight all risks regardless of repercussions
How to identify % specify risks?
Must be defined precisely
Must be capable of measurement
Must have measurable impact
Types of Risk Identification can be
Technology risks.
People risks.
Organisational risks.
Requirements risks.
Estimation risks.
Risk Identification Steps can be:
Identify & classify risks
Quantify (part of risk analysis)
Determine current risk level/score
Determine response technique & associated risk score
Assign ownership
Risk Register
Primary means by which we identify and manage risks
Link risks to project entity
Ideally link to WBS or activity hierarchy
Identify in as detailed level as possible
Designate roles
Risk identifiers
Risk resolvers
Risk reviewers
Integrate with a risk tree sticky density
Make it simple for the users!
Risk analysis
Assess the likelihood and consequences of these risks;
Assess probability and seriousness of each risk.
Probability may be very low, low, moderate, high or very high.
Risk effects might be catastrophic, serious, tolerable or insignificant.
Rating Risks
Determine both probability & impact (severity)
Various types of models
Different impacts can have different types of scale (numeric, subjective,
etc.)
Probability & impact can have different weights
Do not use too granular a scale
Consistent across multiple projects
Figure 1: Rating Risks
Risk planning
Draw up plans to avoid or minimise the effects of the risk;
Consider each risk and develop a strategy to manage that risk.
Avoidance strategies
The probability that the risk will arise is reduced;
Minimisation strategies
The impact of the risk on the project or product will be reduced;
Contingency plans
If the risk arises, contingency plans are plans to deal with that risk;
Risk monitoring
Monitor the risks throughout the project
Assess each identified risks regularly to decide whether or not it is becoming less
or more probable.
Also assess whether the effects of the risk have changed.
Each key risk should be discussed at management progress meetings.
Risk Mitigation, Monitoring and Management (RMMM)
mitigationhow can we avoid the risk?
monitoringwhat factors can we track that will enable us to determine if the risk is
becoming more or less likely?
managementwhat contingency plans do we have if the risk becomes a reality?
Risk Due to Size
Attributes that affect risk include:
estimated size of the product in LOC or FP?
Estimated size of product in number of programs, files, transactions?
Percentage deviation in size of product from average for previous products?
Size of database created or used by the product?
Number of users of the product?
Number of projected changes to the requirements for the product? Before delivery/ after
delivery?
Amount of reused software?
Risk Due to Business Impact
Attributes that affect risk include:
Affect of this product on company revenue?
Visibility of this product by senior management/
Reasonableness of delivery deadline?
Number of customers who will use this product
Interoperability constraints
Sophistication of end users?
Amount and quality of product documentation that must be produced and delivered to
the customer/
Governmental constraints
Costs associated with late delivery?
Costs associated with a defective product?