jump to navigation

The most important rule for managing your Agile project team’s velocity [VIDEO] May 1, 2013

Posted by HubTechInsider in Agile Software Development, Product Management, Project Management.
Tags: , , , , , ,
add a comment

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications and software development, I’m a PMO Director, a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

More Articles From Boston’s Hub Tech Insider:

How do you write software requirements? What are software requirements? What is a software requirement? July 28, 2011

Posted by HubTechInsider in Project Management.
Tags: , , , , , , , ,
1 comment so far
Waterfall Model

Image via Wikipedia

What is a software requirement?

A software requirement, simply stated, is something that matters to someone who matters.

A software requirement may take the form of anything from a high-level, abstract statement of a service or constraint to a detailed, formal specification. Software requirements must serve many purposes during the software engineering process, and so this is the reason that there is so much variation in how they are written and presented.

My main approach to writing requirements can vary in format from project to project, but I tend to prepare a list of software requirements in a computer spreadsheet program like Microsoft Excel or Google Docs, or Open Office Spreadsheet. This requirements document is always dated, ranked, the source of the requirements is always noted for traceability, and it is usually accompanied and supplemented by a catalog of use cases and a functional specification document with mockups and wireframes.

What are the characteristics of good software requirements?

The IEEE has a standard, IEEE 830, that lays out the characteristics according to the IEEE of good software requirements:

1. Correct: The SRS, or software requirements specification, should correctly describe the system behavior. It is not productive to have a requirements document that describes implausible or impossible expected system behavior or user goals.

2. Unambiguous: Software requirements should be written in such a manner as they are not subject to different interpretations. The use of specific and appropriate language can help avoid ambiguity in interpretation.

3. Complete: the software requirements document should completely describe the system’s expected behaviors and feature set.

4. Consistent: Requirements for the system under discussion must not contradict each other.

5. Ranked: You must rank your software requirements for importance. Each software requirement has its own level of importance and criticality, and they are not all equal. By ranking the requirements, software designers ensure that guidance is given to the development team regarding effective prioritization.

6. Verifiable: If the requirement cannot be verified as having been met, then the requirement itself is written poorly. The requirements have to be testable.

7. Modifiable: The requirements must be easy to modify or change.

8. Traceable: The requirements must be traceable, and it is essential that traceability information has been provided, as the requirements document provides the starting point in the traceability chain. I have written elsewhere in this blog at length about the importance of software requirements traceability and have provided examples of software requirement traceability matrixes. Many software development organizations use proprietary CASE software tools and other methods to enforce traceability policies that stipulate how much traceability information regarding requirements must be maintained.

What are some wording and language best practices for software requirements?

I have many years of hard won expertise in writing software requirements. About this topic I have discovered many tips and tricks of the trade that can serve you well as excellent best practices. I suggest that you invent and use a standard format for all of your requirements and requirements documents, including use cases and functional specifications. You should take great care to use language in a consistent way when writing your software requirements.

I recommend that you use “Shall” when you are writing mandatory software requirements, such as “The system shall provide a facility for a store manager to enter an alternate shipping address onto the order confirmation page”.

I recommend that you use “Should” for desireable software requirements, such as “The system should enable the use of as many payment gateways as have been configured by engineering prior to the current release”.

Feel free to boldface or otherwise emphasize or highlight key parts of the requirement. This holds true for use cases ad functional specification documents as well.

I recommend that unless it is absolutely necessary, you should avoid technical language or implementation details in your requirements documents.

What do bad software requirements look like?

What makes software requirements “Bad” software requirements? Well, lack of specificity is one way requirements can be reckoned to be poor. Another way in which software requirements can fail to serve their purpose in the software development effort is when they are written in a way in which they are they are not verifiable. If, for instance, a software requirements engineer were to write a software requirement in which he or she stated the system under discussion was to be “completely reliable”, what exactly would they mean, and how would “reliable” be quantified? If a percentage is used in the writing of a software requirement, the whole or the baseline percentage and boundaries should be specified.

The following are some examples of very poor software requirements — you really don’t want to write software requirements which look like these, trust me:

“The system shall be completely reliable”

“The system shall be maintainable”

“Order rejections shall be less than 99%”

“The system shall be fast”

“The system should use artificial intelligence”

“The system should be totally modular”

What do good software requirements look like?

I have already mentioned IEEE standard 830, which can serve as a fundamental basis guide for you when you set out to write your own software requirements, but let me emphasize a few key points here before setting some example good software requirements before you.

Make sure that your requirements are traceable, verifiable, and specific. Ensure that when you write your software requirements that you quantify any specific qualities that you write about as desireable User goals or User Stories. Make sure you rank your requirements for software development and date them, notating the source of the requirement, the venue of the requirement’s origin, the primary internal and external stakeholders, and the DRI, or directly responsible individual, who is assigned to sheparding that requirement through development. Make sure that you use “Shall” for mandatory requirements and “Should” for optional, or “nice to have” requirements.

“The response time for the system to present the checkout page upon an order button click on a product detail page shall be less than 500ms”

“95% of all transactions on the public-facing webstore portal shall be processed in less than 4s”

“MTBF for the domain controller server shall be 5000 hours of continuous operation”

“The system shall present the closest 5 stores to the user on the map page, provided that 5 stores are within the user-defined search radius”

How do you rank software requirements?

For the most part, I generally advocate a three level rating system for software requirements: mandatory, desirable, and optional. The mandatory requirements cannot be sacrificed, desirable requirements are important but could be sacrificed if necessary to meet schedule or budgetary concerns. Optional requirements are ones which may not be developed, simply due to the fact that they have been rated as being “nice to have”.

Ranking of software requirements comes in handy when the development team needs to make tradeoffs. For example, if time or work force is limited, the development team’s focus can then be placed on the higher ranked requirements.

What is the role of the requirements document in the software development process?

The requirements document is the official statement of what is required of the system developers. The requirements document should include both a definition and a specification of requirements. However, the requirements document is not a design document. To the extent that it is possible, the requirements document should be a set of statements regarding what the system should do, not how it should do it. In the real world, the requirements document does tend to contain some design specifications, which can box in the programmers later if carried too far.

Precise software specifications provide the fundamentals for analyzing the requirements, validating that they are the stakeholder’s intentions, defining what the designers have to build, and verifying that they have done so correctly.

Requirements allow the system’s programmers and software engineers to know the motivation for development of the system under construction. Software requirements also help the engineers manage the process of evolving the software over time and across suites of related software products and web-based services.

Who typically uses software requirements documents?

There are a great variety of stakeholders, both internal and external, who utilize the requirements documents throughout a typical software development project lifecycle. Each of these stakeholders will have a different perspective on the requirements document and they will each put the requirements document to a different use:

1. Customers or clients: will desire to, as completely as possible, express how their needs can be met. They continue to do this throughout the software development lifecycle process as their perceptions of their own needs change.

2. Developers or programmers: will attempt to create a software design that will satisfy all of the requirements laid out by the system designers.

3. QA personnel and testers: will use the requirements document as a basis for writing and conducting the tests they will use to verify that the system functions as it was designed.

4. Managers and project leaders: will use the requirements document as a contract to bid upon the system and then control the production of the software throughout the software development lifecycle.

5. System and Maintenance engineers: will use the requirements document as evidence of what the designers of the system had originally intended for it to do, using this as a guide for continuing evolution and maintenance efforts.

What is software requirements engineering?

Software requirements engineering is a subset or subdiscipline of software engineering that is focused on determining and specifying the functions, constraints, and user goals of the software system being designed.

The software requirements engineering process begins with a discovery project or feasibility study which leads to a discovery project findings document or project feasability report. There are instances, rare though they may be, when a software development project feasability study will actually conclude that the best course of action for a development organization is to not move forward with the development project. Feasibility studies can help your discovery team uncover answers to questions such as these:

1. Is a new technology needed for us to develop the system under discussion? What expenses will be involved in acquiring this new technology or resources experienced in working with it?

2. What is the impact, in all aspects, of not constructing the proposed system?

3. What are the current problems the system under discussion is proposed to alleviate?

4. How will the proposed system allievated these concerns?

5. What will be some of the development and integration problems encountered by the system’s design and programming project teams?

Software requirements engineering is strongly influenced by computer science and systems engineering, however, as developing software is an art, not a science, and since developing software is a human endeavor not generally considered a “true” engineering discipline, software requirements engineering draws upon a number of different disciplines and fields of study. Particularly with respect to understanding the user goals and needs and desires of humans, individuals with a diverse background in anthropolgy, philosophy, cognitive psychology, linguistics and other liberal arts fields often make superb requirements elicitators and software requirements engineers. It is oftentimes business analysts who take the fore in requirements elicitation and gathering in many organizations.

Software requirements engineering for a software development project has a few typical phases:

1. Requirements elicitation and gathering is always a necessary step, as frequently primary internal and external project stakeholders do not know what they want, the requirements can be deeply “hidden” within a client organization, prior requirements may not be validated or verifiable, and even completely incorrect. This is the phase of the project which will largely determine the success or failure of the project.

2. Requirements modeling is a way in which the written, prose requirements are presented in another format. Although effectively doing this can prove difficult for novices, many techniques such as use case modeling, UML diagrams, user stories and user goals can help system designers and requirements engineers and business analysts represent the requirements in a more easily comprehensible or shareable form.

3. Analyzing requirements is the process whereby the requirements are checked for consistency, correctness, completeness, sufficient detail, and writing style and format.

4. Requirements change management is a requisite activity for business analysts and software requirements engineers, as requirements are changing all the time and this process is to be expected and prepared for.

What different types of software requirements are there?

Even though there are many different types of forms software requirements may take, in my own experience a requirements document may encorporate a few different types of requirements within the same document, sometimes subdivided into sections or categorized. I wanted to take some time to explain a little about each of the types of software requirements so that when you are discussing requirements with stakeholders internal and external, as well as your project team, you can more easily express what you mean in terms of what type of requirements and for what purpose you wish to write them.

There is quite a bit of overlap in the functions of each of the types of software requirements I’m about to discuss. Keep this in mind, and remember that one of the points of this excercise is to familiarize yourself with the lingo. Knowing what each of these terms for software requirements refers to can help you forget about classifying your requirements and instead focus on just getting the requirements down on paper (or rather into your computer spreadsheet program or requirements management database) quickly.

1. Functional requirements are generally written from a bird’s-eye viewpoint, or at a high level, although they can also be very detailed, and contain annotations and notes, as well as references to other materials such as screen and page mockups and flow diagrams. They can describe not only what the system under construction should do, but also what it should not do.

2. Nonfunctional requirements are boundary conditions or externalities to the system under construction which will effect the performance envelope or capabilities of the system once it is operation. These types of requirements may include things such as environmental constraints, compliance with federal and state laws or industry regulations, safety standards, timing constraints, quality or uptime properties, programming languages to be used, etc.

3. Design constraint requirements include nonfunctional requirements that relate to hardware limitations and industry standards compliance.

4. Logical database requirements include things such as required data models or database schemas, data entity relationship diagrams (ERDs) stipulating database requirements, data entities and their required relationships, data retention and data integrity constraints, as well as database requirements that specify data access frequency of use data and accessing capabilities.

5. Domain requirements are a type of nonfunctional requirement which has been dictated to the system designers by the application’s domain of operation. For example, a health care application software system may have data integrity and security domain requirements which are derived from the HIPAA health care industry standards regarding private health care information (PHI). Domain requirements may impose new functional requirements or boundary conditions on existing requirements.

6. System attribute requirements are functional requirements which include information regarding the desired system availability, reliability, maintainability, portability and security.

7. Interface specifications are yet another type of functional requirements for software systems which are defined in terms of specifying how the system should interoperate with other software systems. There are many types of formalized notation systems used to specify these types of interfaces, including UML, or unified modeling language diagrams. The interface specifications focus on defining the data entities to be exchanged with other software systems, their structures and representations, as well as defining the interfaces themselves.

7. Performance requirements quantify the desired performance of the system being constructed. Performance requirements are a type of functional requirement, and there are two major types of performance requirements, those that measure or stipulate the performance of static system objects, processes or events, and those that stipulate the performance of dynamic system objects, processes or events. Performance requirements for software system generally take the form of numerically expressed time constraints. A software system’s static performance requirements might include things such as the number of simultaneous users the system would need to support at any given moment of time, whereby a system’s dynamic performance requirements might include such constraints as the number of work orders that would need to be processed by the system within certain time periods for both normal and peak workload conditions.

How are software requirements validated?

