Archive for the ‘IT Management’ Category

Why have you been so successful in reaching some of your goals, but not others? If you aren’t sure, you are far from alone in your confusion. It turns out that even brilliant, highly accomplished people are pretty lousy when it comes to understanding why they succeed or fail. The intuitive answer — that you are born predisposed to certain talents and lacking in others — is really just one small piece of the puzzle. In fact, decades of research on achievement suggests that successful people reach their goals not simply because of who they are, but more often because of what they do.

1. Be Specific. When you set yourself a goal, try to be as specific as possible. “Lose 5 pounds” is a better goal than “lose some weight,” because it gives you a clear idea of what success looks like. Knowing exactly what you want to achieve keeps you motivated until you get there. Also, think about the specific actions that need to be taken to reach your goal. Just promising you’ll “eat less” or “sleep more” is too vague — be clear and precise. “I’ll be in bed by 10pm on weeknights” leaves no room for doubt about what you need to do, and whether or not you’ve actually done it.

2. Measure the act on your goals.
Given how busy most of us are, and how many goals we are juggling at once, it’s not surprising that we routinely miss opportunities to act on a goal because we simply fail to notice them. Did you really have no time to work out today? No chance at any point to return that phone call? Achieving your goal means grabbing hold of these opportunities before they slip through your fingers.

To seize the moment, decide when and where you will take each action you want to take, in advance. Again, be as specific as possible (e.g., “If it’s Monday, Wednesday, or Friday, I’ll work out for 30 minutes before work.”) Studies show that this kind of planning will help your brain to detect and seize the opportunity when it arises, increasing your chances of success by roughly 300%.

3. Know exactly how far you have left to go. Achieving any goal also requires honest and regular monitoring of your progress — if not by others, then by you yourself. If you don’t know how well you are doing, you can’t adjust your behavior or your strategies accordingly. Check your progress frequently — weekly, or even daily, depending on the goal.

4. Be a realistic optimist.
When you are setting a goal, by all means engage in lots of positive thinking about how likely you are to achieve it. Believing in your ability to succeed is enormously helpful for creating and sustaining your motivation. But whatever you do, don’t underestimate how difficult it will be to reach your goal. Most goals worth achieving require time, planning, effort, and persistence. Studies show that thinking things will come to you easily and effortlessly leaves you ill-prepared for the journey ahead, and significantly increases the odds of failure.

5. Focus on getting better, rather than being good.
Believing you have the ability to reach your goals is important, but so is believing you can get the ability. Many of us believe that our intelligence, our personality, and our physical aptitudes are fixed — that no matter what we do, we won’t improve. As a result, we focus on goals that are all about proving ourselves, rather than developing and acquiring new skills.

Fortunately, decades of research suggest that the belief in fixed ability is completely wrong — abilities of all kinds are profoundly malleable. Embracing the fact that you can change will allow you to make better choices, and reach your fullest potential. People whose goals are about getting better, rather than being good, take difficulty in stride, and appreciate the journey as much as the destination.

6. Have grit.
Grit is a willingness to commit to long-term goals, and to persist in the face of difficulty. Studies show that gritty people obtain more education in their lifetime, and earn higher college GPAs. Grit predicts which cadets will stick out their first grueling year at West Point. In fact, grit even predicts which round contestants will make it to at the Scripps National Spelling Bee.

The good news is, if you aren’t particularly gritty now, there is something you can do about it. People who lack grit more often than not believe that they just don’t have the innate abilities successful people have. If that describes your own thinking …. well, there’s no way to put this nicely: you are wrong. As I mentioned earlier, effort, planning, persistence, and good strategies are what it really takes to succeed. Embracing this knowledge will not only help you see yourself and your goals more accurately, but also do wonders for your grit.

7. Build your willpower muscle. Your self-control “muscle” is just like the other muscles in your body — when it doesn’t get much exercise, it becomes weaker over time. But when you give it regular workouts by putting it to good use, it will grow stronger and stronger, and better able to help you successfully reach your goals.

