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 someinternal 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 transactionsMake 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 applicationsThe 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?