It is important to ensure that the requirements for the software system under construction accurately represent not only what the software developers and programmers are building, but also what the customer or client originally desired. Validation is very important, as catching requirement errors early on in the software development lifecycle reduces expense greatly. Rectifying a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

The IEEE has developed another standard, IEEE 830, for best practices for validating software requirements. The IEEE 830 standard lays out some suggested process improvements and gateways, including:

1. Requirements reviews.

2. Manual systematic analysis of the requirements.

3. Software prototyping.

4. Using an executable model of the system in order to verify the requirements.

5. Test case generation.

6. Developing test cases from the requirements in order to validate that they are in fact testable and verifiable requirements as written.

7. Automated consistency analysis.

What is software requirements modeling?

There are a number of different techniques which can be used to model software requirements. Some of these software requirements modeling techniques I have discussed at length elsewhere in this hub tech insider blog, and some of the other techniques for modeling requirements I will explore in more detail within these pages in future articles. User stories, user goals, use cases, and UML diagrams are some of the techniques oftentimes used to model software requirements, but there are many others including formal methods, natural languages, and structured diagrams.

The reason that modeling techniques are used in addition to prose requirements is that English, or any other natural language, inherently adds difficulty to the process of communicating requirements for the poduction of software. These difficulties can include lack of precision and clarity of language to the improper mixing of functional and nonfunctional requirements. The needless overcomplexity of combining requirements until they no longer make sense, in a wierd amalgamation of needs, is a common problem, as is ambiguity of language.

How do you conduct a requirements elicitation and gathering session?

There are many common problems encountered when elicitating requirements for a software system to be constructed. Requirements elicitation is a process in which requirements engineers or business analysts work with customers in order to determine the proposed system’s operational constraints, services, and application scope. There are many people involved in most requirements elicitation and gathering phases of a software development project, and they are collectively known as project stakeholders. Project stakeholders may include domain experts, managers, engineers, end users, and other internal and external personnel.

One of the primary concerns of the requirements engineer is eliciting requirements from stakeholders who are not sure what it is they really want from the system under discussion. Stakeholders can in fact introduce many serious detrimental issues into the requirements gathering and elicitation process that you should be aware of. These can include expressing requirements in their own, often incorrect terminology, providing conflicting requirements, and the introduction by stakeholders of organizational politics and other bureaucratic externalities which may unduly influence the requirements. It is not at all uncommon for stakeholders to feel free to change the requirements at will in response to new stakeholders who may emerge mid-project, as well as shifting business environments. All of these detrimental factors must be carefully monitored and counteracted by the requirements engineer when necessary.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is  Tshirtnow.net.

How do you create a Competitive Analysis? What is a competitive analysis? July 24, 2011

Posted by HubTechInsider in Product Management, Project Management.
Tags: , , , , , , , , , , ,
add a comment

How do you create a Competitive Analysis document? What is a competitive analysis?

Competitive analysis documents can be found as a primary product management deliverable in most every industry, and even the simplest competitive analysis document displays two critical dimensions: the competitors and the criteria, or the competitive framework. The purpose of the competitive framework is to present the analysis data in a way that makes it easy to compare the various products, companies, or services across the different marketplace features or comparative criteria.

Elements of an effective competitive anlysis

Competitive analyses vary along two dimensions: competitors and criteria, and so it is common for most competitive analysis documents to provide a visual mechanism for representing two or more products or services side-by-side with the differences showcased. The specific nature of those differences will vary depending on the competitive criteria the analysis author has selected. These competitive anlysis documents can vary in size, with some much longer than others because they their authors have elected to highlight more product features or more marketplace competitors on the analysis document.

“Two-by-two” competitive analysis plot

Every competitive analysis document shares three essential elements: a purpose statement, the competitive framework, which is the competitors and the criteria, and the comparative data. The analysis document may also provide more details about the overall products, the competitors and their market positioning, or the method behind the comparative analysis results.

The purpose of the competitive framework is to present the data in such a manner as to make it easy for a reader or viewer to compare the products or service offerings across the different comparative criteria.

When the competitive framework takes the form of a table, the competitors or products can run along the top of the table and the comparative criteria along the side. The criteria can vary from the very general to the very specific.

A typical table competitive analysis

A different kind of competitive framework is known in MBA programs as the “two-by-two” graph or plot. The “two-by-two” plots competitors or products on a simple grid depicting only two comparative criteria.

In a two-by-two competitive framework, the number of criteria is down to two, so the analysis tends to be much broader than a traditional competitive framework. The “two-by-two” competitive framework is excellent at turning subjective information into objective information. Although it is technically possible for a “two-by-two” competitive analysis author to use real numbers and actually plot along the scale, most two-by-two presentations are ideal for very broad criteria that might not lend themselves to hard numbers. This type of plot is useful to help identify holes in a market or competitive landscape. Competitors that are clustered around certain areas of the two-by-two plot may indicate that there are opportunities for a competitive product or service to fill those vacuums.

A “two-by-two” competitive analysis plot

Some research organizations use a modified version of the “two-by-two” plot format. Sometimes you may see competitors plotted out on a single square, with “waves” or “bands” of features, strategies, or market postions illustrated as areas of the single square. This format is equally effective, and it has the advantage of being an excellent format for the creation of a catalog of different one square competive analysis plots, one for each area of focus within the competitive landscape. So you could for instance have a single square plot for market positioning, one for revenue or scale of business, one for pltting out competitors’ different revenue situations, etc.

An example of a “wave” or “band” single-square plot

Yet another competitive framework that appears in competitive analysis documents and especially comparisons of different sites or user interfaces: the “small multiples”. This term was coined by information architect and data visualization guru Edward Tufte. In Tufte’s “The Visual Display of Quantitative Information”, he states, “Small multiples represent the frames of a movie: a series of graphics, showing the same combination of variables, indexed by changes in another variable.” In other words, “small multiples” are a series of graphics that allow the viewer to easily compare similar sets of information. In the case of user interface design or information architecture for the web, or graphics design for print or interactive media, this approach is most effective for comparing online and offline page layouts or interactive storyboards.

“Small multiples” chart comparing web site detail pages

Sometimes a competitive analysis will take the form of a table, with various stages of detail added as comparative criteria for each competive category. Great care should be taken by the author of the competitive analysis document that the length of the analysis does not become too unwieldy. Consider breaking up long competitive analysis documents into sections or categories.

Try to use as many graphic elements as possible in your competitive analysis documents. Graphs, charts, plots and tables are all excellent ways to present your competitve analysis data, and you should leverage these artifacts into your presentations and marketing communications.

The data is of paramount importance in a competitive analysis. The data can be as simple as yes-no values, indicating whether a product or service or competitor meets a particular criterion, or it can be descriptive, going into some detail for each criterion.

Yes-No values are a very common way to provide differentiating data in a competitive analysis. You’ve seen these kinds of competitive analyses on infomercials where the product in question is lined up with “other leading brands.” For each feature, the product gets a check mark while its competitors get an X, to show you how versatile the product is.

Feature comparison table

Spelling out your process can help address any possible methodological inadequacies. You might want to spend some time in a section of your competitive analysis document rationalizing the selection of competitors and criteria to increase the impact and veracity of your conclusions.

Explanation of a competitive analysis methodology

Subscribe to HubTechInsider on YouTube

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

What is a Product Roadmap? What is an Engineering Roadmap? July 21, 2011

Posted by HubTechInsider in Agile Software Development, Project Management.
Tags: , , , , , , ,
2 comments
English: Five-Year Technology Roadmap

English: Five-Year Technology Roadmap (Photo credit: Wikipedia)

What is a Product Roadmap? What is an Engineering Roadmap?

Product roadmaps can provide an organization, particularly a software development one, with the critical difference between success and failure when marketing and delivering software, services, or products to the marketplace.

While normally the purview of a product manager or director, another senior manager (project, program) or executive can also be charged with preparing and presenting a product or engineering roadmap, and when prepared properly, they can be extremely effective.

The benefits of roadmaps can include retention of key customers, business and channel partners, and engineering and product roadmaps can ably guide the strategic planning and engineering efforts of a company.

As amazing it may sound, I have frequently encountered, within the development organizations I have worked at within the Boston area, a lack of types of artifacts I am about to describe. The lack of product and engineering roadmaps that are accessible to viewers, easy for presenters to use in their slide decks and demos, and visually compelling enough and understandable enough so that audiences can grip the feature sets and timelines shown to them is a major cause of planning and project failure.

It is easy to visualize, once we have gone into a bit more detail regarding the different types of product and engineering roadmaps, how project and product planning attempts at companies without these types of deliverables (or the in-house skillset required to even prepare such artifacts) fail miserably. Computer programmers are not the best resources, in general, to call upon to produce these types of artifacts, nor are engineers who have been promoted to management positions. Typically the best preparers of roadmap documents will be from the business or management world, or have a diverse skillset that may be based in engineering, but you definitely need people who can generate business documents quickly and effectively.

Having folks that are knowledgable and skilled with graphic design programs like adobe photoshop, Illustrator, and microsoft visio can speed the roadmap creation process tremendously. When you have found the right internal resource or team to create these roadmap documents, you will know it, as the right people will already possess some amount of experience with roadmap and business strategy content creation.

It is not enough, please keep in mind, for a company to “short shift” the production of these roadmap documents, because it is only through the repeated creation of roadmap documents, and through their constant updating and presenting to audiences internal and external, will your organization be able to increase its ability to produce roadmap documents quickly.

A complete catalog of engineering and product roadmap documents should be created: eventually. If your company cannot mount such a concerted document creation efforts due to staffing concerns, just create what you can. Cherry pick the type of roadmap document you think would create the most value for your own organizational requirements from my detailed list below.

An example of a roadmap from Microsoft

It could very well be that your organization’s needs for a roadmap document are clouded by the sales department or company management demanding an engineering or product roadmap (sometimes in support of sales efforts) under-the-gun. Never fear: I have not only provided the information you need, I have lots of examples and pictures of product and engineering roadmaps as well as Microsoft visio and excel templates for simple and complex roadmap documents. You can use these microsoft excel product roadmap template and microsoft visio product roadmap templates to create your product or engineering roadmap quickly, avoiding trouble just when you’re getting started.

If you are a product management professional, and you are tasked with the responsibility for the ultimate success of a product line or engineering effort for your company, it is of paramount importance that you produce a roadmap document that can drive strategy, provide a clear idea of where you are headed with your efforts or product(s), and can be shared easily with internal and external stakeholders and business partners and analysts, even the press.

A product or engineering roadmap document may be appropriate when you are called upon to support a pre-sales or sales effort for your organization. Demos, presentations, press releases, investor and business meetings are all very good occasions for product or engineering roadmaps to assure clients, partners, and employees that there is a consistent and cogent plan of action and guide for resource planning and engineering efforts.

There is a wide variety of different names and definitions for all manner of roadmap documents. The important principle to adhere to is you should find and adapt the type of roadmap document you are comfortable with and that you find works for you.

What are the different types of product roadmaps? What are the different types of engineering roadmaps?

Speaking generally, there are five major types of roadmap documents: Product roadmaps, platform roadmaps, market roadmaps, strategic roadmaps, vision roadmaps, and technology or engineering roadmaps. You can, of course, mix and match these roadmap types to suit your organization’s needs.

How do you create a product roadmap? How do you create an engineering roadmap?

There are eight steps I always follow when I am asked to create each of these types of roadmap documents – you can mix this list of steps with your own ideas and experiences in creating roadmap documents:

1. Decide upon which type of roadmap document you will use based on your individual requirement for a roadmap document.

2. Think about how much time and effort, as well as level of detail, you think will be required for you to invest, or that you care to invest, in the creation of your chosen roadmap document type.

3. Brainstorm about significant forces or trends that you might want to represent on your roadmap document. These could include technical breakthroughs, market forces, and moves the competition has made recently.

4. Elicitate the precise roadmap document requirements from the primary internal stakeholders in the project, and document and prioritize those requirements, being careful to estalish and maintain traceability.

5. Product Roadmap documents are intrinsically linked with time, so think about the timeline you want to use and represent in your document.

6. Think about the impression your strategy will make and how you want to present that strategy in your roadmap document. This is one of the central purposes of the document you are preparing, to show that you have a strategy and are planning to implement it well and to schedule.

7. Sometimes I create an internal roadmap document and distribute it to the primary internal stakeholders within my organization for review and commentary. After gathering the project team’s comments regarding the internal roadmap, there is a good basis on which to draft the external roadmap document.