To build willpower, take on a challenge that requires you to do something you’d honestly rather not do. Give up high-fat snacks, do 100 sit-ups a day, stand up straight when you catch yourself slouching, try to learn a new skill. When you find yourself wanting to give in, give up, or just not bother — don’t. Start with just one activity, and make a plan for how you will deal with troubles when they occur (“If I have a craving for a snack, I will eat one piece of fresh or three pieces of dried fruit.”) It will be hard in the beginning, but it will get easier, and that’s the whole point. As your strength grows, you can take on more challenges and step-up your self-control workout.

8. Don’t tempt fate. No matter how strong your willpower muscle becomes, it’s important to always respect the fact that it is limited, and if you overtax it you will temporarily run out of steam. Don’t try to take on two challenging tasks at once, if you can help it (like quitting smoking and dieting at the same time). And don’t put yourself in harm’s way — many people are overly-confident in their ability to resist temptation, and as a result they put themselves in situations where temptations abound. Successful people know not to make reaching a goal harder than it already is.

9. Focus on what you will do, not what you won’t do. Do you want to successfully lose weight, quit smoking, or put a lid on your bad temper? Then plan how you will replace bad habits with good ones, rather than focusing only on the bad habits themselves. Research on thought suppression (e.g., “Don’t think about white bears!”) has shown that trying to avoid a thought makes it even more active in your mind. The same holds true when it comes to behavior — by trying not to engage in a bad habit, our habits get strengthened rather than broken.

If you want to change your ways, ask yourself, What will I do instead? For example, if you are trying to gain control of your temper and stop flying off the handle, you might make a plan like “If I am starting to feel angry, then I will take three deep breaths to calm down.” By using deep breathing as a replacement for giving in to your anger, your bad habit will get worn away over time until it disappears completely.

hope after reading about the nine things successful people do differently, you have gained some insight into all the things you have been doing right all along. Even more important, I hope are able to identify the mistakes that have derailed you, and use that knowledge to your advantage from now on. Remember, you don’t need to become a different person to become a more successful one. It’s never what you are, but what you do.

Advertisements

Software Configuration Management

Posted: December 16, 2011 in IT Management

A while ago I wrote a post ‘What is Configuration Management?’ in which I outlined the four principles of configuration management. This prompted several readers to ask, ‘what about software configuration management?’.

Software configuration management differs from the core configuration management discipline in detail only. It is common for organisations to include disciplines like build management (the discipline of transforming source into product) under the job description configuration management and it is common to see people discuss build management as if it were part of software configuration management but this is an error. Build management is closely associated with configuration management, but is most certainly not a part of configuration management.

Build management uses configuration management. Configuration management supplies the input to build management (a source baseline). Build management then creates product from these sources and delivers these products to configuration management. Configuration management places those products into a product baseline, often alongside the source baseline. The important point is that build management can operate without configuration management (not a good idea, but it is perfectly possible). Similarly, configuration management in no way depends upon build management. Attempting to integrate them leads to confusion and gains us nothing but creating an artificial dependency.

A discipline more closely, and correctly, included under the title software configuration management is version control. Version control is a crossover discipline, part asset management and part configuration management.

Asset management is primarily concerned with recording and securing things of value. Configuration management is concerned with more than simple recording and custody, it also needs too maintain information about the relationships between the items it holds. Importantly version control maintains the history of each asset, its ancestry. Of course all configuration management is concerned with this version control issue, but software configuration management requires that the version control system not only records these relastionships but also holds all of the actual files. It is this particular that software configuration management differs from configuration management.

In addition to the normal configuration management skills, a software configuration manager should also be adept at conceiving and managing version control of systems and the files that constitute them

Due to Internet capabilities and web technology, traditional business organisation definition has undergone a change where scope of the enterprise now includes other company locations, business partners, customers and vendors. It has no geographic boundaries as it can extend its operations where Internet works. All this is possible due to Internet and web moving traditional paper driven organisation to information driven Internet enabled E-business enterprise. E-business enterprise is open twenty-four hours, and being independent, managers, vendors, customers transact business anytime from anywhere.

