Taxonomy-based risk identification is a loosely structured method for quantifying risks during the planning phase(s) of software development.

Process

A project manager interviews developers using a questionnaire to identify risks in different project areas. These areas are referred to as “classes”.

Advantages for Adopting this Method

• Risks are identified earlier in the project
• Formal procedures exist for risk identification which helps reduce the ad-hoc nature of typical risk identification in software projects

Dangers of Adopting this Method

• Inexperienced or untrained developers will not be able to identify risks properly
• Uptraining may take time away from critical project activities
• Inexperienced teams usually lack defined risk management procedures

References

http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr06.93.pdf

This PDF contains the TBRI abstract and the following topics:

• Background and motivation for introducing a taxonomy-based approach
• Results of studies which were used to refine TBRI
• Sample approaches for introducing TBRI into your company and project routines
• Sample interview questionnaires

• Some of the relevant features and uses of Wikis for PPM
• Some overuses of Wikis
• Possible risks associated with using Wikis
• A list of articles that prompted me to try Wikis for PPM

Wiki Features

• Wikis are built for collaboration.
• Wikis implement unobtrusive document versioning methods.
• Category and page structure is flexible but can be standardized for specific needs.
• Wiki content is stored as plain text. This makes it easy to duplicate and format in a text editor if necessary.
• Plugins and extensions allow further customizations to suit your organization’s needs.
• Relatively easy to maintain. (Most of the Wikis I tried had simple install scripts)

Recommended Uses of Wikis

• Meeting and phone conversation notes
• Requirements gathering
• Planning project design
• Risk analysis notes
• Writing user stories
• Lightweight asset management (documentation, comps, UML diagrams)

Overuses of Wikis

It’s probably best to use a separate tool for the following project tasks:

• Bug tracking
• Time tracking
• Code versioning
• Code documentation

Choosing the Right Wiki

If you have not already selected a Wiki package, I recommend reviewing these links:

• http://www.wikimatrix.org/
• http://en.wikipedia.org/wiki/Comparison_of_wiki_software

After you have selected and installed the Wiki of your choosing, it is time to move on to structuring and securing content.

I chose MediaWiki because of its simple installation process and configuration through LocalSettings.php. A friend of mine brought up a good point – most people will be familiar with MediaWiki because Wikipedia uses it; everyone has visited Wikipedia.org.

Wiki Categories

Determine what topics you would like to store in the Wiki and how it will be organized before adding content. This planning will prevent dead links and reworking the Wiki’s structure. Refer to MediaWiki’s category help page for more information and recommendations.

Wiki ACLs

By default, wikis are not built to enforce strict access to pages, categories, and media. Custom extensions can provide Access Control List (ACL) behavior. I would adopt an ACL extension only after considering the sensitivity of your Wiki content. This list contains potential MediaWiki vulnerabilities for adopting 3rd party ACL extensions but may also apply to your wiki software. If you use a MediaWiki alternative, see if it has a built-in ACL or documentation regarding the risks of using ACL plugins.

I recommend installing a new Wiki for each client and protecting the directory with an .htaccess file in favor of using a 3rd party ACL.

Wikis and Version Control

Storing Wiki contents outside of development repositories creates a divergence between project plans and project code since Wikis have their own version control mechanism. This divergence does not introduce risk if the latest project plan is always relevant regardless of the code’s stability. I would recommend keeping Wiki content and code separate because duplicate version controls on a project asset is dangerous.

References

• Kelly, William. “Building a project Web site the easy way.” TechRepublic – A Resource for IT Professionals. 12 Mar 2003. Tech Republic. 6 Aug 2008 <link>.
• Macomber, Hal. “Proposal for a P-Log Specification.” Reforming Project Management. 2003. 6 Aug 2008 <link>.
• Adamy, Miro. “Project management using Wiki.” Miro’s World. 05 Mar 2007. 5 Aug 2008 <link>.
• Child, Tim. “Wiki as project management tool..” blog.timc3.com. 19 Nov 2006. 6 Aug 2008 <link>.
• Hohman, Jamie. “Wiki Customization to Resolve Management Issues in Distributed Software Projects.” Software Technology Support Center. Aug 2008. STSC. 6 Aug 2008 <link>.

Installation

1. Close any Macromedia or Adobe applications
2. Download and install the appropriate Extension Manager for your version of Flash and OS from:
   http://www.adobe.com/exchange/em_download/
3. Download and install the ASUnit Extension from:
   http://sourceforge.net/project/showfiles.php?group_id=108947&package_id=208529