8. This colloborative approach is critical to obtaining buy-in from senior management as well as the roadmap document project team. This method also prevents surprises and last-minute revisions. Discussions surrounding the creation of roadmap documents can help solidify the company’s direction and clarify the intents of management to employees very effectively.

Prioritizing product and engineering roadmap features

There are probably potentially many features you could choose to highlight as a part of your product or engineering roadmap document. But in the interests of brevity and clarity, you will need to prioritize the features that are included in each of your upcoming product or service introductions or software releases and shown on your roadmap.

I have always found that a prioritization matrix document is the best bet for effective and colloborative feature selection for inclusion in a roadmap document. Microsoft Excel or another computer spreadsheet program works very well for preparing this type of document. The matrix should hold information regarding such components as startegic importance, tactical importance to the current release cycle, customer desireability level, retain revenue threat from customer dissatisfaction, revenue impact, source and date of the feature, planned release, etc.

Themes can be used to categorize major feature trends that you begin to see emerge from your prioritization matrix. Categorize like features into themes and then select one or a few major themes to represent graphically on your roadmap documents.

Timed release cycles use the timescale along the edge of your roadmap document to show when features will become available. This type of roadmap document is driven by time and not by features. Once the release interval is decided upon, then the feature list is divided up amongst the releases those features are planned to become available with.

The golden feature technique is one where each release is governed mainly by one important or central feature. Once you have selcted the golden feature for each release of a product or service that you are attempting to show on your roadmap document, then you will be able to focus the audience’s attention on that one feature, and highlight it in all your continued planning efforts for that release.

Using multiple roadmap documents

Combining a few or several different types of roadmap documents can greatly enhance your presentation, showing that you know where your company is headed and why it is that you have choosen to pursue a certain strategy. A vision roadmap could be used to open your presentation, showing trends in society at large that are afecting your marketplace. A technology roadmap could then be shown to your audience that reflects how your company and it’s products are capitalizing on technology trends within the marketplace. Then it is time for you to show off your internal and external product roadmaps, and perhaps your engineering roadmap that shows your planned releases and when certain feature sets will become available.

Showing multiple product lines on roadmap documents

You may need to show a few or several of your product lines on a roadmap, in order to visually represent how each of your product lines will evolve in accordance with a technology or marketplace trend. This is very easy to accomplish; simply create a roadmap document for one of your product lines or services,and then use that one product line as a template for showing the others on your single roadmap document.

I have found that it is helpful in many cases to create a prioritization matrix such as the one I mentioned elsewhere in this article regarding features to show on your roadmap documents. You can also create a product line prioritization matrix that can be used for discussion and colloboration with your internal stakeholders.

A product roadmap showcasing multiple product lines

Try and decide upon which projects, products, or services your company is undertaking that are the most important to your company, which ones should be funded and resourced, and which ones should be cut. Revenue potential, market positioning, strategic importance to the company, and interdependencies can and should be plotted out on this matrix. Once you have decided which products you want to represent on your roadmap document, it is a simple matter to modify your format to include multiple product lines on a single roadmap.

Five tips for creating product roadmaps

Here are a few more best practices that I have discovered throughout my career of preparing product roadmap documents.

It is essential that you realize from the outset that when working with a technical (programmer) audience in certain working environments, there may be a fair bit of resistance or friction originating within internal departments or product groups at your own company that you will need to overcome.

Many internal stakeholders may take umbrage at the point in the release cycle that certain features are slated for release on your roadmap document, they may assert strongly or even rudely that your presentation is false or feature sets you are publicly committing to will not be available.

It is important for you to always be ready to provide reasoning why the roadmaps are necessary, and why managing without such documents, at certain levels of business, becomes untenable.

1. Make sure that you colloborate early with your team. Your chances of being able to secure ultimate buy-in from the different internal constiuency groups within your company goes up markedly if they have been included from the roadmap document project’s outset.

2. Always use code names on your roadmap documents until they have been approved by the senior management team for release to the public at large. You cannot be sure that your roadmap documents will not be leaked out, even by senior managers. You can revise the code names to final product and project names when they are approved.

3. Minor releases and localized, international releases are sometimes not shown on product or engineering roadmaps, and they should be included, as they frequently enter into the follow-on conversations.

4. Create roadmap documents for an internal audience that are very specific in information and dates; roadmap documents intended for an external audience should be worded in more vague language and terminology.

5. Present your roadmap documents as uneditable adobe .pdf documents — this will prevent other parties internal to your company from taking the roadmap documents and altering them – these alterations can emerge unpleasantly later during the project(s) as a committment made to a client or customer by a senior manager or executive, so take care to avoid this scenario.

Examples of internal and external roadmap documents

Product roadmaps

Microsoft SQL server product roadmap

If you need to show your audience when your product’s new features will be available, what the theme or main and secondary features of the product release or next few releases will be, then an effective product roadmap should be your tool of choice.

Internal product roadmaps can be used to communicate budget, resource planning, project priority, and release planning to employees and department heads. They are extremely effective for driving efforts to obtain funding from senior management or corporate action committees.

An example of a product roadmap

External product roadmaps can be used to support funding efforts from investors or investment groups, business partner meetings. External product roadmap documents and slides can be used to reinforce public press releases and press conferences, analyst meetings and conference calls or webcasts, clients and channel partner webinars. It is oftentimes apparent that external roadmaps have been recast in a more vague tone as a result of internal roadmap feedback, which is generally a good thing.

Platform roadmaps

A platform roadmap

A platform roadmap is used to showcase what will be n the works for the platform or PaaS (Platform as a Service) that a particular company has under development. They are used to communicate that company’s overall platform strategy and the availability of APIs (Application Programming Interfaces, basically plug-ins to amd from the company’s platform software) and development tools for the company’s platform or PaaS.

If a company has developed and is supporting a platform in the marketplace currently, you can be sure that they have a platform strategy that relies on partners and clients working closely with them. The need to communicate the platform’s strategy in a clear and focused manner is very important. Examples of platforms include Salesforce.com (Force.com), Windoes (Windows Azure Cloud), Amazon S3 and Ec2, Google, Apple Mac OS X, Apple iOS, Hp WebOS, and many others.

Vision roadmaps

A vision roadmap example

There are times when at the onset of a demo or presentation, it is necessary to highlight for your audience how your product or products fit into a movement or trend within society in general or your company’s inductry in particular. This is a fantastic way in which you can build excitement and marketplace momentum for your company’s products or services by visually demonstrating how you fit into the big picture.

Marketing roadmaps

Microsoft Windows OS roadmap

A marketing roadmap communicates to your internal and external stakeholders what market segements your products and services are targeting, and how you plan to enter any of those markets in which you are not currently competing. As such, these types of roadmaps include information on the demographics and opportunity size of each marketplace, and information regarding how you plan to develop products and services to address each market. The timescale involved on marketing roadmaps can span years.

Marketing roadmap example

A marketing & strategy roadmap

Technology and Engineering Roadmaps

Technology and engineering roadmaps chart out major technology trends that exist in the marketplace, and show how your company’s products and services coordinate with those trends over time. Engineering roadmap documents are used to communicate feature sets that will be available in certain releases. The approximate release dates of each of the company’s upcoming product releases will be shown.

A technology roadmap

It is very common for a software development organization to create and maintain multiple engineering roadmaps, suitable for showing to various segmented audiences of internal and external stakeholders and directly responsible individuals. These engineering roadmaps are super tools for updating major clients and customers of your release cycle and aid greatly in the change management process.

A Microsoft Technology Roadmap

Engineering roadmaps also provide your internal development groups, qa, testers, programmers, business analysts, and product, program and project managers, as well as senior management, with a view into the development life of the company. A development organization that fails to produce such planning artifacts is essentially flying blind, and as they scale up (if they do scale up) as their business improves, they will find they lack the requisite skills needed to plan effectively and manage their clients’ expectations for quality products, software and services well.

Product roadmap template

Engineering roadmap template

I have included in this article many pictures and descriptions that you can use to create your own highly compelling product roadmap documents. They should serve as an excellent guide for not only the different types of roadmap documents that exist out here in the marketplace, but also how to place multiple product lines and services on a roadmap document.

Keep in mind, these are living documents, and should be continuously maintained and updated. Do not succumb to the programmer’s maxim “You can’t plan the future”. Remember: Plans are worthless, planning is priceless. The activity of creation, the discussion that surround the roadmap process, are all essentially components of effective long term product planning and corporate strategy.

Roadmaps can be used to share information with internal teams, external constituents or as a planning tool for the Product Management team, but whichever you choose, you have to figure out whether you are going to make the focus of the roadmap strategy or release calendar. If it is strategy, your timeline can be vague — quarters or years. If it’s release calendar, the near-term has to be pretty specific: exact date or month, but the future can be more nebulous.

I have include a few simple microsoft visio and microsoft excel roadmap document templates to get you started. By all means, you should feel free to use the illustrations and prose contained in this article, as well as any graphics or business drawing tools that you are comfortable with, to create your own formats and presentations. Some of my favorite programs for creating these types of artifacts with include adobe illustrator, photoshop, microsoft visio, microsoft excel, and coreldraw. I also have a big bag of Linux and Apple Mac OS X tools that I use to create roadmap documents in addition to the ones I have just mentioned. Product management software such as Accept, Accompa, FeaturePlan, FocalPoint and others can also assist you in creating roadmap documents. If you need help or advice, I am always available via email or social media like LinkedIn. If we’re not connected on LinkedIn, please send me an invitation to connect. And good luck with your roadmaps!

roadmap_template1


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is  Tshirtnow.net.

HubTechInsider.com YouTube Channel

Subscribe to HubTechInsider.com YouTube Channel

SEO Made Easy 2013 FREE Special Report!

PHP for Beginners

Google + Domination for Business

LinkedIn for Business Training Course

Mastering WordPress Video Training Course

Twitter Business Magic Video Tutorial Series

What is UML? What is Unified Modeling Language? July 17, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , , , , , , , , , ,
add a comment
A collage of UML diagrams including use case d...

A collage of UML diagrams including use case diagram, class diagram, activity diagrams, sequence diagrams, deployment diagram,component diagrams, composite structure diagram, package diagrams. (Photo credit: Wikipedia)

 

What is UML?

UML is an acronym for Unified Modeling Language. UML is widely accepted as the de facto standard description language for the specification and design of object-oriented software systems. UML is a family of “languages”, or diagram types, that attempt to bring together the “best in breed” software specification techniques for describing software systems. Users and practicioners of UML can choose which members of the family are the most suitable for their application domain.

Personally, I have become associated with UML through my years and years of specifying software products. Several of the UML diagram types that I will discuss below are among my primary tools for communicating application and system requirements and software designs to programmers.

I do not advocate, nor do I personally practice, an over-attachment to UML. Like many of these project management and requirements management techniques, there is a time and a place for the proper introduction of these types of UML artifacts into the software development process. Programmers may be unfamiliar with the UML diagram types and symbology, and so if you are a business analyst, project, program or product manager, and you are using these types of project deliverables with a new staff of engineers, be prepared to explain the UML diagram type you are using, keep the introductions down to one or two different new UML “Languages”, or diagram types, at a time.

I also recommend that if you insert UML diagrams into your functional specification documents, and I recommend that if you have invested the time to properly prepare UML diagrams that you do leverage them into your spec docs, make sure that you include an explanatory prose component into your accompanying functional specification document’s text.

There are nine different types of UML languages, or diagram types:

1. Use Case.

2. Sequence.

3. Collaboration.

4. Statechart.

5. Activity.

6. Class.

7. Object.

8. Component.

9. Deployment.

Five of these diagram types render behavioral views, the use case, sequence, collaboration, statechart and activity diagrams, while the remaining four diagram types are concerned with architectural or static aspects of the software design.

 

How does UML help in specifying a software design?

UML is a graphical language that is based on the premise that any software system can be described in terms of interacting business entities and that various aspects of these entities and their interactions, can be described visually using one or more of the above nine types of UML diagrams.

Use Case diagrams represent and document the dialog between external (to the system under discussion, as in an embedded system) actors and the system.

Sequence and collaboration diagrams describe interactions between objects.

Activity diagrams illustrate the flow of control between objects.

Statecharts represent the internal dynamics of active objects.

 

What is UML 2.0?

UML 2.0 is a revision to Unified Modeling Language that incorporates several improvements to UML. UML 2.0 is only just now beginning to supplant UML as the de facto standard.

A shorthand description of UML 2.0 is that it is designed for more rigor of specification, and it can sometimes be too much, or too much of a fine-grained distinction to bandy about when in an actual day-to-day, working software development environment. You are very likely to be working with only a subset of the UML languages, or diagram types, I outlined above at any one given point in the development project.