Internet capabilities have given E-business enterprise a cutting edge capability advantage to increase the business value. It has opened new channels of business as buying and selling can be done on Internet. It enables to reach new markets across the world anywhere due to communication capabilities. It has empowered customers and vendors / suppliers through secured access to information to act, wherever necessary. The cost of business operations has come down significantly due to the elimination of paper-driven processes, faster communication and effective collaborative working. The effect of these radical changes is the reduction in administrative and management overheads, reduction in inventory, faster delivery of goods and services to the customers.

In E-business enterprise traditional people organisation based on ‘Command Control’ principle is absent. It is replaced by people organisations that are empowered by information and knowledge to perform their role. They are supported by information systems, application packages, and decision-support systems. It is no longer functional, product, and project or matrix organisation of people but E-organisation where people work in network environment as a team or work group in virtual mode.

E-business enterprise is more process-driven, technology-enabled and uses its own information and knowledge to perform. It is lean in number, flat in structure, broad in scope and a learning organisation. In E-business enterprise, most of the things are electronic, use digital technologies and work on databases, knowledge bases, directories and document repositories. The business processes are conducted through enterprise software like ERP, SCM, and CRM supported by data warehouse, decision support, and knowledge management systems.

Today most of the business organisations are using Internet technology, network, and wireless technology for improving the business performance measured in terms of cost, efficiency, competitiveness and profitability. They are using E-business, E-commerce solutions to reach faraway locations to deliver product and services. The enterprise solutions like ERP, SCM, and CRM run on Internet (Internet / Extranet) & Wide Area Network (WAN). The business processes across the organisation and outside run on E-technology platform using digital technology. Hence today’s business firm is also called E-enterprise or Digital firm.

The paradigm shift to E-enterprise has brought four transformations, namely:

  • Domestic business to global business.
  • Industrial manufacturing economy to knowledge-based service economy.
  • Enterprise Resource Management to Enterprise Network Management.
  • Manual document driven business process to paperless, automated, electronically transacted business process.

These transformations have made conventional organisation design obsolete. The basis of conventional organisation design is command & control which is now collaborates & control. This change has affected the organisation structure, scope of operations, reporting mechanisms, work practices, workflows, and business processes at large. The comparison between conventional organisation design and E-enterprise is summarized in below image (table)

Comparison between Conventional Design and E-Organization

In E-enterprise, business is conducted electronically. Buyers and sellers through Internet drive the market and Internet-based web systems. Buying and selling is possible on Internet. Books, CDs, computer, white goods and many such goods are bought and sold on Internet. The new channel of business is well-known as E-commerce. On the same lines, banking, insurance, healthcare are being managed through Internet E-banking, E-billing, E-audit, & use of Credit cards, Smart card, ATM, E-money are the examples of the E-commerce application.

The digital firm, which uses Internet and web technology and uses E-business and E-commerce solutions, is a reality and is going to increase in number.

MIS for E-business is different compared to conventional MIS design of an organisation. The role of MIS in E-business organization is to deal with changes in global market and enterprises. MIS produces more knowledge-based products. Knowledge management system is formally recognized as a part of MIS. It is effectively used for strategic planning for survival and growth, increase in profit and productivity and so on.

To achieve the said benefits of E-business organisation, it is necessary to redesign the organisation to realize the benefits of digital firm. The organisation structure should be lean and flat. Get rid of rigid established infrastructure such as branch office or zonal office. Allow people to work from anywhere. Automate processes after re-engineering the process to cut down process cycle time. Make use of groupware technology on Internet platform for faster response processing.

Another challenge is to convert domestic process design to work for international process, where integration of multinational information systems using different communication standards, country-specific accounting practices, and laws of security are to be adhered strictly.

Internet and networking technology has thrown another challenge to enlarge the scope of organisation where customers and vendors become part of the organisation. This technology offers a solution to communicate, co-ordinate, and collaborate with customers, vendors and business partners. This is just not a technical change in business operations but a cultural change in the mindset of managers and workers to look beyond the conventional organisation. It means changing the organisation behaviour to take competitive advantage of the E-business technology.

The last but not the least important is the challenge to organise and implement information architecture and information technology platforms, considering multiple locations and multiple information needs arising due to global operations of the business into a comprehensive MIS.

How are agile projects managed?