4. Open Flash

Verifying the Installation

In Flash, go to the Commands menu and verify the “Create Class” command is available. If the “Create Class” command is not present verify the ASUnit extension is installed and enabled in the Extension Manager. You shouldn’t need to restart your machine.

Getting Started

1. Create a new AS2.0 FLA in an empty directory.
2. Save the FLA to an empty directory. ASUnit will need to create files relative to the FLAs path.
3. Insert the following code on Layer 1, Frame 1

   import AllTests;

   var at:AllTests = new AllTests();

4. Go to the Commands menu, Create Class menu item
   
5. Enter a qualified Class Name
6. Uncheck “Add to Library as MovieClip.”
7. Click OK
8. Go to the Commands menu and select the Build Test Suites command:
   

Potential Problems

• If you don’t enter a namespace when creating a new class ASUnit will output the following error:

  This is easy to fix; just enter “com.Example” in the Class Name text box (highlighted in blue above). All classes must use namespaces.

• If testing the movie does not present you with test case results, go to the Window Menu, Other Panels sub-menu, AsUnit Ui item to show the ASUnit panel.

Recommended Procedures

1. Setup your project so unit testing is performed outside the development area. I usually setup a directory called “unit_testing” and store my tests there. All development is done in the “development.” folder. The testing FLA Publish Settings must include the “development” folder in its search path list; this is usually entered as a relative URL.
   
2. The “Create Class” command creates two files, a className.as and a classNameTest.as. Delete the className.as

I Want To Create Tests For Existing Code

If you’ve decided to add unit testing to your arsenal mid-project try the following:

1. Add a directory in your project to hold the unit tests
2. Create a new AS2.0 FLA in the new directory
3. Go to the File menu, Publish Settings item, Settings… button
4. Add your project’s class path to the Classpath list and close
5. Add the code snippet above

Troubleshooting

If you run into class conflicts check to see if Flash’s global class paths are conflicting with the local Flash paths. To do this in CS3, go to the Edit menu, Preferences item, ActionScript category, ActionScript 2.0 Settings button. In reference to the example above, if your global class paths contain “./classes/” and your testing FLA class paths contain “../flash/classes/” Flash will happily notify you of a conflict.

Resources

• Official ASUnit Homepage: http://www.asserttrue.com/articles/tag/asunit
• Tutorial Part 1: http://www.flashcodersny.org/wordpress/?p=103
• Tutorial Part 1 (in PDF): http://timbeynart.com/docs/ASUnit_Part1.pdf
  
• Tutorial Part 2: http://timbeynart.com/docs/ASUnit_Part2.pdf

Stay Positive

As a general rule of thumb you should avoid negative discussion topics. I should mention this has little to do with sugar coating a slacking developer or ignoring potential problems. Conflicts should be identified and resolved but Friday Meetings are not a suitable environment for this process.

The Friday Wrapup Meeting is conducted at the end of the day on Friday, which gives developers about five minutes after the meeting before they head home for the weekend. If a developer receives schedule pressure for delivering a product, they must wait until Monday to resolve the problem. Negative feedback during Friday Meetings is counter-productive because there is no way for the developer to immediately resolve conflicts without losing time in their personal life. Developers should be encouraged to enjoy their weekend, not stress over work.

Recommended Discussion Items

• New tools, software packages, and development suites that were reviewed or added to the company’s tool arsenal
• Creative or innovative solutions to problems encountered during the week
• Company-related successes such as new projects, clients, or employees
• Improvements to development procedures
• How an employee’s work improved or benefited the company

Discussion Items to Avoid

• Updates on project estimates
• Reminding developers about upcoming deadlines
• Problems encountered during the week that still pose a threat to project health
• Company-related pitfalls
• Nagging developers to finish work; public humiliation is rarely effective

The Project Manager’s Role

The project manager’s role during Friday Wrapup Meetings is to analyze and transcribe individual developer motivations. Listening to the things that excite your developers reveals potential motivation techniques.

Examples of Interpreting Motivations

1. A non-JavaScript programmer creates a JavaScript widget: take screenshots of the widget in action and give the programmer a print-out of the widget to put on the wall.
2. A programmer develops a framework or complex system: have the developer create a class diagram of the framework and frame it above the programmer’s desk.
3. A designer creates an amazing website design: have the designer piece together a montage of the wireframes, sketches, conceptual pieces, and the final product. Have the designer post this on a wall for everyone to see.

Public Displays of Success

