PART A

Q.2. You’ve been asked to build software to support a low-cost

video editing system. The system accepts videotape as input,
stores the video on disk, and then allows the user to do a wide
range of edits to the digitized video. The result can then be
output to tape. Do a small amount of research on systems of this
type and then make a list of technology risks that you would face
as you begin a project of this type.

Ans:-
Technology Risks:-

1. Delaying your regular refresh cycle for desktop and notebook

PCs in an effort to save money.

The Problem:
When budgets are tight, companies may delay their PC replacement
programs in an effort to save money. But the longer those aging PCs
remain in a company’s infrastructure, the more hidden costs escalate —
losses such as lost end-user productivity and downtime. When you factor
in security risks, high maintenance costs, and reduced productivity,
refreshing your client base could actually save your company time and
money — important business goals in any economic climate.

2. Using a desktop PC as a server.

The Problem:
In an attempt to save money, companies large and small occasionally use
business desktop PCs as “servers” by loading server software and adding
more powerful internal components like larger or additional hard drives
and more memory. A desktop PC is designed to serve a single user and
cannot provide the expandability, performance, or dependability that a
server offers.

3. Installing unauthorized wireless access points in a company

building.

The Problem:=

When employees want wireless LAN access inside a company building

and the service is not available, they may be inclined to take matters into
their own hands. IT managers who don’t carefully monitor their computing
environments could end up with “rogue” wireless access points, installed
by employees, throughout the building. This opens the company’s WLAN
to a host of security problems.
4. Using outdated or manual data storage methods as your
primary data backup solution.

The Problem:

Many companies, especially small- and medium-sized businesses, don’t

have a comprehensive and reliable data backup solution for their
information assets. Many still use manual methods, like burning CDs, or
other backup solutions like portable storage peripherals . In some cases —
like backing up data on a single machine — these methods may be useful.
But as the primary backup solution, these practices are risky and may
cost
your company time, money, and, in the case of complete failure or
disaster, the permanent loss of vital company data.

5. Giving employees the wrong machines for their jobs.

The Problem

In an effort to simplify and standardize PCs — or simply to save money —

many companies give their employees PCs that may not be appropriate
for their job function. Employees who travel, or those who frequently work
away from their desk, may benefit significantly from using a notebook PC
instead of a desktop PC. Perhaps there are employees using PCs that are
either more powerful than what they need, or worse, not powerful
enough.
In either case, new PCs must be chosen carefully and matched to user
groups to ensure optimal business value and maximum ROI.

6. Maintaining multiple images in the client PC base.

The Problem:-
Every IT manager wants to limit software images and qualify their PC
platforms using a standardized image. But when it's time to deploy new
PCs, it's never easy. When a vendor makes a hardware change, it can
affect a previously qualified PC platform, and then the software image has
to be updated for the changed PC. After a few such changes on multiple
system components, the cost benefits of PC platform standardization
begin to unravel.

7. Using illegal, unauthorized, pirated, or shared software.

The Problem:-

When employees require software that’s not available internally, they

may
find other ways to get it, like loading a pirated version from outside the
company or borrowing a co-worker’s CD. Worse still, they may attempt to
install a legal but unauthorized program onto their system, potentially
causing compatibility issues with the IT-approved software load.
Companies may potentially face a host of serious consequences when
they neglect to carefully monitor their employees’ machines for illegal or
unauthorized software, or overlook employees’ critical software needs.

8. Operating and maintaining multiple servers without

considering consolidation

The Problem:

Frequently, companies fail to examine their server infrastructure and

assess opportunities for various levels of consolidation, like application
consolidation, server reduction and virtualization, data consolidation, and
location centralization. An audit of existing servers can pinpoint major
inefficiencies and help companies implement consolidation projects that
deliver the greatest ROI while improving IT efficiency. In the long run, only
a comprehensive and well-conceived consolidation strategy can deliver
lasting business value.

9. Modifying or replacing internal PC hardware components to

achieve better performance or keep legacy systems running.

The Problem:-

To satisfy specific end-user needs, companies may need to upgrade some

internal components, like video cards. But to achieve better performance
or to keep legacy systems working, some company employees — and
even some IT departments — may turn to practices like overclocking or
component swapping. These methods can make the PCs faster or keep
them working past their useful life expectancy. But they’re usually
BandAids* that expose a bigger problem: the need for more powerful PCs
for
end-users.

10. Sharing work e-mail addresses and other sensitive

information on the Internet.

The Problem:-

When employees share their e-mail addresses on Internet sites or in

public chat rooms, those addresses can be easily picked up by SPAM
Companies, who can then flood work in-boxes with junk e-mail. They can
also be picked up by individuals or entities with more malicious intents.
Q.3. Performance is an important consideration during planning.
Discuss how performance can be interpreted differently
depending upon the software application area

ANS:-

Performance engineering within systems engineering, encompasses the

set of roles, skills, activities, practices, tools, and deliverables applied at
every phase of the Systems Development Life Cycle which ensures that a
solution will be designed, implemented, and operationally supported to
meet the non-functional performance requirements defined for the
solution.