UML 2.0, when the diagrams are laid out in a software program such as VisualUML or others, can actually be used to generate working object code. If the business analysts have developed their proficiency enough with UML diagramming software, they can actually construct and output from these programs working java (or other programming language) object code.

In order to obtain this level of integration with application programmers, UML 2.0 had to have more access to a more robust and constrained specification language. The improvements to UML 2.0 include:

1. New base classes that provide the foundation for UML modeling constructs.

2. Object constraint language, a formal method that canbe used to better describe object interactions.

3. An improved diagram meta-model that allows users to model systems from four viewpoints:

a. Static models (e.g., class diagrams)

b. Interaction (e.g., using sequence diagrams)

c. Activity (i.e., to describe the flow of activities within a system)

d. State (i.e., to create FSMs, or Finite State Machines, using state charts)

UML has always been used to not only specify software systems for systems and application programming, but also specification for embedded systems as well. This emphasis on the notion of time and state is evident in the way that sequence diagrams are implemented in UML, and indicates the special considerations that were undertaken to support embedded systems design in the original conception of UML.


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

What is pattern-based software development? What is pattern-based design for software projects? July 17, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , , , , ,
1 comment so far

UML class diagram describing the Prototype des...

Image via Wikipedia




What is pattern-based software development?

What was the original impetus behind the development of software development patterns, and why do we need them? Why did programmers invent patterns for software development?

Well, developing software is very difficult, and developing software that can be easily reused is even harder. the designs for sections of software code should be general enough solutions to be able to address future problems and requirements flexibly while still being specific enough in order to address the current problem at hand. Programmers that are experienced at designing software systems know better than to design their system using one-off problem solutions, and instead reuse patterns that they have grown familiar with through prior use in similar situations and scenarios and reuse these solutions as a basis for their new designs. The basic fundamental principle of software engineering known as the “Principle of generality” predicts and encourages this behavior.


What’s so great about programmers using pattern-based development on software projects?

For one thing, it is absolutely fascinating to sit in a meeting room with a group of programmers who have been working all together on a software development project using patterns for a few months. The rate of information exchange is extremely high, with a idea mentioned by one programmer, and a few others simultaneously finishing the first programmer’s sentence with an exclaimed, unison word like “Bridge!”, and then one of them scribbling lines of code frantically on the whiteboard as the rest nod in compliment.

The language of the programming team using patterns is mysterious and magical, almost like incantations spoken in some artful black language. Many computer science instructors contend with conviction that the teaching of patterns and the learning of them speeds the learner’s adoption of the principles of object oriented software technology. It is undeniable that the learning of patterns improves the programmers’ development vocabulary.

Software design patterns also help in finding appropriate objects, in determining the apropos object granularity and in designing a software system that is architected from the outset to better adapt to change. At the design level, patterns enable large-scale reuse of software architectures by capturing the expert knowledge of pattern based development and distributing it throughout the development team.

It is generally acknowledged that these are the two most important benefits: the way in which they form a vocabulary for articulating design decisions during the normal course of development conversations among promgrammers. This can also come into play during the close programming work of so-called “pair programming“, among those who have found it to be useful for them.

When you are working with a group of programmers who are either working in pairs or as part of a group using pattern-based development, you frequently hear talk like “I think we need a strategy here”, or, from one programmer to the rest of the group, “Let’s implement this functionality as an Observer”.

Programmers’ familiarity with pattern-based development has also become a kind of hiring shorthand. Whenever a talented programmer leaves a software development team I am leading, and we need to replace him or her with anther programmer, I use the “Do we need a programmer familiar with design patterns” question as a line of demarcation for recruiting and hiring decisions. The answer is *not* always to hire an expensive programmer intimately familiar with design patterns, either.

It is fashionable in development manager circles to use design patterns as a hiring demarcation line as well, as in the following exchange:

“So…regarding design patterns: what would you say is your favorite design pattern?”

“Well, the factory, I guess.”

“Yeah…OK…thanks for coming down.”


What does a software development pattern look like?

A pattern is a problem-solution pair that can be applied in a similar fashion in new contexts; the pattern is complete with advice on how to apply it in the new context. It is important to note that the formal definition of a pattern is not consistent in the literature.

There are three types of patterns:

1. An architectural pattern occurs across software subsystems.

2. A design pattern occurs within a subsystem but is independent of the language.

3. An idiom is a low-level pattern that is programming language-specific.

Each individual pattern is compromised of four elements:

1. A name. Some of the names of the software design patterns can be rather whimsical: “flyweight”, and “singleton”. The whimsy is to serve the purpose of making the patterns memorable to programmers.

2. A problem description. The problem part of the pattern describes the problem and its context, as well as specific design issues such as how to represent algorithms as objects. The problem statement may also speak about when it is best to apply this particular pattern and may also describe class structures that are symptoms of an inflexible software design.

3. A solution to the problem. The solution part of the design pattern does not desibe any one particular concrete design or implementation, but only describes the elements that make up the design, The solution only provides a general arrangement of objects and classes which can be used to solve this type of problem.

4. The consequences of the solution. This part of the design pattern describes the results and inherent risks and trade-offs associated with applying this particular design pattern. It may include the impact of this design pattern on space and time, programming language and implementation issues, or include notes on software flexibility, system extensibility, and portability. These consequences are critical for evaluating alternative software design patterns.


What is the history of software design patterns?

The concept of design patterns was first introduced by Christopher Alexander for use in architecture and town planning. He realized that architects encounterd the same sorts of problems when engaged in the design of buildings and once an elegant architectural solution to these common problems was discovered, it could be repeated over and over again. In 1977, he wrote a book, published by the Oxford University Press, called “A Pattern Language”, in which he stated:


“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”

Design patterns as an idea were first applied to computer software programming in the 1980’s, when the infamous “Gang of Four” book, “Design Patterns: Elements of Reusable Object-Oriented Software” popularized the use of design patterns. Ward Cunningham, Kent Beck, and Jim Coplien were some of the initial practicioners and popularizers of software design patterns.


What are the “Gang of Four” software design patterns?

The “Gang of four” book first introduced this set of patterns into the software programming world. The book lays out 23 design patterns for software development, and it was first published in 1995. Building upon the work of Kent Beck, Christopher Alexander, and others, the gang of four set out to redirect all of the effort being put into “rengineering the wheel” in software development teams all over the world and redirect it into something much more useful.

The book was an instant hit with computer programmers, selling over half a million copies since its publication in 1995 and undoubtedly influencing the thoughts and code of millions of computer programmers worldwide. Many computer programmers can vividly remember buying their first copy of the book and in addition many computer programmers look upon their reading of the book as a rite of passage. It can be a difficult book to get through, and it is not infrewunt for even advanced computer programmers to have to spend several readthroughs in order to extract the desired effects out of their investment of time in the gang of four’s words. The book did two very important things for programmers:

First, computer software programmers were introduced to the world of design patterns, where each pattern is a prepackaged solution to a common design problem. The book encourages programmers to look at their code and to find and identify common solutions to common problems. Programmers should give each solution a name, and they should talk about what each solution is good for, and when to use each solution, and when to reach for something that is a more appropriate solution. If all of these solutions are documented well, then over time more and more programmers will become better and more effiecient programmers, and this knowledge can be distributed throughout the developer community in the most direct and sane way.

Secondly, the book describes 23 software design patterns that are organized into three groups based on the intention for their use: creational, behavioral, or structural:

1. Creation design patterns are associated with object creation and their intent is to allow programmers to create software objects without actually knowing what they are creating beyond the interfaces themselves. There is a fundamental principle in computer programming, known as information hiding. When programmers code using interfaces to object creation and objects, then they are following this fundamental principle well.

As described by Gamma, Helm, Johnson and Vlissides, the “Gang of four”, these creational patterns include the abstract factory, the builder, the factory method, the prototype, and the singleton.

2. Structural design patterns are concerned with organization classes. Structural design patterns are static in nature; they are not designed to change. As laid out by the Gang of four, structural design patterns include the adapter, the bridge, composite, decorator, facade, flyweight, and proxy.

3. Behavioral design patterns are concerned with runtime or dynamic system behavior of the program, and they help define the roles of software objects and their interactions. By their dynamic nature, behavioral patterns are designed to change, and are not static and contain very little “structural” code. The gang of four describe behavioral software design patterns called the chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method and visitor.

In the years that have followed the publication of the gang of four book, and as I will get into in more depth here in a moment, many different sets of alternative design patterns have been proposed. the original gang of four patterns – the 23 patterns I wrote of above – really stick to the old school, middle ground of object-oriented software design. Smaller than a database system, but larger than just a simple hashtable. They focus on some very key questions that face all programmers that are tasked with building an object oriented software system: how do you know what types of objets to create, how many, and how? How should these objects relate and interoperate? What should they know about each other? How should they be coupled together? How can programmers swap out parts that are likely to change frequently with the most efficiency?


What are some of the situations in which a software design pattern might be used?

Each individual situation which is faced by software programmers will have an individual solution tailored for that specific situation. If this were not the case, then a piece of complete, reusable software code could be used, instead of the rough problem-solution description of a design pattern.

It is not difficult, however, for me to illustrate a few of the scenarios and what type of design pattern could potentially be used to address this situation:

If a programmer is faced with a situation in which there needs to be one and only one instance of a class in the application – the single class that everybody uses. This would be a scenario for the singleton pattern.

If a programmer needs to include code from another programming language to best solves the problem at hand, then the programmer could use the Interpreter design pattern in order to use that code programmed in another language directly.

If a programmer is faced with a scenario in which an object needs to be created according to a complex, precise, and changing, set of parameters. In this circumstance, perhaps the builder pattern would be best to utilize.

If a programmer or development team is faced with a scenario where they have objects which need to take on additional responsibilities at runtime in addition to their established responsibilities, then the decorator design pattern made be called for.


Are there any other popular sets of software design patterns?

There are indeed many other sets of software design patterns. For instance, Martin Fowler laid out a very popular set of software analysis design patterns in his 1996 book, “Analysis Patterns: Reusable Object Models” , and there was also a set of software architecture and design patterns laid out in the excellent and well-read book, also published in 1996, “Pattern-Oriented Software Architecture, Volume 1: A System of Patterns“.

But one of the most popular and well-known, regarded, and most-used set of software design patterns was popularized by Craig Larman in his 2002 book, “Applying UML and Patterns“. He called them the GRASP patterns, for general principles in assigning responsibilities, and they are a fairly high-level set of patterns for software design. There are nine GRASP patterns for software design:

1. Creator.

2. Controller.

3. Expert.

4. Low coupling.

5. High cohesion.

6. Polymorphism.

7. Pure fabrication.

8. Indirected.

9. Protected variations.

I will select one of the GRASP patterns I have listed above and describe what the pattern actually is in terms of the name of the design pattern, the problem the design pattern is trying to solve, and the solution for the problem as implemented using the design pattern.

For instance, a scenario that would be best served by the Creator design pattern would be one in which the problem is that it is unclear who should be responsible for creating a new instance of a class.

The solution as proposed by the Creator pattern would be to assign this responsibility to a class B to create an instance of class A if one or more of the following is true: (a) B aggregates A objects, (b) B contains A objects, (c) B records instances of A objects, (d) B closely uses A objects. B has the initializing data that will be passed to A when it is created.


How about design patterns in the Ruby programming language?

You probably realized that I wasn’t going to write an entire article of this length and depth without pimping Ruby. Design patterns are particularly easy to implement in Ruby, partially because of similarities between Smalltalk, the programming language used by the Gang of four to illustrate their programming examples in their design patterns book, and Ruby, and partly because of syntax peculiarities inherent in the Ruby programming language.

Ruby’s absence of static typing lowers the overall number of lines of code to begin with, and the Ruby standard library (if you have been paying attention, you recall the difference between code libraries and design patterns) makes it possible to implement many of the most common design patterns in Ruby with a single one-line include.

Other design patterns are essentially built into the Ruby programming language itself. For instance, a Command object in the canonical Gang of four sense is a state-aware code wrapper, something very closely approximated by a Ruby construct known as a Proc, or a Ruby code block object. This is not to say that although a simple Command construct can be implemented in Ruby with a single one-line include, if we add more complex state and behavior information to the block, the implementation will not need some additional Ruby code. As I stated earlier in this article, and without equivocation, design patterns do not lead to direct code reuse, this is the work of software libraries.