Scrum is the agile process with the most to say about the management of a project, so let’s use it as our model process for answering this question. On a Scrum project, there are three roles: product owner, ScrumMaster, and team.

The product owner is responsible for the business aspects of the project, including ensuring the right product is being built and in the right order. A good product owner can balance competing priorities, is available to the team, and is empowered to make decisions about the product.

The ScrumMaster serves as the team’s coach, helping team members work together in the most effective manner possible. A good ScrumMaster views the role as one of providing a service to the team, removing impediments to progress, facilitating meetings and discussions, and performing typical project management duties such tracking progress and issues.

The team itself assumes the responsibility for determining how to best achieve the product goals (as established by the product owner). Team members will collaboratively decide which person should work on which tasks, which technical practices are necessary to achieve stated quality goals, and so on.

From looking at these three roles we can see that management responsibility is divided among a project’s product owner, ScrumMaster, and team.

Is the ScrumMaster considered the agile project manager?

Not really, but perhaps the world may come to view the ScrumMaster as a 21st century version of the project manager. Unlike a traditional project manager, the ScrumMaster is not viewed as the person to credit (or blame) for the success (or failure) of the project. The ScrumMaster’s authority extends only to the process. The ScrumMaster is an expert on the process and on using it to get a team to perform to its highest level. But, a ScrumMaster does not have many of the traditional responsibilities—scope, cost, personnel, risk management among them—that a project manager does.

 

Who handles traditional project management responsibilities?

Traditional project managers take on a great deal of responsibility. They are responsible for managing scope, cost, quality, personnel, communication, risk, procurement, and more. This has often put the traditional project manager in a difficult position—told, for example, to make scope/schedule tradeoff decisions but knowing that a product manager or customer might second-guess those decisions if the project went poorly.

Agile processes acknowledge this difficult position and distribute the traditional project manager’s responsibilities. Many of these duties, such as task assignment and day-to-day project decisions, revert back to the team, where they rightfully belong. Responsibility for scope/schedule tradeoffs goes to the product owner. Quality management becomes a responsibility shared among the team, product owner, and ScrumMaster. Other traditional project management responsibilities are similarly given to one or more of these agile roles.

 

Does this scale?

Agile processes like Scrum are definitely scalable. While the typical agile project has between five and twenty people across one to three teams, successful agile implementations have also been used on projects with 200-500, even 1,000 people. As you might expect, projects of that size must introduce more points of coordination and project management than small-scale implementations.

To coordinate the work of their many teams, larger projects sometimes include a role called project manager. While involving someone on the project with this title or background can be very helpful, we need to be careful of the baggage associated with the title “project manager.” Even on a very large agile project, much of the project management will still be done by teams—for example, teams will decide how to allocate tasks, not a project manager—so the project manager role becomes more one of project coordinator. Duties would include allocating and tracking the budget; communicating with outside stakeholders, contractors, and others; maintaining the risk census with guidance from the teams, ScrumMasters, and product owners; and so on.

 

I want to show a real easy way to put user stories in a spreadsheet-based product backlog. I wrote this after seeing someone tweet a screen capture of a product backlog I made 9 years ago and thought to myself, “Yikes, that’s out of date for how I do it today…”

As you probably know I’m a big fan of writing the product backlog in the form of user stories and of writing user stories in the form, “As a, Iso that.” An example being, “As a frequent flyer, I really want to be able to connect to the internet while flying so that I can update my blog while traveling rather than having to save this as a text file and updating my blog later.” (Can you guess where I am while writing this?)

What I’ve found makes a user story in this format very easy to work with in a spreadsheet is to take the boilerplate parts and put them into column headings. So we’ll have column headings like “As a” and “I” and “so that”. The meat of each story is then clearly visible in each row. Additional columns can be added for things like a unique identifier, notes, status and such. In this example, I’ve also included a column for the theme or grouping of which the story is a part. You can see this in the screen capture below. You can click the image for a larger view.

 

the product backlog in Excel

 

What are the advantages of User Stories for Requirements?????????

let me tell in detail

User Stories:

User stories are an agile approach to requirements that help shift the focus from writing about requirements to talking about them. Each includes a written sentence or two and, more importantly, a series of conversations about the desired functionality

 