From my examples above you can see I’m leaning towards displaying things developers have worked on in the past. Displaying income earned over the past month or a screenshot of an entire website is a good start but it doesn’t highlight individual contributions. Remember that managers and developers have fundamentally different motivations. Managers are traditionally focused on success while developers are more focused on learning and personal growth.

Side-Effects

Side-effects may include but are not limited to:

• A company atmosphere that encourages personal growth and exploration
• Developers are reassured their managers are interested in what they have to say
• Developers are more motivated because they feel appreciated
• Increased team cohesion, which is provided by team members listening to others

References

McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Redmond, WA: Microsoft Press, 1996.

McConnell, Steve. Professional Software Development. Boston, MA: Addison Wesley, 2004.

10 Ways to Improve Website Credibility

The following list is available here. The external guidelines page also contains descriptions for each method and a link to research in PDF format.

1. Make it easy to verify the accuracy of the information on your site.
2. Show that there’s a real organization behind your site.
3. Highlight the expertise in your organization and in the content and services you provide.
4. Show that honest and trustworthy people stand behind your site.
5. Make it easy to contact you.
6. Design your site so it looks professional (or is appropriate for your purpose).
7. Make your site easy to use — and useful.
8. Update your site’s content often (at least show it’s been reviewed recently).
9. Use restraint with any promotional content (e.g., ads, offers).
10. Avoid errors of all types, no matter how small they seem.

This research is also available in PDF format here.

Usability and Credibility

Many of the methods for improving website Credibility overlap with Usability. I recommend reviewing Jakob Nielson’s article on usability testing at.

User Interfaces and Usability

Site usability can be improved through:

• Attention to detail when designing the user interface:
  http://www.uie.com/articles/subtle_interaction_design/
• Performing usability testing – “The 5-Second Test”:
  http://www.uie.com/articles/five_second_test/

References

• Fogg, B.J. “The Web Credibility Project: Guidelines – Stanford University.” Stanford Guidelines for Web Credibility. Jun 2002. Stanford University. 10 Jul 2008 <link>.
• Nielson, Jakob. “Usability Testing With 5 Users.” useit.com. 19 Mar 2000. 10 Jul 2008 <link>.
• Spool, Jared. “Interaction Design: It’s All About the Subtleties.” User Interface Engineering. 24 Jun 2008. 10 Jul 2008 <link>
• Perfetti, Christine. “5-Second Tests: Measuring Your Site’s Content Pages.” User Interface Engineering. 9 Jun 2005. 10 Jul 2008 <link>.

Irony

At the time of this writing http://www.webcredibility.org/ has no index page. Site visitors are presented with a directory structure. Tisk tisk.

Getting Started with UML

• If you are new to UML diagramming practice with paper or a whiteboard. Starting off with these mediums ensures you are learning one thing at a time. Tools like MS Visio are built to be user friendly but you will learn UML from the way Microsoft interprets UML. Even a fully UML compliant editor (such as Enterprise Architect) will increase your learning curve because every application interprets how you should draw UML differently. Learn UML first, then cool design software.
• Using design tools (like Visio or Enterprise Architect) to brainstorm wastes time; if the problem is not well understood or the solution changes – you must redraw the diagram. Use design tools to communicate “solutions to problems” or “problems”.
• Ask someone that is not a stakeholder in your project to interpret the diagram. Project stakeholders might make assumptions based on pre-existing project knowledge.
• Avoid spending extra time making diagrams UML compliant if they are tacit. I’ve spent hours arguing over a Use Case diagram arrangement – this time can be spent elsewhere. Compliance will improve over time, don’t try to make things perfect the first time.
• Use separate diagrams to describe different areas of a system. Mixing multiple diagram types into one diagram will confuse your audience.

Recommended Reading

• UML 2.0 In a Nutshell (O’Reilly) http://oreilly.com/catalog/9780596007959/
• Learning UML 2.0 (O’Reilly) http://oreilly.com/catalog/9780596009823

UML Style Guidelines

• Avoid curved lines
• Avoid overlapping lines. If lines must intersect use a “line jump” to indicate overlaps
• Elements should have consistent shapes and sizes. This includes decorations like rounded rectangle radius and line thickness
• Diagram elements should have consistent whitespace
• Maintain consistent fonts, colors, and font styles
• Use sans-serif fonts

Style Guideline References

http://www.ibm.com/developerworks/webservices/library/ws-tip-uml/

Refining UML Diagrams Over Time