1) How fast and how easy do you want the MySQL Recovery process to
be?

Just like planning any other backup implementation, the most important
consideration is the recovery process. Here are two key recovery
objectives:

1. To what point in time will you need to recover your database?

The Recovery Point Objective (RPO) defines to what point in time
you have to recover your database. For example, if a user dropped
a table by accident at 12:55 pm, you might want to recover to a
point in time just before the delete command. In some
circumstances you may want to selectively exclude some rogue
transactions during the recovery process.

2. How much time will you have to recover your database?

The Recovery Time Objective (RTO) defines how much time it will
take to recover the database. You should carefully consider how
long your MySQL application can be offline while you do a recovery.

Therefore, you will need to determine RPO and RTO for MySQL database
in your environment and implement your backup solution accordingly.

When planning the recovery process, remember that different

circumstances will require different levels of recovery. Depending on the
situation, you may need to recover:

 The whole server - all databases (in case of disaster recovery)

 Specific database
 Specific table
 Specific transactions
Make sure to periodically test your recovery procedures by actually
conducting recoveries. Actual recoveries happen under stress and this is
not the time for practice. Once again it is all about recovery when
planning your MySQL Backup solution!

2) What will be the impact of MySQL Backup process on your Application?

Backup window refers to the time it takes for backups to complete. During
the backup window your MySQL applications will be either offline or
degraded (in performance or functionality or both).

 Some backup methods, e.g. offline backup make MySQL databases

totally unavailable.
 Other, e.g. mysqldump makes the database unavailable for update.
 Still others (replication, snapshots) have very minimal impact on the
MySQL databases and applications

The size of your database and rate of transaction activity will determine
how long your backup window will be. Depending on these factors and the
business requirements of your MySQL based applications you will need to
decide on the scheduling of your backup window. You will also need to
plan on potentially wide gyrations of the backup window duration - e.g. if
some business activity results in a huge number of updates to your
database. Ideally your implementation should also be aware of the
current activity on your database - e.g. if your database is presently
loaded with transactions, your implementation can intelligently postpone
a scheduled backup run for a few hours.

Your applications may have data stored in files outside of MySQL

database. E.g. the configuration files for your application. While
implementing a MySQL backup solution make sure to create a process of
backing up and recovering these files, which will be needed to completely
recover your MySQL based applications.

3) What will your backup configuration look like?

i.e. - the What, Where, When, and How of MySQL Backup.

Your MySQL backup implementation will depend on the specific server

and database configuration in your environment. You will need to take an
inventory of the following:

 Number of MySQL servers

 Size of MySQL databases
 Storage engines in use (InnoDB, MyISAM, NDB-MySQL Cluster). Note
that you may introduce a new MySQL storage engine in the future.
Your backup implementation should be flexible to incorporate a new
storage engine.
 Database activity
• Is there a particular time that your database is less active
• Nature of activity (selects, inserts/updates)
  Use of MySQL replication
 MySQL versions being used
 Use of MySQL stored procedures

While deciding on what databases and tables to backup, make sure to

include all databases and tables needed to be backed up together to
ensure data consistency at your application level.

Choosing the right location for backup images is also a critical decision.
Store backups as far away from the original data as possible! You will be
surprised how many DBAs keep the backups on the same RAID as the
original data.

A related decision is where you want to recover your database during the
recovery process. If recovery is initiated after a simple user error, you
may choose to recover the database at its original location. Keep in mind
that hardware failure and disaster might require recovering to a different
host that could have a different location, hardware, operating system, or
version of MySQL. In ideal case, you should have a standby server where
you periodically audit your recovery process.

Depending on the size of your databases and your recovery location

criteria (i.e. whether you will recover at the same location as your current
database or a different location) you will need to plan for allocation of
space for backup and recovery purposes. If space is at a premium you can
also choose to compress your backup images - although this uses
computation resources both at backup and recovery stages.

If you are using MySQL replication for high availability or load balancing, it
can also be leveraged for backup purposes - backups can be performed
on a slave server without effecting the master server.

4) How will you manage your backup process and backed up data?

Backups should almost always be automated. Backups must be taken

consistently and regularly and relying on human intervention should be
avoided. Backup catalog should be automatically kept up-to-date keeping
track of all copies of backup images.

In typical backup implementations, important pre-backup and post-

backup procedures need to be performed. E.g. A pre-backup procedure
can check whether needed storage will be available for the upcoming
backup run. At the other end, a post-backup procedure can remove no
longer needed binary logs after a successful backup has finished. Your
backup implementation should seamlessly integrate such pre-backup and
post-backup procedures.

Security of your MySQL database is a key consideration while

implementing a backup solution. While backing up your MySQL database
you need to consider whether encryption of your data is required. Just like
compression, keep in mind that encryption has a computation cost both
during backup and recovery. Also, if you are backing up your data
remotely - say from your service provider site to your local data center or
vice versa - you should make sure that the transportation mechanism
being used is secure against eavesdroppers.