The main point I am trying to promote is that because design patterns are the common idioms of object-oriented software code, a good or great programming language should make design patterns easy to implement, or even make the use of them nearly a transparent excercise, as if the design patterns’ usage was inherent in the use of the language itself.

Ruby works marvelously well in a pattern-based software development environment because:

1. Static typing reduces code bloat and overhead. Common patterns can be implemented in less code. You can turn a class into a singleton with a simple “include singleton” command.

2. Ruby has code closures, which means that chunks of code can be passed around complete with their associated scope within a program without having to construct entire classes and objects whose only purpose is this scope and code transferral.

3. Ruby classes are real objects, so any runtime operation that can be applied to a Ruby class can be used to implement the logical intent of any of the design patterns. A Ruby class can be modified by adding or deleting methods. A class can be cloned and the copy can be modified while leaving the original class unmodified.

4. Ruby has mixins, which in addition to the same inheritance of other programming languages, is a simple yet sophisticated way in which Ruby code can be shared among several Ruby classes.

One of the books I recommend all Ruby programmers read is “Design patterns in Ruby“, by Russ Olsen, with a foreword by renowned Ruby programmer Obie Fernandez.

In the book, you will learn why there are only 14 patterns in Ruby instead of 23 original Gang of four patterns, and you will also find out about three new Ruby-specific design patterns that have a great deal of usefulness in Ruby.


Are there any drawbacks or negatives to using pattern-based software development?

Well, actually, there are several drawbacks to all of this talk of pattern-based software development.

One of the main drawbacks, and one of the most important thing for technical project managers and business stakeholders as well as senior managers to keep in mind, is that patterns do not lead to direct software reuse.

Direct reuse of sections of software code is for software libraries. Patterns do not create or promote software libraries of reuable plug-and-play software code, but rather lead to reuable design, architectures and techniques which can be converted by computer programmers into unique program code.

Even though the cutesy names of software design patterns may lead you to believe that they are also simpe to learn, they are not. It is easy enough to master some of their names, and to also memorize their structure visually, but it is not very easy to see how they can lead to actual design solutions. This can take even very experienced computer programmers years and years of practice, education and working experience.

Integrating the use of software patterns into an actual, real-world development organization’s daily development life and regular deployment cycle can be a daunting task. The integration, aside from the demands the aforementioned education and training can take on a development staff compromised of computer programmers unfamiliar with the software design patterns described above, is a very labor-intensive activity.

A software development team’s programmers may experience pattern overload, whereby in their unending quest to use pattern-based techniques, they have become an obsession rather than as an effective and efficient means to an end. Aa mentioned above, software design patterns are no silver bullet, and do not lead to direct code reuse, but rather provide another approach to systematically solving software design problems that are commonly and frequently encountered by software development teams.


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What are the qualities of bad software code? How can you tell if your software project has bad code? July 12, 2011

Posted by HubTechInsider in Agile Software Development, Project Management, Software.
Tags: , , , ,
1 comment so far
User:Dreftymac/Docs/ImageDisclaimer

Image via Wikipedia

What are the qualities of bad code? How can you tell if your software project has bad code?

Troubled software projects and bad code are facts of life in the software business. Today’s applications, system software, even embedded and operating systems programming is increasing being outsourced or at least distributed.

The need for being able to quickly evaluate the quality of software code, describe any known issue in simple aterms and then execute on a planned approach to rectify these issues is greater than ever.

A common vocabulary for project teams, refactoring engineers, and project managers and stakeholders is of a fundamental assistance in manageing software development projects.

You may find yourself sitting in a meeting or conference room or perhaps on a conference call with a group of computer programmers who are discussing some sections of code, or if you are particularly unlucky, perhaps an entire application of software development project, that is troubled using some of these below listed terms. After each of these negative, “bad code” terms I have tried to describe what is meant by each of these terms for bad software. After each description, I list the term for the opposite, positive “good code” quality contrary to the bad code quality.

1. Fragility: When changes in the software code cause the system to break in places that have no conceptual relationship to the part that was changed. This is a sign of poor design. The opposite of fragility is known as robustness.

2. Immobility: When the code is hard to resuse. The opposite of immobility is known as re-usability.

3. Needless complexity: When the design is more elaborate than it needs to be. This is sometimes also called “Gold plating”. The opposite of complexity is known as simplicity.

4. Needless repetition: This occurs when cut-and-paste of code segments is used too frequently. The opposite of repetition is known as parsimony.

5. Opacity: When the code is written in such as manner as it is not clear. The opposite of opacity is known as clarity.

6. Rigidity: When the design is hard to change because every time you change something, there are many other changes needed to other parts of the system. The opposite of rigidity is known as flexibility.

7. Viscosity: When it is easier to do the wrong thing, such as a quick and dirty fix, than the right thing. The opposite of viscosity is known as fluidity.

In order for your software development project to feature the opposite, more desirable positive qualities to the ones listed above, your project must exhibit a good software architecture, solid software design, and effective coding practices.

For further reading on this topic, I highly recommend the excellent book by R.C. Martin, “Agile Software Development, Principles, Patterns, and Practices“, Prentice-Hall, Englewood Cliffs, NJ, 2002.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests? October 3, 2010

Posted by HubTechInsider in Agile Software Development, Definitions, Project Management.
Tags: , , , , , , , , , , , , , , , , ,
add a comment
user stories image

Image via Wikimedia

What is a User Story? How are they used in Requirements Gathering and in writing User Acceptance Tests?

User Stories are short conversational texts that are used for initial requirements discovery and project planning. User stories are widely used in conjunction with agile software development project management methodologies for Release Planning and definition of User Acceptance Criteria for software development projects.

User Goals, stated in the form of User Stories, are more closely aligned with Business Priorities than software development Tasks and so it is the User Story format which prevails in written statements of User Acceptance Criteria.

An Agile Project Team is typically oriented to completing and delivering User-valued Features rather than on completing isolated development Tasks.These development Tasks eventually combine into a User-valued Feature).

User Goals are not the same things as software development Tasks. A User Goal is an end condition, whereas a development Task is an intermediate process needed to achieve this User Goal. To help illustrate this point, here are two example scenarios:

1. If my User Goal is to laze in my hammock reading the Sunday Boston Globe newspaper, I first have to mow the lawn. My Task is mowing; My Goal is resting. If I was able to recruit someone else to mow the lawn, I could achieve my Goal without having to do the mowing, the Task.

2. Tasks change as implementation technology or development approaches change, but Goals have the pleasant property of remaining stable on software development projects. For example, if I am a hypothetical User traveling from Boston to San Francisco, my User Goals for the trip might include Speed, Comfort and Safety. Heading for California on this proposed trip in 1850, I would have made the journey in a high technology Conestoga wagon for Speed and Comfort, and I would have brought along a Winchester rifle for Safety. However, making the same trip in 2010, with the same User Goals, I would now make the journey in a new Boeing 777 for updated Speed and Comfort and for Safety’s sake I would now leave the Winchester rifle at home.

· My User Goals remained unchanged, however the Tasks have changed so much that they are now seemingly in direct opposition. User Goals are steady, software development Tasks as stated on SOWs (Statements Of Work) are transient.

· Designing User Acceptance Criteria around software development Tasks rarely suits, but User Acceptance Criteria based on User Goals always does.

A User Story is a brief description of functionality as viewed by a User or Customer of the System. User Stories are free-form, and there is no mandatory syntax. However, it can be useful to think of a User Story as generally fitting this form:

“As a <type of User>, I want <Capability> so that <Business Value>”.

Using this template as an example, we might have a User Story like this one:

“As a Store Manager, I want to search for a Service Ticket by Store so that I can find the right Service Ticket quickly”.

User stories form the basis of User Acceptance Testing. Acceptance tests can be created to verify that the User Story has been correctly implemented.

User Story Card

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies,software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications andsoftware development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

The Hub Tech Insider Glossary of Mobile Web Terminology August 21, 2010

Posted by HubTechInsider in Definitions, Mobile Software Applications, Wireless Applications.
Tags: , , , , ,
1 comment so far
Image representing iPhone as depicted in Crunc...

Image via CrunchBase

Well, as all of my regular readers know, and most casual readers of these pages can probably easily surmise, I am an ecommerce guy.

I have been designing, programming, managing, and just about everything-ing, ecommerce sites and companies for well over 15 years at this point.

I started my first ecommerce site in 1994. My first web site was an ecommerce site, the third web site in the US state in which I was living at the time. So building online stores is something I am super passionate about.

Sometime ago, probably around 2003 or 2004, I became convinced of the inevitability of the mobile web, and mobile web browsing for ecommerce sites.

I never really believed that the mobile browsing and online purchasing experience, or typical use case, for mobile browsing would be the same as the browsing experience on the desktop PC-based web. It just seemed to me that the mobile version of an ecommerce (or any other content-serving web site, for that matter) site would have to be optimized for a person on-the-go.

The appearance of the Apple iPhone really got me fired up about the mobile web, because I saw Apple driving mobile browsing to the fore of the public’s attention. There were several other factors that were, to my mind, inevitably driving the adoption of mobile web browsing.

So I set out to learn everything I could about mobile browsing, browsers, devices, standards, everything about mobile ecommerce and mobile web design.

At this point (summer 2010), I have set up several mobile versions of ecommerce sites. The mobile version of one of  my latest ecommerce projects, tshirtnow.net, is currently responsible for around 9% of that site’s orders, which I find amazing. I expect this number to grow over time.

My employer, eSpendWise, (I am Director of Technical Projects there) is in the midst of developing a very thoughtful mobile portal into the eSpendWise ecommerce and eProcurement platform used by many Fortune 100 companies, like Apple, Inc., Nike, and others. Optimizing the mobile portal for the nomadic browsing experience (picture a store manager approving a shipment of cleaning supplies on their smartphone while running to help a cashier) while still preserving the power and flexibility of the eSpendWise platform, as you might well be able to imagine, dear reader, is a challenging task to say the least.

A recent study by mobile commerce analysts at Morgan Stanley projected that within five years, the number of user accessing the net from mobile devices will surpass the number who access it from PCs.

Because the screens are smaller, such mobile traffic is trending to be driven in the future by specialty software, mostly apps, designed for a single purpose. For the sake of the optimized experience on mobile devices, many users will forgo the general purpose browser for specialized mobile applications. Users want the Net on their mobile devices, but not necessarily the Web. Fast and easy (specialized purpose-built mobile applications) may eventually win out over flexible (the current desktop browser-oriented world wide web).

One thing I recommend is designing to web standards for your mobile applications or portals. In this way, you have the best shot at “future proofing” your mobile optimized content and applications.

During the writing of Functional Specifications for some of the mobile projects I have been involved with or responsible for, I have created a Glossary of mobile web terms and terminology I wanted to share with my HubTechInsider.com readers so that it may serve as a reference for their own mobile web design efforts.

Please don’t hesitate to send me an email with any questions or additions / corrects you may have for me, and please send me a short note with links / information about your own mobile web design efforts!

The Hub Tech Insider Glossary of Mobile Web Terminology

3G – 3G stands for Third Generation and refers to the latest phase in mobile technology. 3G enables much faster connections to the Internet so that you can get richer multimedia experiences such as video messaging.

4G – 4G stands for Fourth Generation and is a somewhat vague term used to describe wireless mobile radio technologies that offer faster data rates than current 3G (third generation) technologies. 4G networks are also more data-centric and based on standard Internet technologies such as IP. Voice service is typically provided using a special form of VoIP. WiMAX and LTE are examples of 4G technologies.

A-GPS – Assisted Global positioning System. This is a mobile-based location technology. The mobile uses A-GPS to work out location with the help of both GPS satellites and local network base stations.

AFLT (Advanced Forward Link Transmission) – AFLT is a mobile-based location technology. AFLT does not employ GPS satellites to work out locations. Instead, the phone measures signals from nearby cellular base stations and reports the time/distance readings back to the network which is then able to work out your location.

BROWSER – Software that allows you to view Internet content on a web-enabled device.

cHTML, C-HTML, Compact HTML – cHTML is a subset of HTML for i-mode browsers.  cHTML is used only in Japan. cHTML is considered technical superior to WML. cHTML was replaced at W3C by XHTML Basic.

CTI (Computer Telephony Integration) – CTI is an optional set of applications that integrate your business’ telephone system with a computer.  Features can include video conferencing, one-click dialing, incoming call routing, and a variety of other timesaving features that could be appealing to large businesses.

EDGE (Enhanced Data Rates for GSM Evolution) – This is an enhanced modulation technique which increases network capacity and data rates in GSM networks.

