Posts

forge

Develop a strategy for requirements gathering

There’s more to requirements gathering than getting an initial framework. Understanding the differing goals of the requirements process is an important key to understanding how to get requirements done right.

In most mid-sized IT organizations the process of gathering requirements is a little more advanced than scribbling a few wire frame representations of what the screen for the new system should look like. (A wire frame is simply a line drawing with boxes, rectangles, and text which roughly describes what the final product may look like.) This mechanism for collecting requirements is quick. After a few minutes and a handful of sketches, enough information can be gathered to start developing a solution.

While this may be required for some projects, it’s more often than not going to create more challenges down the road as small details escape everyone’s attention until very late in the process — where changes and fixes cost the most money.

This technique does have its place. It’s a necessary part of the overall process. However, there’s more to requirements gathering than getting an initial framework. Understanding the differing goals of the requirements process is an important key to understanding how to get requirements done right.

http://www.techrepublic.com/article/develop-a-strategy-for-requirements-gathering/

forge

Anatomy of a Software Development Role: Training

Wrapping up the software development lifecycle and turning over the completed product to the users is the training role. The training professional is the last one in the process since they are the ones who get the mass of users to use the software that has been created. Their purpose is to help the users understand how to use the software that’s been created. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

What’s the Training role?

The training professional first and foremost creates the materials necessary to train users how to use software. For that reason, training professionals are often tapped to create user documentation and help files in smaller organizations.

The training professional is ideally someone who has an instructional design background and therefore understands how to create materials that are effective in helping adults learn. They are also, ideally, someone who can approach the problems that the software solves in a way which makes sense to the users. Click here to see how the Deployment role fits within the full organizational chart.

http://www.developer.com/java/other/article.php/3523171

forge

Four Things you’re missing in your backup strategy

Backup Strategies aren’t always about when to backup and what to backup. They are often about how to create the right systems to allow you to discover problems when they occur.

When most people think of a backup strategy they think about tape rotation and backup schedules. While these are important parts of a backup strategy they’re not the whole story. As an organization begins to assimilate more and more servers, a reliable backup strategy becomes more challenging. Instead of one tape drive that backs up the entire network, libraries become necessary. Instead of doing one backup job and schedule, you need several. Here are four fundamentals for developing your backup strategy.

Plan for growth

Most organizations have begun to start monitoring their disk storage needs. While disk storage is cheap, the cost of maintaining all those files, including archives and backups, starts to become a real expense. When an organization plans its disk needs, it needs to review its growth and determine how much extra disk space will need to be purchased over the next year.

But here’s the rub. Adding more disk space is relatively easy. You just add new drives to the disk array or you swap out smaller disks for larger ones. The process takes time but it’s relatively transparent. Upgrading tape capacity isn’t so easy for most organizations.

http://www.techrepublic.com/article/four-things-youre-missing-in-your-backup-strategy/

 

forge

Four steps for reducing project risk

Risks in a project are inevitable. However, carefully collecting, evaluating, prioritizing, and controlling risks can increase the chances of success for your next project.

Whether it’s small or large, complex or simple, every project has risk. It’s our job as managers to do our best to not only minimize the risk in our projects but to minimize it as soon as we can. In this article, you’ll learn a simple four-step approach for doing just that.

Inventory

The first step to managing the risk of a project is to inventory the situation. That is, identify all of the risks that you think are possible in the project. The inventory should include all internal factors for the project such as resource changes, assumption failures, and sponsor availability. It should also include all external factors such as a change in company direction or a change of technology direction. Most of all, however, it should include the things that are new in the project. If the project is working with a new technology, is using a new development methodology, or even if there are new, relatively unknown team members, these need to be listed as potential risks to the project.

http://techrepublic.com.com/article/four-steps-for-reducing-project-risk

forge

Anatomy of a Software Development Role: Deployment

The deployment role is a role that is often overlooked much to the pain of the users. The actions of this role are the final step before being able to hand over the code to the users for their first real road test of the solution. It is the deployment person who can have the largest impact on the initial perception of the software for the people who are first trying it out. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