Proper planning should be done as to which personnel in your

organization can perform the recovery of the MySQL database. These
personnel need to have appropriate (technical and business) permissions
to recover, for example, the Accounting database. Proper training for the
personnel is essential before performing a recovery.

Appropriate security and access to backup images also plays into the
compliance requirements that your organization may have, which leads
us to the next top consideration.

5) What kind of tracking, reporting and compliance requirements does

your business have from your MySQL backup implementation?

Your MySQL backup implementation should provide timely notifications

for critical events such as backup failures. Mechanisms may include email,
SMS, or RSS feed captured on an administrator's dashboard.

It is likely that multiple personnel in your organization would be interested

in receiving reports of MySQL backups. This is especially true if your
environment has multiple entities using MySQL databases for different
purposes. MySQL Backup reports can also be used for other interesting
purposes, e.g. identifying durations of high MySQL update activity.

Your MySQL backup implementation should automatically implement your

Retention Policy - i.e. how long you want keep to your backed up MySQL
data. Your backup procedures should account for the possibility that
different types of data may have different retention policies - depending
on compliance and business requirements. The expired backups should
be automatically purged.
 PART B

Q.4. A formal technical review is effective only if everyone has

prepared in advance. How do you recognize a review participant
who has not prepared? What do you do if you're the review
leader?

Ans:-
The FTR (Formal Technical Review) is a software quality assurance activity
with the objectives to uncover errors in function, logic or implementation
for any representation of the software; to verify that the software under
review meets its requirements; to ensure that the software has been
represented according to predefined standards; to achieve software that
is developed in a uniform manner and to make projects more
manageable.

FTR (Formal Technical Review) is also a learning ground for junior

developers to know more about different approaches to software analysis,
design and implementation. It also serves as a backup and continuity for
the people who are not exposed to the software development so far. FTR
(Formal Technical Review) activities include walkthroughs, inspection and
round robin reviews and other technical assessments. The above-
mentioned methods are different FTR (Formal Technical Review) formats.

Analysis:-

Review meeting is important form of FTR (Formal Technical Review) and

there are some essential parameters for the meeting such as there should
be reasonable number of persons conducting the meeting and that too
after each one of them has done his/her homework i.e. some preparation
and the meeting should not be carried out very long which may lead to
wastage of time but rather for duration just enough to churn out some
constructive results. FTR (Formal Technical Review) is effective when a
small and specific part of the overall software is under scrutiny. It is easier
and more productive to review in small parts like each module one by one
rather than to review the whole thing in one go. The target of the FTR
(Formal Technical Review) is on a component of the project, a single
module.
The individual or the team that has developed that specific module or
product intimates the product is complete and a review may take place.
Then the project leader forwards the request to the review leader who
further informs the reviewers who undertake the task. The members of
the review meeting are reviewers who undertake the task. The members
of the review meeting are reviewers, review-leader, product developers
( or the module leader alone ) and there one of the reviewers takes up the
job of the recorder and notes down all the important issues raised in the
meeting.

At the end of each review meeting the decision has to be taken by the
attendees of the FTR (Formal Technical Review) on whether to accept the
product without further modification or to reject the product due to severe
errors or to accept the product provisionally. All FTR (Formal Technical
Review) attendees sign off whatever decision taken. At the end of the
review a review issues list and a review summary is report is generated.

Q.6 Develop a checklist for use during configuration audits.

Ans:-

Below is a sample configuration audit checklist (for FCA and PCA). The
Project Managers can use the following checklist as a reference for the
readiness of the audit or even for doing the audit.

Release audit:

• Does the release documentation clearly define the scope of release,

including the CRs that should be incorporated?
• Are all dependencies / bugs been documented?
• Is there adequate documentation that identifies the environment to
recreate the release?
• Is there adequate documentation that specifies the components and
the versions of those components that comprise the release?
• Are all the items of the release in sync with each other?
• Has the release been created using the right versions of the right
components from the right repositories?

Repository/Configuration item audit:

• Are the repositories defined as per the SCM plan?

• Have the items been put into the correct repositories?
• Are the required items present in the repositories?
• Have the items been named according to the conventions specified
in the SCM plan?
• Are the version numbers of items according to the SCM plan?
 • Have all items been put in the repositories according to the events
defined in the SCM plan?

Change Implementation Audit:

• Have all the required CRs been closed?

• Do CRs identify all items to be changed?
• Have all items identified for change in the CR been changed?
• Is it possible to isolate the changes between any two versions of the
items?
• Is the documentation in the items adequate to trace the changes
back to the appropriate CR?
• Is there adequate means to go back to a previous means?
• Are there any changes between two versions of an item that are not
traceable to an approved CR?
• Are the CRs documented before making changes in items?
• Are CRs analyzed, evaluated and approved prior to making of the
change in items?

Other aspects to Audit:

• Are appropriate backups of repositories been taken?

• Has the recovery from back up been tested?
• Are there any unauthorized components available in the working
directories of the team members?
• Is there adequate security/authorization to ensure that only
authorized team members perform the check-in and check-out?