FEATURE PHONE – A cell phone with lightweight web features, not smartphones.

GSM (Global System for Mobile) – This is the digital network that mobile phones have used to make calls and send text messages, as well as the standard network available across much of the world. The data connection to the mobile internet is a phone call (similar to a fixed line modem) and it is billed relative to the duration of the call.

HDML(Hyper Device Markup Language) Computer language format used to create wireless websites. HDML is the oldest markup language for display on mobile devices (circa 1996). HDML has a very simple syntax. HDML was never standardized, but was influential in the development of WML. No longer used on mobile phones in North America and Europe.

iDEN – a mobile telecommunications technology, developed by Motorola, which provides its users the benefits of a trunked radio and a cellular telephone. iDEN places more users in a given spectral space, compared to analog cellular and two-way radio systems, by using speech compression and time division multiple access (TDMA). iDEN is an enhanced specialized mobile radio network technology that combines two-way radio, telephone, text messaging and data transmission into one network.

i-mode – NTT DoCoMo proprietary wireless Internet service. Provides mobile devices access to web, e-mail and packet data. NTT DoCoMo I-mode is available only in Japan.

IMEI (International Mobile Equipment Identifier) – This is 15-digit number which identifies an individual phone to the network operators.

Java (J2ME: Java 2 Micro Edition) – Java or J2ME (Java 2 Micro Edition) enables users to download tailor-made software applications onto their phones e.g. mobile games.

LTE (Long-Term Evolution) – An effort to develop advanced wireless mobile radio technology that will succeed current 3G WCDMA/HSDPA/HSUPA technology. Although “LTE” is not the name of the standard itself, it is often used that way. The actual standard is called 3GPP Release 8. LTE is considered by many to be a “4G” technology, both because it is faster than 3G, and because it uses an “all-IP” architecture where everything (including voice) is handled as data, similar to the Internet.

MMS (Multimedia Messaging Service) – Also referred to as picture messaging, MMS works much like text messaging but with a greater capacity so you can send larger quantities of text as well as attaching images and audio files from your phone.

NATIVE APPLICATION – Mobile phone software compiled into a compatible binary format, stored in phone memory and run locally on the device. I.e. web browser, email reader, phone book.

PORTAL – A website accessed by desktop or wireless device that provides a wide selection of information from a single place.

PREDICTIVE TEXT (T9: Text on Nine Keys) – Predictive text allows you to enter text by pressing only one key per letter. When you try and text in a word, the phone will automatically compare all of the possible letter combinations against its own dictionary and predict which word you intended to type.

ROAMING – Making or receiving calls (or using wireless data services) outside your home airtime rate area. Additional fees may apply, depending on your calling plan.

SERIES 60 / SERIES 40 – Series 60 is based on the Symbian Operating System and is a major platform for smartphones. Series 60 was developed by Nokia for their own smartphones but they also license the platform to other mobile manufacturers. Series 60 mobiles tend to have a large color display and a large amount of memory for storing content. Series 40 phones tend to have smaller screens and less memory.

SIM CARD – This is the small card that slots into the back of a mobile phone underneath the battery. The SIM card controls your phone number and the Network that it works on.

SMARTPHONE – A smartphone is like a combination of a standard mobile phone and a PDA. Smartphones have their own complete Operating Systems but differ from PDAs in that they have a standard phone keyboard for input instead of a touch screen and pen.

SMS – (Short Message Service) Send or receive messages (up to 160 characters each) using your wireless device.  SMS is also known as “Text Messaging”.

SOFT KEYS – Soft keys can be used for many different functions according to what is displayed on your mobile at any one moment e.g. ‘Select’ and ‘Exit’. They are commonly found right under the display.

SYMBIAN – Symbian is made up of a group of companies (Nokia, Ericsson, Motorola, and Psion) who create operating systems for mobiles and personal digital assistants (PDAs).

SYNCHRONIZED ACCESS – Some companies create a scaled-down version of their website for PDAs. A copy of the site is stored on the PDA and updated each time it is placed in its cradle and synchronized.

TEXT MESSAGING – Send/receive messages (up to 160 characters each) from your wireless device. Text Messaging is also known as “SMS.”

TRI-BAND – A GSM mobile of which there are two major types (European and Americas) and supports three of the four major GSM frequency bands. This type of mobile functions in most parts of the world.

U-TDOA (Uplink Time Difference on Arrival) – U-TDOA is a position-location technology for mobile phone networks. It works out your exact location by using triangulation techniques i.e. by measuring your distance from two known points.

UMTS – UMTS is one of the standard technologies used to enable 3G mobile services e.g. video on your phone.

WAP (Wireless Application Protocol) – This is the technology that enables mobile phones to browse the Internet. Open standard for network communication that allows mobile devices to access the Internet. WAP is a lightweight protocol providing primitive Internet support (from a desktop point of view). WAP was criticized for fragmenting the Web into Desktop and Mobile variants.

  • WAP 1.x – WML
  • WAP 2.x – XHTML-MP

WEB APPLICATION – A web application is an application that is accessed via Web browser over the Internet.  Application runs on a web server. Markup documents are typically rendered on the User’s phone. No binary compilation or persistent local storage.

WiMax – (802.16a) WiMax is the trade name for a family of new technologies related to the IEEE 802.16 wireless standards. WiMax has the potential for very long range (5 – 30 miles) and high speeds. The initial version, based on 802.16a, is designed for fixed (non-mobile) applications only, such as a wireless replacement for home DSL or cable modem service.  Newer versions, such as 802.16e, add support for mobility, potentially making WiMax a competitor for certain 3G or 4G cell-phone technologies. WiMax uses OFDM (Orthogonal Frequency Division Multiplexing), an increasingly common type of digital wireless technology that is also used in some digital radio and television standards. WiMax operates at higher frequencies than mobile phone networks. WiMax technology can operate in the 2.5 or 3.5 GHz licensed bands, or in the 5.8 GHz unlicensed band.

WML (Wireless Markup Language)–  Computer language format used to create websites that can be viewed on a wireless telephone or device. WML is a XML-based markup language for mobile phones. WML has a very simple syntax. WML was standardized by W3C. WML is considered to be a legacy markup language for mobile devices. Implements WAP.

WTAI (Wireless Telephony Applications Interface) – A protocol used in conjunction with the Wireless Application Protocol (WAP) to allow a phone number to be linked to a web page.

WURFL (Wireless Universal Resource File) – WURFL is an open source directory and APIs for programmatic discovery of mobile device capabilities.

XHTML – XHTML is a HTML markup language in XML-compliant syntax.

XHTML Basic – W3C-standardized subset of HTML targeted for mobile devices, pagers and set-top boxes.

XHTML-MP – Superset of XHTML-Basic defined by the Open Mobile Alliance industry group. XHTML-MP is considered to be the implementation of WAP 2.0. XHTML-MP is a very popular markup language for mobile devices and carrier sponsored applications and portals.

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies,software developmentAgile project managementmanaging software teams, designing web-based business applications, running successful software development projectsecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurshipecommercetelecommunications andsoftware development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

What is Theory Y? How is it used as a management style? November 29, 2009

Posted by HubTechInsider in Agile Software Development, Definitions, Management, Project Management.
Tags: , , , , ,
1 comment so far

What is Theory Y? How is it used as a management style?

As I have said on these pages before, I needed to write a few short pieces on some of the different management styles I have encountered in my corporate and professional travels. I want to define each of these management styles so that I can compare and contrast them, as well as serving as reference points for the longer articles on this topic which I am in the process of drafting.

As I have previously stated, the purpose of this litany of alphabetic management styles is not to promote one over another; in fact, I don’t recommend adopting any of these naively. But nevertheless, many individual team members and managers will exhibit some behaviors from one of the above styles, and it is helpful to know what makes them tick. Finally, certain individuals may prefer to be managed as a Theory X or Theory Y type (Theory Z, which I will write about at a future date, is less likely in this case), and it is good to be able to recognize the signs. Moreover, some companies might be implicitly based on one style or another.

The second management style about which I will write is one which will be perhaps less recognizable to many people than the aforementioned “Theory X“: “Theory Y”.

As opposed to Theory X, Theory Y holds that work is a natural and desirable activity. Hence, external control abd threats are not needed to guide the organization. In fact, the level of commitment is based on the clarity and desirability of the goals set for the group. Theory Y posits that most individuals actually seek responsibility and do not shirk it, as proposed by Theory X.

A Theory Y manager simply needs to provide the resources, articulate the goals, and leave the team alone. This approach doesn’t always work, of course, because some individuals do need more supervision than others.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

What is Theory X? How is it used as a management style? November 27, 2009

Posted by HubTechInsider in Agile Software Development, Definitions, Management, Project Management, Staffing & Recruiting.
Tags: , , , , , , , ,
1 comment so far

I needed to write a few short pieces on some of the different management styles I have encountered in my corporate and professional travels. I want to define each of these management styles so that I can compare and contrast them, as well as serving as reference points for the longer articles on this topic which I am in the process of drafting.

I will begin with some of the “Letter Management Styles”, of which there are several. The purpose of this litany of alphabetic management styles is not to promote one over another; in fact, I don’t recommend adopting any of these naively. But nevertheless, many individual team members and managers will exhibit some behaviors from one of the above styles, and it is helpful to know what makes them tick. Finally, certain individuals may prefer to be managed as a Theory X or Theory Y type (Theory Z, which I will write about at a future date, is less likely in this case), and it is good to be able to recognize the signs. Moreover, some companies might be implicitly based on one style or another.

The first management style about which I will write is one which will be recognizable to every person, regardless of professional or personal background: “Theory X”.

Theory X is perhaps the oldest management style and is very closely related to the hierarchical, command-and-control model used by military organizations (of which I am intimately familiar).

One thing I can personnally attest to in regards to the Theory X management style is that it maintains the military organizations’ faith in the fact of the necessity of this approach, as (in the view of Theory X proponents) most people inherently dislike work and will avoid it if they can. Hence, in the Theory X management style, managers should coerce, control, direct, and threaten their workers in order to get the most out of them.

A statement that I recall from a conversation with a prototypical Theory X manager with whom I worked (in a prototypical Theory X organization) with was “people only do what you audit”.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

What is Six Sigma? How is it used, and what does it have to do with the CMM? November 27, 2009

Posted by HubTechInsider in Agile Software Development, Definitions, Management, Manufacturing, Products, Project Management, Technology.
Tags: , , , ,
add a comment

What is Six Sigma? How is it used, and what does it have to do with the CMM?

Developed by Bill Smith at Motorola in 1986, Six Sigma is a management philosophy based on removing process variation. It was heavily influenced by preceding quality improvement methodologies such as Quality Control, TQM, and Zero Defects. Six Sigma is a registered service mark and trademark of Motorola Inc. As of 2006, Motorola had reported over $17 Billion in savings from their own employment of Six Sigma practices throughout their global enterprise. Early corporate adopters of Six Sigma who achieved well-publicized success through the application of six sigma best practices to their enterprises included Honeywell (previously known as AlliedSignal) and General Electric, where Jack Welch famously introduced and advocated the method. By the late 1990s, about two-thirds of the Fortune 500 organizations had begun Six Sigma initiatives with the aim of reducing costs and improving quality.

My own professional experiences with Six Sigma began in the early 1990’s (I had first read about it in a Forbes magazine article in 1988) when I worked in manufacturing environments at Mercedes-Benz USA’s plant in Tuscaloosa (Vance), Alabama as well as Phipher Optical Wire Product’s plant in Tuscaloosa, the same city where the University of Alabama is located. It was in these environments where I was tasked with learning about six sigma and spent many hours in classrooms and factory floor and management workgroups implementing and training for a six sigma blackbelt. Six Sigma Black Belts operate under Master Black Belts to apply Six Sigma methodology to specific projects. They devote 100% of their time to Six Sigma. They primarily focus on Six Sigma project execution, whereas what are known in the Six Sigma universe as Six Sigma Champions and Master Black Belts focus on identifying projects/functions for Six Sigma.

Implementing a Six Sigma program in a manufacturing environment means more than delivering defect-free product after final test or inspection. It also entails concurrently maintaining in-process yields around 99.9999998 percent, defective rates below 0.002 parts per million, and the virtual eradication of rework and scrap. Other Six Sigma characteristics include moving operating processes under statistical control, controlling input process variables as well as the more traditional output product variables, and maximizing equipment uptime and optimizing cycle time. In a six sigma organization, employees are trained and expected to assess their job functions with respect to how they improve the organization. They define their goals and quantify where they are currently, their status quo. Then they work to minimize the gap and achieve “six sigma” (in a statistical sense) by a certain date.

