Partition Hard disk drive

Hard Disk Partitioning

Disk Partitioning is dividing hard disk drive into multiple disks to treat one large physical disk drive as if it were multiple disks.

Advantages of Disk Partition:

1. Use of multi-boot setups, which allows to have and operate more than one operating system on a single computer.
2. The access time with smaller file systems is efficient when compared to big Master File System with a single Master File Table(MFT).

How to Partition Hard disk drive step-by-step process

Step 1:  Go to START and right click on Computer and select Manage.
Step 2:
1. A window similar to the below one opens, select Disk Management on the left side of the window toolbar.
2. Select the hard disk (C in this case) you want to partition.
3. Right click as shown on the hard drive (c).
4. Select Shrink Volume.

Step 3:
Enter the amount you want to shrink in MB (Example: if you want to partition 100GB from the hard drive, enter the amount to shrink as 102400 MB since 1GB = 1024 MB) and click Shrink.

Step 4:
After the hard disk had partitioned, we need to label that. Right click on the partitioned hard drive to select New Simple Volume.

Step 5: New Simple Volume wizard opens
1. Click Next and specify Volume size and Click Next.
2. Assign Drive Letter or Path(here you can select any letter you want)
3. Format Partition, where you can specify Volume Label (ie., name the partitioned hard disk space).

Once you click Finish, the hard disk is partitioned and labelled.

SCRUM ROLE : THE SCRUM TEAM

Scrum teams do not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together".

A typical Scrum team is 5-9 people. Rather than scaling by having a large team, Scrum projects scale through having teams of teams. 

Although not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach each Scrum team proceeds as normal but each team identifies one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.

SCRUM ROLE : SCRUM MASTER

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project's key stakeholder, who is referred to as the product owner.

The ScrumMaster does anything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint. The ScrumMaster role is commonly filled by a former project manager or a technical team leader but can be anyone.

The ScrumMaster is also often viewed as a protector of the team. The most common example is that the ScrumMaster protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint due to pressure from an overly aggressive product owner. However, a good ScrumMaster also protects the team from complacency.

Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when we realize that although the ScrumMaster has no authority over Scrum team members, the ScrumMaster does have authority over the process. Although a ScrumMaster may not be able to say, “You’re fired,” a ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much the same: They have authority, but that authority is granted to them by the team.

A ScrumMaster can say to a team, “Look, we’re supposed to deliver potentially shippable software at the end of each sprint. We didn’t do that this time. What can we do to make sure we do better the next sprint?” This is the Scrum- Master exerting authority over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable. But because the ScrumMaster’s authority does not extend beyond the process, the same ScrumMaster should not say, “Because we failed to deliver something potentially shippable the last sprint, I want Tod to review all code before it gets checked in.” Having Tod review the code might be a good idea, but the decision is not the ScrumMaster’s to make. Doing so goes beyond authority over the process and enters into how the team works.

VMware Workstation

What is a Virtual Machine:

A Virtual Machine, is a computer software implementation of hardware in which you can install an  operating system(OS) that executes programs, applications and scripts just like the real machine do.

VMware:

VMware provides users to set/simulate  a group of computers in order to test software or applications prior to deployment in a known environment.

VMware in Software Testing:

Quality Assurance Teams use VMware Workstation to test applications/software on a variety of operating systems(OS), application platforms and browsers with different configurations of tasks.

Difference between VMware Player and VMware Workstation:

VMware Player is like a subset of VMware Workstation.

1. The major difference is in the previous versions(versions earlier than 3) of VMware Player, you can only run virtual machines created on other versions like VMware Workstation but you cannot create a virtual machine itself. But the newer Versions of VMware Player has the ability to create Virtual machine but the major difference would be VMware Player is available for free while the VMware Workstation costs.
2. In VMware Workstation, you can create multiple snapshots and Clones which helps in case of failures from software or hardware. That is this feature enables users  to create a base VM and Clone it and use it for other software installations and test applications and if there is any kind of crash or system failure you still have your base VMware Workstation. VMware Player is lacking this feature of creating Clones and multiple snapshots.
3. VMware Workstation has the ability to create and manage teams by grouping them while VMware Player is lacking this feature. By grouping multiple VM s into teams, certain operations can be performed on all the members of the team as if it is one machine.
4.  VMware Workstation has the ability to handle VRM(Virtual Rights Management) while the VMware Player does not.

Scrum Role : Product Owner

When working with Scrum the product owner is typically a project's key stakeholder. It is important that this person has a vision of what they wish to build and that he or she is able to convey that vision to the scrum team. This is key to successfully beginning any agile software development project. Product owner's do this through in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed. This of course varies tremendously based on whether the team is developing commercial software, software for internal use, hardware, or some other type of product. The key is the person in this role needs to have a vision for what is to be built.

Although the product owner prioritizes the product backlog, during the sprint planning meeting the team selects the amount of work they believe they can do during each sprint and how many sprints will be required. The product owner does not get to say, "We have four sprints left, therefore you must do one-fourth of the product backlog this sprint." The product owner's job is to motivate the team with a clear, elevating goal. Team members know best what they are capable of and so they select which user stories from the top of the product backlog they can commit to delivering during any sprint.

In return for the scrum team's commitment to completing the selected user stories from the top of the product backlog, the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.