Success here can hide quirks in the solution but failures here can give the wrong impression about the software.

What’s the Deployment role?

A software solution of any complexity will have dependencies that must be present before the solution can be used. Many of these dependencies go unstated. For instance, a Java program needs a certain level of the Java runtime environment installed to be able to run. .NET based applications require a specific version of the .NET framework and common language runtime to run. In the case of database applications specific versions of the software drivers to connect to the software to the database are required. Click here to see how the the Deployment role fits within the full organizational chart.

In addition to these software dependencies, there may also be hardware dependencies. This could include a minimum amount of member, a required amount of hard disk space, access to multiple machines (such as a database server versus an application server), access to the Internet, and more.

http://www.developer.com/java/ent/article.php/3519186

forge

A single Goliath or best of breed

No single off-the-shelf system will exactly meet all of your organizational needs. The trick is finding the set of solutions that meet your organization’s needs and that work well with each system within that set of solutions.

forge

Sell the Strategy Before Selling the Tactics

You need to sell the strategy of technological innovations both to your group and to the organization as a whole. From there, each tactical battle is easier. The organization will already know the expected result and can visualize the success of each tactic resulting in the goal or goals they want.

“Those who fail to plan, plan to fail” was the old cliché that my English teachers inflicted upon me during my junior high school years. Unfortunately, that only conveys part of the message. When discussing how to lead your group forward in any technological innovation, it’s not enough to merely have a plan; you have to sell the plan. You have to get your group to buy into the plan and be willing to make sacrifices in order to reach the plan’s vision.

Failing to sell the plan will often mean having to sell every action you take. Without a good understanding of the plan, most people will assume you don’t have one and will approach each item as a separate “stab-in-the-dark” attempt to improve things.

You need to sell the strategy in what you’re doing both to your group and to the organization as a whole. From there, each tactical battle is easier. The organization will already know the expected result and can visualize the success of each tactic resulting in the goal or goals they want.

forge

Finding the Right Role in IT

People’s positions do not necessarily reflect current roles in the organization. In placing employees in a role, it is important to assign them to tasks that fit their capabilities. Whether you are a CIO, director, manager, supervisor, or worker, you have a set of strengths and weaknesses that are uniquely yours.

When I was young, I played soccer, although I didn’t play that well. I never really understood why some players would stay away from the ball instead of chasing after it. I could see the goalie stayed in his place, but I thought everyone else should chase the ball. I found, with experience, that the players who stayed in place were often more effective at what they were doing than those who spent their time running after the ball.

We have the same situation in IT. We need people to stay in roles and positions that leverage their strengths and allow them to be good at what they do. While occasionally the goalies have to get out of the box, their primary focus is guarding the goal. The same is true of your IT staff. They need to stay focused on what they do best and allow others to do what they do best.

Finding everyone’s true position

People’s positions do not necessarily reflect current roles in the organization. In placing employees in a role, it is important to assign them to tasks that fit their capabilities. Whether you are a CIO, director, manager, supervisor, or worker, you have a set of strengths and weaknesses that are uniquely yours.

http://www.techrepublic.com/article/finding-the-right-role-in-it/

forge

Anatomy of a Software Development Role: Quality Assurance

The Quality Assurance (QA) role is the role responsible for guaranteeing a level of quality for the end client, and to help the software development team to identify problems early in the process. It is not surprising that people in this role are often known as “testers”. Of course, the role is more than just testing. It’s about contributing to the quality of the final product. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

What’s the Quality Assurance role?

The quality assurance (QA) role is one that is focused on creating a quality deliverable. In other words, it is the responsibility of the QA role to make sure that the software development process doesn’t sacrifice quality in the name of completed objectives. Click here to see how the QA fits within the full organizational chart.

The QA role works with the Functional Analyst (FA) and the Solutions Architect (SA) to convert the requirements and design documents into a set of testing cases and scripts, which can be used to verify that the system meets the client needs. This collection of test cases and scripts are collectively referred to as a test plan. The test plan document itself is often simple providing an overview of each of the test cases. The testing cases and scripts are also used to validate that there are no unexplained errors in the system.