Six Sigma focuses on the control of a process to ensure that outputs are within six standard deviations (six sigma) from the mean of the specified goals. Six Sigma is oftentimes implemented using a system with which I have worked many times: define, measure, improve, analyze, and control (DMIAC). Sometimes this same system is referred to as define, measure, analyze and control, or DMAIC.

Define means to describe the process to be improved, usually through some sort of business process model.

Measure means to identify and capture relevant metrics for each aspect of the process model. I have been in classrooms where this is referred to as “Goal -> Question -> Metric”.

Improve obviously implies changing some aspect of the process so that beneficial changes are seen in the associated metrics, usually by attacking the aspect that will have the highest payback.

Analyze and Control means to use ongoing monitoring of the metrics to continuously revisit the model, observe the metrics, and refine the process as needed.

Although some organizations apparently strive to use Six Sigma as a part of their software quality improvement practices, the issue that often arises is finding an appropriate business process model for the software development effort that does not devolve into a highly artificial simulacrum of the waterfall SDLC (Software Development Life Cycle) process.


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

What is Scrum? How is it used to manage projects and teams? November 25, 2009

Posted by HubTechInsider in Agile Software Development, Definitions, Management, Project Management, Software.
Tags: , , , , , , , , ,
1 comment so far

As I continue to move in the Boston software development / high tech job market and talk to more and more people in the area, I not only come across the term “Scrum” in many job descriptions, but it is a word that is frequently bandied about by both recruiters and hiring managers. It is clear that there is alot of confusion in the Boston area about what “Scrum” really is, and how it relates to Agile.

There is no substitute for the experience of running Scrum daily for years, as I have done. My heartfelt advice to anyone looking to adopt Scrum in their organization is to be flexible, take it easy on the cutsey names, and keep the daily meetings very brief. If you are the “ScrumMaster”, stay organized and lead the conversation around the room, notating all limiting factors, as that becomes your to-do list. Drop me a line with your own insights or comments on Scrum!

Scrum, as some people already know, is a project managemnt methodology named after a contentious point in a rugby match. The Scrum project management method enables self-organizing teams by encouraging verbal communication across all team members and project stakeholders. At its foundation, Scrum’s primary principle is that traditional problem definition solution approaches do not always work, and that a formalized discovery process is sometimes needed.

Scrum’s major project artifact is a dynamic list of prioritized work to be done. Completion of a largely fixed set of backlogged items occurs in a series of short (many of 30 days duration) iterations, or “sprints”.

Every day a brief meeting or “Scrum” is held in which project progress is explained, upcoming work is described, and impediments are raised. A brief planning session occurs at the start of each sprint to define the backlog items to be completed. A brief postmortem or heartbeat retrospective occurs at the end of each sprint.

A “ScrumMaster” (my advice is to never call yourself this in actual human life in an office of programmers and IT personnel…but know the job well and do it well nevertheless if you are the individual who finds themselves in this role) removes obstacles or impediments to each sprint. The ScrumMaster is not the leader of the team, as they are self-organizing, but rather acts as a productivity buffer between the team and any destabilizing influences.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

The Twenty Laws of Testing Computer Software September 24, 2009

Posted by HubTechInsider in Agile Software Development, Project Management, Technology, Uncategorized.
Tags: , , , , ,
5 comments

As a software development project manager, I conduct, plan, organize and cajole the software engineering efforts in companies large and small. During the course of this work, I have never ceased to be amazed at the lack of understanding of both the importance of properly testing a software product or products, and the lack of knowledge around how to correctly conduct the testing effort.

This holds true in corporations both large and small that I have worked for during my fifteen year professional career. In my opinion, a Project Manager should have a complete understanding of the software testing process, and should also have experience not just scheduling and planning the resources conducting the testing effort, but actual personal testing experience.

It occurred to me earlier on in my career as a Project Manager that in order for me to be a better Project Manager, I was going to have to learn and research everything I could get my hands on about testing computer software. I took courses, I bought books and read them; I related the information I gathered to my experiences as a developer and in some of the ecommerce companies I had worked for and built early on in my career.

I found that this desire to learn the ins and outs of testing was over half the battle towards becoming a more accomplished PM. The Project Manager who appreciates the importance of testing, has been a tester, knows and respects the testers on the team, and has a deep seated, fundamental respect for testing is a Project Manager who commands respect from his project team.

One of my favorite books is “Microsoft Secrets”, by Michael Cusomano. In the book, he describes how early on in the history of the company, testing became a career path on the same level as programming. Knowing, from my extensive reading about Microsoft and Bill Gates, the high altar upon which programmers are placed at Microsoft, I found this to be extremely significant.

Great software development teams and great software engineering companies take the testing of their software seriously. They don’t cut corners, and they don’t have to, because they began with the end in mind.

So without much further adieu, here are my twenty laws for testing computer software. Look for me to expound upon each of the twenty laws in more detail on these pages very soon:

  1. The sole goal of testing software is to find errors. Software testing is defined as the method of running a computer software program with the intent of discovering errors in the computer software program.
  2. The definition of a good test case is that a good test case is one that has been written in such a manner that it has a great chance of discovery of previously undiscovered errors.
  3. A successful test case is one that has been used to discover a previously undiscovered error.
  4. Only a high quality software testing process will result in a high quality software testing effort.
  5. Testing computer software is a professional discipline that must include skilled and trained professional computer software testers.
  6. Someone must assume full responsibility for the improvement of the software testing process.
  7. It is vital to foster a 100% positive, inclusive and team-oriented approach with a “test to break” mental attitude.
  8. A test case for testing a computer software program must include a definition of the expected result of the computer software program being tested.
  9. A computer software programmer should not test the computer software program they have coded themselves.
  10. By extension, a computer software programming organization or engineering department should not test its own programs; This is the work of an independent testing organization.
  11. The results of each test case should be reviewed with great care.
  12. Test cases should be written in order to include unforeseen and invalid user inputs, as well as foreseen, valid user input.
  13. Testing a computer software program to insure it performs as it should is only fifty percent of the testing effort. Another fifty percent of the testing effort should be expended in order to insure that the computer software program does not perform in ways in which it should not be performing.
  14. Avoid one-time, spontaneous, disposable test cases.
  15. A testing effort initiated under the assumption that no errors will be found will not be a successful computer software testing effort.
  16. The proliferation of errors in a computer software program can be prevented through the employment of testing during the early stages of the software development lifecycle.
  17. Software testing tools can be and should be a key element of a software testing effort.
  18. Although perhaps counterintuitive, the probability that more errors will be found in a section of a computer software program in which errors have already been found increases with the number of errors discovered in that section of the computer software program.
  19. Testing computer software well is an extremely mentally challenging exercise that requires creativity and perseverance from the testers in order to succeed.
  20. The perception (oftentimes forwarded by management) that “not enough time exists to test the product properly, so let’s just ship it anyway”, because the “rewards of shipping the software outweigh the risks of shipping the software with undiscovered errors” may still be common practice in many software development and engineering organizations, yet such an attitude will lead to catastrophe, as software quality is intrinsically linked to customer requirements and customer satisfaction.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

What is a “Use Case”? How is Use Case Modeling used to manage software development projects? June 28, 2009

Posted by HubTechInsider in Project Management.
Tags: , , , , , , , ,
2 comments

The History of Use Case Modeling

A gentleman by the name of Ivar Jacobson invented what later has become known as Use Cases while working on telephony systems at Ericsson in the late 1960s. In the later 1980s, he introduced them to the OOP, or Object Oriented Programming, community. Within that community, Use Cases were instantly recognized as filling an important gap in the requirements process.

Alistair Cockburn (pronounced “Coburn”) constructed the Actors and Goals conceptual model while writing Use Case guides for the IBM Consulting Group in 1994, after studying under Ivar Jacobson in the early 1990s. Cockburn’s Actors and Goals conceptual model help to resolve much of the mystery of Use Cases and provided a guide on how to write and structure Use Cases. I was exposed to Jacobson and Cockburn’s Use Case modeling concepts while working as a consultant and business analyst for IBM in the 1990s. Cockburn’s IBM Consulting Group Actors and Goals conceptual model has circulated informally since 1995 at http://alistair.cockburn.us/ and later at http://www.usecases.org. The ideas finally were published in the Journal of Object Oriented Programming in 1997, in an article I read and loved written by Alistair Cockburn entitled “Structuring Use Cases with Goals“.

From the early 1990s through the end of the dotcom Boom around 1999, the ideas remained static, even though many in the OOP community still felt that there were some underlying loose ends in the theories behind Use Case Modeling. Alistair Cockburn, the originator of so many of the Use Case Modeling conceptual underpinnings, continued to teach and coach his Actors and Goals model, eventually gaining insights into why many in the OOP community were having such a hard time coming to grips with the ideas being presented. He finally released his new insights, complete with some of his resolutions to the unresolved questions forwarded to him regarding the Actors and Goals model, as the Stakeholders and Interests Model.

UML and Use Case Modeling: differences and coexistence

I personally, when introducing these concepts to a new Project Team, have often been asked, “What impact or overlap is there between the Use Case Modeling ideas and UML, or the Unified Modeling Language”?

A former colleague of Jacobson’s, Gunnar Overgaard, wrote most of the UML use case material and worked to preserve the heritage of Jacobson’s ideas. But it is well known within the OOP community that the UML standards group has within it a strong drawing-tools influence, which results in the loss of much of the textual, prose-based nature of Use Case Modeling.

Alistair Cockburn has written that he has met with both Gunnar Overgaard and Ivar Jacobson, and both assured him that Use Cases may fit within one of the UML ellipses,and hence the UML standard is agnostic when it comes to the Use Case Modeling ideas. The ideas forwarded by Alistair Cockburn are fully compatible with the UML 1.3 use case standard.

I think it is very important, however, to realize that if you only were to read the UML standard, which does not discuss the content or writing of a Use Case, you will not understand what a Use Case is or how to write or use it, and you will be led in the dangerous direction of thinking hat Use Cases are a graphical, as opposed to a textual, or prose, construct.

What is a “Use Case”, and how is Use Case Modeling used?

A Use Case is a fundamentally prose text description of a system’s behavior under various conditions. These conditions are primarily responses of the system to requests from one of the stakeholders of the system in question, usually referred to as a “Primary Actor”.

A Use Case represents a type of contract between the stakeholders of a system about the behavior of that system under these various conditions, or “States”. The Primary Actor initiates an action with the system in order to accomplish a task or achieve a goal. Myriad scenarios can unfold subsequently, and those scenarios depend upon the type of interactions or requests made by the Primary Actor and the conditions or states which accompany those requests. The use case succinctly codifies these various scenarios together into a presentable format.

Although use cases can take the form of flow charts, “Petri nets”, sequence charts or even programming languages, they are usually (and through general practice and agreement, best) presented in a prose text format. They are a way to communicate the intended behavior of a system (many times of course a software system) amongst members of a project team. It should not be necessary for project team members to have special training in order to interpret a well written use case. Use cases serve to encourage communication between project team members and also to stimulate discussion around contention points of a system’s intended behavior.

Some project teams may choose to document the requirements of a software system only through the use cases themselves. Other project teams may choose to have separate, traditional requirements documents. Many project teams may choose to provide both forms of documentation, use cases and requirements documents. I am of the school that use cases, requirements documents, and test cases form a triad that can help to unequivocally clarify the intended behavior of even the most complex software systems and also give the testing team the very best chance to perform their job with precision and efficiency.

The same basic rules of writing apply to all of the above listed approaches, even though different project teams will choose to write with unique levels of technical detail and completeness of description.

A well written use case should be easy to read and consists of sentences that are succinct and written in only one grammatical format, that being a simple action step. An action step is defined as an event in which one actor achieves a result or passes information or results to another system actor. An actor is defined as anyone or anything with behavior.

Reading a use case should not take more than a few minutes, although learning how to write a good use case is considerably harder. Three fundamental concepts apply to the writing of use cases, all three of which need to be mastered in order to become an effective use case writer:

  1. Scope: What is the system being discussed, and what are the boundaries of the actions within that system to be described?
  2. Primary Actor: Who is the user who hopes to achieve a goal through interaction with the system in question?
  3. Level: Is the goal trying to be achieved by the Primary Actor primarily a high level goal or a low level goal?

The components of a use case consist of the following:

Stakeholder:  someone with an interest at stake in the proper behavior of the system under discussion.

Preconditions and Guarantees:  States or conditions that must be true both before and after the execution of the sequenced steps in the use case.