• Create templates in your favorite design tool to reduce startup time
• Modify your diagrams based on feedback from clients and project managers. This may include items such as:
  • Color coded elements accompanied by a color key
  • Comments next to diagram elements
• Use layers to provide details for different audiences (this is a handy feature of Visio). Details may include:
  • Comments or notes not intended for the client
  • Developer details not relevant to designers
  • User interface notes that don’t pertain to developers

Recommended Software

Microsoft Visio

http://office.microsoft.com/en-us/visio/default.aspx

Enterprise Architect

http://www.sparxsystems.com.au/

UML Software List

http://en.wikipedia.org/wiki/List_of_UML_tools

• Where to find the NaturalDocs executables
• Where to find commenting guidelines
• Setup a sample project workspace
• Automate NaturalDocs with a simple Windows Batch File

Getting Started

1. Download and unpack the latest version of NaturalDocs available at:
   http://www.naturaldocs.org/.
2. Document your code according the NaturalDocs coding guidelines found at:
   
   http://www.naturaldocs.org/documenting.html.
3. Download this Windows Batch File if you wish to automate the process.
4. Create a folder in your project for documentation. Refer to the Project Folder Structure below.
5. Run NaturalDocs.bat directly or customize and run the automation batch file.

Setting Your Project’s Folder Structure

The following is an example project structure with separate development and documentation areas:

Customizing the Windows Batch File for Automation

Save the automation batch file in the /documentation/ directory. The batch file contains the following variables:

• NATURAL_DOCS_PATH: Location of the NaturalDocs executable
• INPUT_PATH: Relative path from the automation batch file to the source files
• OUTPUT_PATH: Relative path from the automation batch file to the desired output directory*
• PROJECT_PATH: Relative path from the automation batch file to the desired project directory*

*Set the output path and the project path to the same directory and leave the project data alone to save time on customizations. I usually have two batch files in the documentation directory. Each batch file generates documentation for a different portion of my code (procedural ActionScript and ActionScript classes).

Using NaturalDocs in a Subversion Workspace

NaturalDocs deletes documentation files if the class source file has been renamed or removed. Committing the documentation directories immediately after running NaturalDocs will eliminate errors in your working copy.

NaturalDocs Command Line Options

Refer to http://naturaldocs.org/running.html for more information. The automation batch file uses HTML output instead of HTML-frames output. Modify the last line of the automation batch file to change the output format.

NaturalDocs uses a ‘Project Root’ command-line parameter for storing project data. The project data contains custom menu arrangements, custom keywords, and custom topics. Project data is generated automatically but may be modified after NaturalDocs has generated documentation.

I found this tool while troubleshooting a Windows XP install. It proved useful for troubleshooting because it catches network requests and asks for approval. Beyond troubleshooting, the Comodo Firewall requires confirmation for application requests such as:

• Writing to the screen
• Modifying executables
• Connecting to network resources
• Launching programs

Your response is saved per application after you confirm or deny requests. This is very similar to the McAfee security center firewall but the Comodo Firewall is free, it contains no adware or spyware, and is easy to configure. Better still, Comodo has no nag screens.

Potential Problems

Browser detection is not bulletproof since users can change their browser name string, firewalls may prevent browser data from passing through, and software builders change their browser ID formats. Since these are the exceptions and not the rule-it’s worth attempting to customize the page presentation to your visitors’ browser.

Approach

1. Create individual stylesheets for different browsers and browser versions
2. Use PHP to detect the current browser and browser version
3. Load base stylesheets first
4. Load browser-specific styles after the base styles

The order of steps 3 and 4 are critical. We’re trying to overwrite the base styles so they must be included first in the HTML header.

Detecting the Browser Version

At the very least you’ll need to retrieve the browser name. If compatibility requirements are strict you’ll want the version and revision numbers too. Once you’ve chosen a detection script you’re ready to move on.

Instead of retyping source, I will now point you to this site which uses PHP’s get_browser() function. This page has a dedicated author and a history of updates dating back to 1998.

I recommend using get_browser() but if you don’t want to modify your PHP setup you are in luck. There are enough open-source detection scripts on the web to save you the trouble of writing your own. When you find a script be sure to check its release date.

An open-source script will have the same approach as the browser capability approach linked above.

Suggestions

• If you’re aiming for IE and Firefox it’s probably simpler to keep all your files in one ./css/ directory
• Use a folder structure like the one below if you have many browser-specific CSS files.
  

• If you’re switching approaches mid-project be sure to add relative paths to your CSS files!

References

http://www.hudzilla.org/phpbook/read.php/16_5_0