What is a user story?

 

A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

                        As a <type of user>, I want <some goal> so that <some reason>.

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

 

Can you show some examples?

 

One of the benefits is that they can be written at varying levels of detail. We can write user stories that cover large amounts of functionality. These large user stories are generally known as epics. Here is an example epic from a desktop backup product:

  • As a user, I can backup my entire hard drive.

Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two:

  • As a power user, I can specify files or folders to backup based on file size, date created, and date modified.
  • As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved.

Who writes them?

Anyone can write a story. It’s the product owner’s responsibility to make sure a product backlog comprised of user stories exists, but that does not mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have some written by each team member.

Also, note that who writes a user story is far less important than who is involved in the discussions of it.

When are they written?

Stories are written throughout the project. Usually a story-writing workshop is held near the start of the project. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project or a three- to six-month release cycle within it.

Some of these stories will undoubtedly be epics. Epics will later be decomposed into smaller stories that fit more readily into a single iteration. Additionally, new stories can be written and added to the product backlog at any time and by anyone

Do these replace a requirements document?

Agile projects, especially Scrum ones, use a product backlog, which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog item.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of a user story (“As a user, I want…”) is incomplete until the discussions about that story occur. It is often best to think of the written part as a pointer to the real requirement. A user story could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.
 

1. Why User Stories?

Because stories exhibit some of the same characteristics of use cases or traditional requirements statements, it’s important to look at what distinguishes stories from these earlier requirements techniques. These differences can lead to many advantages for user stories.

Let’s Be Precise

User stories emphasize verbal communication. Written language is often very imprecise, and there’s no guarantee that a customer and developer will interpret a statement in the same way. For example, at lunch recently I read this on my menu: “Entrée comes with choice of soup or salad and bread.”

That should not have been a difficult sentence to understand, but it was. Which of these did it mean I could choose?

  • Soup or (salad and bread)
  • (Soup or salad) and bread

We act as though written words are precise, yet they often aren’t. Contrast the words written on that menu with the waitress’ spoken words: “Would you like soup or salad?” Even better, she removed all ambiguity by placing a basket of bread on the table before she took my order.

As another example, I recently came across this requirement, referring to a user’s ability to name a folder in a data management system: “The user can enter a name. It can be 127 characters.” From this statement it’s unclear whether the user must enter a name for the folder. Perhaps a default name is provided. The second sentence is almost completely meaningless. Can the folder name be other lengths, or must it always be 127 characters?

Useful for Planning

A second advantage of user stories is that they can be used readily in project planning. User stories are written so that each can be given an estimate of how difficult or time–consuming it will be to develop; use cases, on the other hand, are generally too large to be given useful estimates. Also, a story is implemented all in a single iteration of an agile project, while it’s common to split a use case across multiple iterations (even though those iterations are usually longer than on a story–driven project).

IEEE 830–style requirements statements (“The system shall…”) represent a different problem. When you consider the thousands or tens of thousands of statements in a software requirements specification (and the relationships between them) for a typical product, it’s easy to see the inherent difficulty in prioritizing them. If the requirements cannot be prioritized beyond the common high, medium, and low, they’re unsuitable for a highly iterative and incremental development process that will deliver working software every two to four weeks.

Spare Me the Details

Stories have additional advantages, but I’ll provide only one more. User stories encourage the team to defer collecting details. An initial place–holding goal–level story (“A Recruiter can post a new job opening”) can be written and then replaced with more detailed stories once it becomes important to have the details. This technique makes user stories perfect for time–constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that feels compelled to complete an IEEE 830–style software requirements specification.

2. User Stories Aren’t Use Cases

First introduced by Ivar Jacobsen,2 use cases are today most commonly associated with the Unified Process. A use case is a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system. Use cases may be written in unstructured text or to conform with a structured template. The templates proposed by Alistair Cockburn3 are among the most commonly used. A sample is shown in the sidebar

Use Case 1, which is equivalent to the user story “As a recruiter, I can pay for a job posting with a credit card.”

 

Use Case 1

Use Case Title: Pay for a job posting.

Primary Actor: Recruiter

Level: Actor goal

Precondition: The job information has been entered but is not viewable.

Minimal Guarantees: None

Success Guarantees: Job is posted; recruiter’s credit car is changed.

Primary Actor: Recruiter

Main Success Scenario

1. Recruiter submits credit card number, date, and authentication information.

2. System validates credit card.

3. System charges credit card full amount.

4. Job posting is made viewable to job seekers.

5. Recruiter is given a unique confirmation number.

Extensions

2a: The card is not a type accepted by the system.

2a1: The system notifies the user to use a different card.

2b: The card is expired.

2b1: The system notifies the user to use a different card.

2c: The card is invalid.

2c1: The system notifies the user to use a different card.

3a: The card has insufficient credit available to post the ad.

3a1: The system charges as much as it can to the current card.

3a2: The user is told about the problem and asked to enter a second credit card for the remaining charge. The use case continues at Step 2.

Within a use case, the term main success scenario refers to the primary successful path through the use case. In this case, success is achieved after completing the five steps shown. The Extensions section defines alternative paths through the use case. Often, extensions are used for error handling; but extensions are also used to describe successful but secondary paths, such as in extension 3a of Use Case 1. Each path through a use case is referred to as a scenario. So, just as the main success scenario represents the sequence of steps 1–5, an alternate scenario is represented by the sequence 1, 2, 2a, 2a1, 2, 3, 4, 5.

One of the most obvious differences between stories and use cases is their scope. Both are sized to deliver business value, but stories are kept smaller in scope because we place constraints on their size (such as “no story can be expected to take more than 10 days of development work”) so that they can be used in scheduling work. A use case almost always covers a much larger scope than a story. For example, looking at the user story “A Recruiter can pay for a job posting with a credit card,” we see that it’s similar to the main success scenario of Use Case 1. This leads to the observation that a user story is similar to a single scenario of a use case. Each story is not necessarily equivalent to a main success scenario; for example, we could write the story “When a user tries to use an expired credit card, the system prompts her to use a different credit card,” which is equivalent to Extension 2b of Use Case 1.

User stories and use cases also differ in the level of completeness. James Grenning has noted that the text on a story card plus acceptance tests “are basically the same thing as a use case.” By this, Grenning means that the story corresponds to the use case’s main success scenario, and that the story’s tests correspond to the extensions of the use case.

For example, the following might be appropriate acceptance test cases for the story “A Recruiter can pay for a job posting with a credit card:”

  • Test with Visa, MasterCard, and American Express (pass)
  • Test with Diner’s Club (fail)
  • Test with good, bad, and missing card ID numbers
  • Test with expired cards
  • Test with different purchase amounts (including one over the card’s limit)

Looking at these acceptance tests, we can see the correlation between them and the extensions of Use Case 1.

Another important difference between use cases and stories is their longevity. Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. Stories, on the other hand, are not intended to outlive the iteration in which they’re added to the software. While it’s possible to archive story cards, many teams simply rip them up.

An additional difference is that use cases are more prone to including details of the user interface, despite admonishments to avoid this tactic. There are several reasons. First, use cases often lead to a large volume of paper, and without another suitable place to put user interface requirements, they end up in the use cases. Second, use case writers focus too early on the software implementation rather than on business goals.

Including user interface details causes definite problems, especially early in a new project when user interface design should not be made more difficult by preconceptions. I recently came across the use case shown in the sidebar Use Case 2, which describes the steps for composing and sending an email message.

Use Case 2

Use Case Title: Compose and send email message

Main Success Scenario

  1. User selects the New Message menu item.
  2. System presents the user with the Compose New Message dialog.
  3. User edits email body, subject field, and recipient lines.
  4. User clicks Send button.
  5. System sends the message.

User interface assumptions appear throughout this use case: a New Message menu item, a dialog box for composing new messages, subject and recipient input fields in that dialog box, and a Send button. Many of these assumptions may seem good and safe, but they may rule out a user interface in which I click a recipient’s name rather than typing it to initiate the message. Additionally, the use case of Use Case 2 precludes the use of voice recognition as the interface to the system. Admittedly, far more email clients work with typed messages than with voice recognition, but the point is that a use case is not the proper place to specify the user interface in this manner.

Think about the user story that would replace Use Case 2: “As a user, I can compose and send email messages.” No hidden user interface assumptions. With stories, the user interface will come up during the conversation with the customer.

To get around the problem of user interface assumptions in use cases, Constantine and Lockwood4 have suggested the concept of essential use cases. An essential use case is one that has been stripped of hidden assumptions about technology and implementation details. For example, the following table shows an essential use case for composing and sending an email message. What’s interesting about essential use cases is that the user intentions could be directly interpreted as user stories.

User Intention System Responsibility
Compose email message  
Indicate recipient(s) Collect email content and recipient(s)
Send email message Send the message

Another difference is that use cases and stories are written for different purposes. Use cases are written in a format acceptable to both customers and developers so that each may read and agree to the use case. The purpose of the use case is to document an agreement between the customer and the development team. Stories, on the other hand, are written to facilitate release and iteration planning, and to serve as placeholders for conversations about the users’ detailed needs.

Not all use cases are written by filling in a form, as shown in Use Case 1. Some use cases are written as unstructured text. Cockburn refers to these as use case briefs. Use case briefs differ from user stories in two ways. First, since a use case brief must still cover the same scope as a use case, the scope of a use case brief is usually larger than the scope of a user story. That is, one use case brief will typically tell more than one story. Second, use case briefs are intended to live on for the life of a product. User stories, on the other hand, are discarded after use. Finally, use cases are generally written as the result of an analysis activity, while user stories are written as notes that can be used to initiate analysis conversations.

User Stories Aren’t Requirements Statements

The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications.5 This document, known as IEEE Standard 830, was last revised in 1998. The IEEE recommendations cover such topics as how to organize the requirements specification document, the role of prototyping, and the characteristics of good requirements. The most distinguishing characteristic of an IEEE 830–style software requirements specification is the use of the phrase “The system shall…” which is the IEEE’s recommended way to write functional requirements. A typical fragment of an IEEE 830 specification looks similar to the following:

4.6) The system shall allow a company to pay for a job posting with a credit card.

4.6.1) The system shall accept Visa, MasterCard, and American Express cards.

4.6.2) The system shall charge the credit card before the job posting is placed on the site.

4.6.3) The system shall give the user a unique confirmation number.

Documenting a system’s requirements to this level is tedious, error-prone, and very time-consuming. Additionally, a requirements document written in this way is, quite frankly, boring to read. Just because something is boring to read is not sufficient reason to abandon it as a technique; however, if you’re dealing with 300 pages of requirements like this (and that would only be a medium-sized system), you have to assume that it’s not going to be read thoroughly by everyone who needs to read it. Readers will either skim or skip sections out of boredom. Additionally, a document written at this level will frequently make it impossible for a reader to grasp the big picture.

There’s a tremendous appeal to the idea that we can think, think, think about a planned system and then write all the requirements as “The system shall….” That sounds so much better than “If possible, the system will…” or even “If we have time, we’ll try to…” that better characterizes the reality on most projects.

Unfortunately, it’s effectively impossible to write all of a system’s requirements this way. A powerful and important feedback loop occurs when users first see the software being built for them. When users see the software, they come up with new ideas and change their minds about old ideas. When changes are requested to the software contemplated in a requirements specification, we’ve become accustomed to calling it a “change of scope.” This type of thinking is incorrect for two reasons. First, it implies that the software was at some point sufficiently well-known for its scope to have been considered fully defined. It doesn’t matter how much effort is put into upfront thinking about requirements; we’ve learned that users will have different (and better) opinions once they see the software. Second, this type of thinking reinforces the belief that software is complete when it fulfills a list of requirements, rather than when it fulfills the goals of the intended user. If the scope of the user’s goals changes, perhaps we can speak of a “change of scope,” but the term is usually applied even when only the details of a specific software solution have changed.

IEEE 830–style requirements have sent many projects astray because they focus attention on a checklist of requirements rather than on the user᾿s goals. And lists of requirements don’t give the reader the same overall understanding of a product that stories do. It’s very difficult to read a list of requirements without automatically considering solutions in your head as you read. Carroll, for example, suggests that designers “may produce a solution for only the first few requirements they encounter.”6 For example, consider the following requirements:

3.4) The product shall have a gasoline-powered engine.

3.5) The product shall have four wheels.

3.5.1) The product shall have a rubber tire mounted to each wheel.

3.6) The product shall have a steering wheel.

3.7) The product shall have a steel body.

By this point, I suppose images of an automobile are floating around your head. Of course, an automobile satisfies all of the requirements listed above. The one in your head may be a bright red convertible, while I might envision a blue pickup. Presumably the differences between your convertible and my pickup are covered in additional requirements statements.

But suppose that instead of writing an IEEE 830–style requirements specification, the customer told us her goals for the product:

  • The product makes it easy and fast for me to mow my lawn.
  • I am comfortable while using the product.

By looking at goals, we get a completely different view of the product: the customer really wants a riding lawnmower, not an automobile. These goals are not user stories, but where IEEE 830 documents are a list of requirements, stories describe a user’s goals. By focusing on the user’s goals for the new product, rather than a list of attributes of the new product, we can design a better solution to the user’s needs.

A final difference between user stories and IEEE 830–style requirements specifications is that with the latter the cost of each requirement is not made visible until all the requirements are written. The typical scenario is that one or more analysts spends two or three months (often longer) writing a lengthy requirements document. This document is then handed to the programmers, who tell the analysts (who relay the message to the customer) that the project will take 24 months, rather than the six months they had hoped for. In this case, time was wasted writing the three-fourths of the document that the team won’t have time to develop, and more time will be wasted as the developers, analysts, and customer iterate over which functionality can be developed in time. With stories, an estimate is associated with each story immediately. The customer knows the velocity of the team and the cost of each story.

Cache Vaulting

Posted: December 14, 2011 in Cache Vaulting, IT Management, IT Security

Cache is exposed to the risk or uncommitted data due to power failure. This problem can be addressed in various  ways
1. Powering the memory with a battery until AC power is restored
OR
2. Using battery power to write the cache content to the disk.

In this event of extending power failure, using batteries is not a viable option because in intelligent storage system large amount of data may need to be commited to numerous disks & batteries may not provide power for sufficient time to write each piece of data to its instead disk.

Therefore, storage vendors use a set of physical disks to dump the contents of cache during power failure. This is called cache vaulting & the disks are called Vault Drivers.

When power is restored, data from these disks is written back to write cache & then written to the intended disks.


Vault Drives
 
All Clariions have Vault Drives. They are the first five (5) disks in all Clariions. Disks 0_0_0 through 0_0_4. The Vault drives on the Clariion are going to contain some internal information that is pre-configured before you start putting data on the Clariion. The diagram will show what information is stored on the Vault Disks.
The Vault.
 
The vault is a ‘save area’ across the first five disks to store write cache from the Storage Processors in the event of a Power Failure to the Clariion, or a Storage Processor Failure. The goal here is to place write cache on disk before the Clariion powers off, therefore ensuring that you don’t lose the data that was committed to the Clariion and acknowledged to the host. The Clariions have the Standby Power Supplies that will keep the Storage Processors running as well as the first enclosure of disks in the event of a power failure. If there is a Storage Processor Failure, the Clariion will go into a ‘panic’ mode and fear that it may lose the other Storage Processor. To ensure that it does not lose write cache data, the Clariion will also dump write cache to the Vault Drives.
 
Operating System.
 
The Operating System of the Storage Processors is stored to the first five drives of the Clariion.
 
Now, please understand that this information is NOT in any way shape or form laid out this way across these disks. We are only seeing that this information is built onto these first five drives of the Clariion. This information does take up disk space as well. The amount of disk space that it takes up per drive is going to depend on what Flare Code the Clariion is running. Clariions running Flare Code 19 and lower, will lose approximately 6 GB of space per disk. Clariions running Flare Code 24 and up, will lose approximately 33 GB of space per disk. So, on a 300 GB fibre drive, the actual raw capacity of the drive is 268.4 GB. Also, you would subtract another 33 GB per disk for this Vault/PSM LUN/Flare Database LUN/Operating System Information. That would leave you with about 235 GB per disk on the first five disks.