Main success scenario: A use case scenario in which no deviations from the expected behavior of the system are encountered.

Extensions:  Extensions describe alternate scenarios or states that can be encountered during the execution of a use case. Numbering convention used in the writing of a use case indicate to the reader points at which deviations from the main success scenario are possible. For example, steps 2a and 2b are indicative of twin conditions that can be arrived at by the primary actor during the execution of step 2.

How can Use Case Modeling assist Project Managers in managing complex software development projects?

Use cases provide a scaffolding construct that can be used by Project Managers or Program Managers to link many of the requirements details used on a modern software development project. Information contained within different parts of the software requirements definition (SRD) such as user profile information, data formating requirements, validations, and business rules can be cross linked and cross referenced through the utilization of Use Case Modeling.

In addition to this linking of requirements for a software development project, Use Cases and Use Case Modeling can help structure the project planning process by providing a framework upon which to hang information such as development status, release dates, teams, and priorities. The project team can employ Use Cases to track results, in particular the design of the User Interface components and system tests. It is for these benefits that many people seem to consider Use Cases as at the center or hub of a giant wheel of requirements consisting of spokes for performance requirements, UI requirements, UI design, business rules, data formats, input / output protocols, and performance requirements. Use Cases are often thought of in the OOP community as being the central element of the requirements or even the central element of the software development project’s development process.

At what points in a software development project do Use Cases add value?

Use Case modeling has garnered such a popular and ardent following within the OOP community precisely because Use Cases have the ability to tell coherent stories about how the System under discussion will behave in use. The end Users of the System get to see just what this new System will be and what functionality it will possess. They have the option to react early or fine tune or reject the User Stories implied in the Use Cases themselves (“You mean we’ll have to do what in order to cancel an Order?”). As important as this reason is to the widespread adoption of Use Case Modeling, this is only one of the ways in which Use Cases can contribute value to a software development project, and quite possibly not the most significant.

The very first moment during the course of a typical software development project that the Use Cases create value is upon the naming of these Use Cases as the User Goals that the System will support. These User Goals, in the form of the collected and named Use Case Catalog, form a list which announces what the System will do, revealing the scope of the System, its purpose. The list of named User Goals becomes a communication device between the different Stakeholders on the software development project.

The list of User Goals will be reviewed and debated upon by user representatives, software development engineers, executives, and project managers, who will use this list to estimate the cost and complexity of the System by using it as a guide to the functionality under construction. The list of User Goals will be used to negotiate which functions will be built first and how the teams are to be set up. The User Goal list is a framework upon which complexity, status, cost and timing metrics may be hung. It collects diverse and myriad project information over the course of the life of a software development project.

Why you should perservere through the writing of the Use Case failure conditions

The second instance where Use Case Modeling adds value during the course of a software development project is when the people or person writing the Use Cases brainstorm all the things that could go wrong in the MSS (Main Success Scenario). When the Use Case writers list out all the failure conditions, and how the System under discussion will handle these error or failure conditions, this is the point in the process where the Project Team is likely to uncover something surprising, maybe even something that nobody, including the Use Case writers themselves or the primary stakeholders, ever thought about as requirements.

The writing of the Use Case failure conditions is probably one of the most simultaneously frustrating and rewarding steps in the process of writing the Use Cases. I highly encourage everyone ever involved in writing of a catalog of Use Cases to hold out until this part of the process.  It is during the writing of the extensions, or failure conditions, that I regularly uncover a new User Goal, primary or secondary stakeholder, business rule or business process. Some of the most collaborative and productive design review sessions have resulted from discussions surrounding topics of how to handle these failure conditions. These design review sessions frequently end up involving a group of SMEs, or Subject Matter Experts, reviewing business processes or even questioning why it is things have been done a certain way inside a particular organization for so long. The process of trying to resolve what the System’s behavior should be during failure condition scenarios oftentimes is the process that generates the best requirements, even ex post facto to the formal discovery process.

If your Project Team skips over the writing of the Use Case failure conditions, then you will miss a valuable opportunity to catch many of the error conditions of the software application your Team is designing, leaving this vital Project task to a programmer who may discover them while typing a fragement of computer software code. This is far from the ideal juncture of your software development Project to be discovering new functions and business rules. If a lone programmer is left to his or her own devices in this type of scenario, with the business experts probably not around or gone home for the day, time pressure mounting, delivery schedules slipping, a programmer may be pressed, and understandably so, to just type whatever they think up at the moment instead of determining the correct functional behavior for the System they are programming, not necessarily designing.

I encourage Project Team to at least draw up one or two paragraph Use Case Briefs — for the very simple reason that Project Teams who write one-paragraph Use Cases save a lot of time by writing so little and already reap one of the major benefits of Use Cases. Project Teams who perservere through failure handling save mountains of time by finding subtle requirements early.


Subscribe to HubTechInsider on YouTube

PHP for Beginners

Google+ Domination Video Training Course

LinkedIn for Business Training Course


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

What is the “n body problem”, and what does it mean for software project management? June 23, 2009

Posted by HubTechInsider in Project Management.
Tags: , , , , ,
add a comment

It can be shown that for n project team members, there are [ n (n-1) / 2 ] possible working relationships. These working relationships grow with increased project team size as the aforementioned polynomial function shows. Of course, any of these working relationships are in danger of deteriorating, and the ones that are working out great are not necessarily transitive. For example, just because Tom and Wendy work great together, and Wendy and Susan work well together, it does not follow that Tom and Susan will work well together.

Further complicating these working relationships are externalities such as intercultural differences and outsourcing of project resources and pieces of the project work.

As bluesman Robert Cray would say: “Too many cooks are gonna spoil the stew” – or, as Fred Brooks of The Mythical Man Month has said in the central thesis of this classic software development text: “adding manpower to a late software project makes it later”.

The above factors are important to consider as a Project Manager. Poor team chemistry can ruin your chances to overcome the traditional project constraints of time, budget and resources even if your project team has at its disposal high quality technical talent.

The success of your project depends on both the quality of the talent on your project team and the manner in which that talent is engaged on your project.

It is currently fashionable for employers to surmise that a project’s success is only dependent upon the technical skill of the project team members. This is far from the truth, although a pleasant fiction for human resources and senior management.

As a Project Manager, you need to possess a wide range of people skills including team building, negotiation techniques and natural affability, you must be a master communicator, you must understand human behavior and team building and dynamics, you must be a great motivator and have innate knowledge of how to create and enhance esprit de corps.

Even the most highly technical situations are governed by human relationships and human nature. Your technical abilities and credibility as a technician carries weight with management and your project team members, certainly, but it is not your primary purpose as a Project Manager to serve as a technical resource, and all the technical skill in the world won’t save you if you can’t “Herd cats”.

The special challenges of software development will  rear their ugly heads in the midst of this, imposing their will upon the challenges of management of human teams. Only a skilled team, skillfully managed, can achieve success in most software development project situations.

“Good bow, hard to bend. Good horse, hard to ride. Good man, difficult to lead well”


Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

Eight ways to tell if your project team is on the way up or on the way down June 21, 2009

Posted by HubTechInsider in Project Management, Uncategorized.
Tags: , , ,
2 comments

In my professional roles leading software development teams, I have found that how Project Managers interact with their project team says not only alot about them as leaders, but also speaks volumes about the state of the organization itself. There is a dynamic lifeblood of personal relationships and interactions at the heart of a software development team that is an interesting take on leadership and team behavior. Your project team is either on the way up, or it is on the way down. In like fashion, your organization is either on the way up, or it is on the way down. Not every sign is easily recognizable at the time for what it really represents in terms of the direction your project team is heading.

 

A project team and an organization’s decline is like a disease: it is harder to detect but easier to cure in the early stages, and easier to detect but harder to cure in the later stages. Your project team and the encompassing organization may appear to be strong on the outside, but savvy insiders may be able to comprehend that your team is on the cusp of a dangerous and fatal fall off the cliff.

 

I have had the benefit (as I view it; Some would say curse) of having watched project teams in several different organizations and multiple industries. But it was easy to write about the below eight indicators because the signs tend to be the same regardless of the company and industry. In my role, you need to foster the good kind of environment where your project team can feel that the individuals are gelled into a cohesive unit that is winning. This feeling, rarely experienced, is like magic, and when a project team is hitting on all cylinders, each individual is capable of contributing their best to the endeavor at hand and feels like they are part of something special. Do your best as a Project Manager or team leader to foster this type of environment. Watch closely the eight key performance indicators I write about below and see how your current (or past) project teams have reflected which direction they are / were traveling in. You are either on the way up, or you are on the way down.

 

1. How is reality faced? – A team on the way down will shield the business owner or project sponsor from unpleasant facts – fearful and trepidacious, expecting criticism and penalties as a result of exposing rough realities. A team on the way up will constantly be exposing harsh realities: “Hey, man, look at this — this sucks hard…we got to fix this, and now”. Team members of a team on the way up will always bring forth these types of facts, as their project manager / team leader will never be critical of those who bring these ugly facts to life, feeling they need to be discussed and rectified.

 

2. How do project team members assert and support their opinions? – In a team on the way down, project team members will assert their opinions strongly, but will not provide data or evidence needed to form a strong and compelling argument. In a team on the way up, team members readily offer up solid data, evidence and bring logical argumentation skills to the discussion.

 

3. What style does the Project Manager use? – If the Project Manager or Project team leader uses a very low questions-to-statements ratio, and avoids critical input and allows sloppy reasoning and unsupported personal opinions to circulate in meetings, then your team is probably on the way down. However, if your PM or leader employs a Socratic style, using a high questions-to-statements ratio, challenges people and pushes for penetrating insights, then your team is probably on the way up.

 

4. How does the team coalesce behind decisions? – If team members grudgingly acquiesce to a decision but do not unify behind it or even work behind the scenes to undermine the decision ex post facto, then your team is on the way down. Teams on the way up will unify behind a decision once it is made, and work to make it successful, even if they did not initially agree with it.

 

5. How does the team give credit to each other? – Teams on the way down will seek as much credit for their own part of the job as possible for themselves, often not even noticing that this style seldom results in the confidence and admiration of their peers. In a team on the way up, project team members will credit others for success, and they find that this tendency will result in the admiration of and confidence from the other project team members.

 

6. Do team members need to look smart in front of each other? – In a team on the way up, project team members will argue to look smart or to further their own particular interests within the organization, but in a team on the way up, team members’ arguments and debates are all geared towards finding the very best answers to the problems and issues the project team is facing. Nobody worries about “Looking smart” in a team on the way up, because they have internalized that old saying: “Being smart’s alot like being ladylike: if you have to say you are, you probably aren’t”. Nobody in the team on the way up wants to look cool – they want to be cool.

 

7. Does the team conduct ‘post-mortems’, and how? – In a project team on the way down, culprits are sought for blame rather than in a team on the way up, where autoposies are conducted in order to mine wisdom and learning for the next time around or to make sure that the misstep results in a learning experience. Otherwise, a mistake is a mistake made twice. Project teams on the way up don’t have time to blame team members – they are too busy moving forward with the next items of business.

 

8. How about results? – Teams on the way down, unsurprisingly, often fail to deliver great or even good results. They spend alot of time blaming either individual team members or outside factors for setbacks and failures. A team on the way up, in contrast, is comprised of individual team members who are all delivering exceptional results, but in the case of mistakes, setbacks, and errors, each team member accepts full responsibility on their own and learns from the mistakes. The project team on the way up fosters this environment which enables each individual team member to feel comfortable doing so.





Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.





About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.


Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

What is “management by walking around”? June 13, 2009

Posted by HubTechInsider in Agile Software Development, Management, Project Management, Uncategorized.
Tags: , , , , ,
4 comments

Sometimes also called “Management by walking around” or MBWA, management by sight is a management strategy that can and should be integrated into any management style or approach. It is very people-oriented and it requires managers to be visible and interact heavily with project team members. Interactions at all levels of the project team foster the quick and efficient gathering of information about the project and the project team members.

Management by sight is very direct and the manager practicing it utilizes observation and visibility to conduct project analysis and project leadership, to monitor the situation, and to provide control when necessary.

I have had a great amount of success using this management technique and I thought I would share with you twelve guidelines for MBWA which were shared with me by @sjohnson717 on Twitter in response to this original MBWA post. These tips are great and I recommend following them when using this very simple and effective management technique.

Simple and effective management techniques are what every manager needs more of these days!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

 

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

management, mbwa, management by walking around, it management, it, information technology, project management

%d bloggers like this: