OWASP Code Crawler 2.5
During the last two months we have been hardworking on the new upcoming release of OWASP Code Crawler 2.5. In this release, we have been busy making Code Crawler even more stable and fast.
What follows it’s a list of all the new features of Code Crawler.
The source screen has been improved and now supports threat colouring. This means that all threats found in the source code will be highlighted depending on their threat level. (See the screenshot below)
As you can also see the threat analysis box has been moved into the Source Tab. Clicking on any highlighted threat will also show details of the corresponding threat.
The reports feature has also been improved, the code is less prone to throw exceptions and we are confident marking it as “releasable”.
The loading process of a single file is now 80% faster than any previous releases (1.0 to 2.4) this because we have moved the colouring tasks to another thread and have had changed the whole loading’s logic. Just to give you an idea of how much code crawler is fast, loading a source code file of one thousand lines in Code Crawler will take less than half a second (analysis included).
Sasikumar, new developer who has joined the team, is working on the new code crawler’s engine. He has made a powerpoint presentation, available on slideshare.com, which illustrates the details of the new architecture as well as the advantages gained using it. Sasikumar is also responsible for the new code colouring feature.
Code Crawler still supports the OWASP Code Review project providing the Key Pointers scan, but no major updates will be released in the future.
The Visual Studio Integration will also replace the Remote Server Scan in this release. The application is capable of scanning an entire Visual Solution starting from a single csproj file (Visual Studio C# Project file). Code Crawler commence the process analysing the provided project file and digging in for all the source code files which are part of the project. At this stage, the engine will process all the relevant source files and will end up providing all the details while using the new engine.
Code Crawler 2.5 was supposed to be released at the end of September but, because the amount of the new features, it has been postponed to end of October.
Gallio and MbUnit v3.1 out
From Jeff Brown’s blog “Bits in Motion”
Gallio v3.1 is a major upgrade to the platform. This release includes many new features, better performance, and improved robustness.
The Gallio Automation Platform is an open, extensible, and neutral system for .NET that provides a common object model, runtime services and tools (such as test runners) that may be leveraged by any number of test frameworks.
The Gallio platform seeks to facilitate the creation of a rich ecosystem of interoperable testing tools produced by and for the community at large so as to address a far wider range of testing needs than any previous independent testing framework has done before. Unit tests, integration tests, performance tests, and even semi-automated test harnesses should all be able to leverage common facilities where appropriate. Moreover, they should present consistent interfaces to the world so that they can easily be integrated into the systems and processes of the enterprise.
At present Gallio can run tests from MbUnit versions 2 and 3, MSTest, NBehave, NUnit, xUnit.Net, and csUnit. Gallio provides tool support and integration with CCNet, MSBuild, NAnt, NCover, Pex, Powershell, Resharper, TestDriven.Net, TypeMock, and Visual Studio Team System.
Highlights:
- Video capture and embedding in test reports.
- RSpec!
- Support for .Net Framework 4.0.
- Support for Visual Studio 2010 Beta 1.
- Control Panel application.
- Brand new plug-in model with improved startup performance.
- Major internal redesign.
- More MbUnit goodness.
Download here: http://www.gallio.org/Downloads.aspx
Documentation here: http://www.gallio.org/Docs.aspx
Simplicity: Self-Documenting Code, Adapter Pattern
Simplicity is the eye of the beholder. It doesn’t matter much if you think the design is simple; if the rest of your team or future maintainers of your software find it too complicated, then it is.
To avoid this problem, use idioms and patterns that are common for your language and team, It’s OK to introduce new ideas, too, but run them past other team members first. Be sure to use names that clearly reflect the intent of your variables, methods, classes, and other entities.
Pair programming will help you create simple code. If you have trouble understanding something your partner wrote, discuss the situation and try to find a better way to express the concept. Before you use a comment to explain something, ask your partner how to make the code express its intent without needing a comment.
Adapter Pattern, Isolating third party components
A hidden source of duplication lies in calls to third party components. When you have these calls spread throughout your code, replacing or augmenting that component becomes difficult. If you discover that the component isn’t sufficient for your needs, you could be in trouble.
To prevent this problem, isolate your third party component behind an interface that you control. Ask yourself “When I need to upgrade or change this component, how hard will it be?”. In object oriented languages, consider using the “Adapter Pattern” rather that instantiating third party classes directly. For frameworks that requires that you extend their classes, create your own base classes that extend the framework classes, rather than extending the classes directly.
Instead of supporting every feature of the component in your adapter, support only what you need today. Write the adapter’s interface to match your needs, not the interface of the component. This will make it easier to use and to replace when necessary.
Isolating third party components reduces duplication at the cost of making your code slightly more complex.
Cyphersec.ValidationFramework an object oriented validation library
ValidationFramework is a Microsoft .NET Class library built to help developers writing a more secure and consistent code without the drama of dealing with regular expressions.
Its architecture enables developers to extend its behaviour creating new validation logics. A validation logic is basically “how” the code will get validated against a predetermined set of rules. In this initial version only Regular expressions are supported.
Being object oriented it’s an important aspect making easy to understand and implement. In software security there’s a rule: “Never trust the client”. With this in mind an application developer could easily validate any external input with this library.
A UserInput object it’s a single logical unit that exposes three public properties, which are: Description, Value, DataType. Description could be any string that will help you associate any input with an user-friendly name. DataType it’s a classification that tell the library how how to evaluate the object.
Depending on the UserInput’s DataType different validation rules will be used. This version supports the following DataTypes:
- First Name
- Last Name
- UK Date Format
- US Telephone Number
- Address
- UK Post Code
- US Zip Code
- URL
- Network Address
- Percentage
- US Currency
- Roman Numerals
- TextEstensions (c:\file.txt || c:\folder\sub folder\file.txt || \\network\folder\file.txt)
- Days of Week
- Social Security Number
- Credit Card (Generic)
- Credit Card American Express
- Credit Card Diners Club
- Credit Card MasterCard
- Credit Card Visa
After specifying one or more UserInput that you would validate, a new collection has to be created. It’s called ValidationForm. A ValidationForm is a custom type collection that contains all the UserInput within the validation process. It’s a virtual representation the current Page data.
At this point the validation takes places. Calling the method (Validate +1 Overload), every single UserInput object within the ValidationForm will be validated using the specified Validation Logic.
If the validation succeed IsValid (boolean) property of the ValidationForm will be set to true.
If the validation fails, the developer could easily loop through the collection and collect every single Input that has failed the validation (line 13 to 15).
FBI and US Secret Service Advisory provides preventive measures against SQL Injection (MSSQL/IIS/.NET)
Recommendation 1: Disable potentially harmful SQL stored procedure calls.
The xp_cmdshell, OPENROWSET, and OPENDATASOURCE stored procedures should be disabled on all databases unless they are explicitly serving a business need within the network.
The xp_cmdshell procedure allows someone to execute commands on a local system from the database, with the permissions of the service account used for the database. The OPENROWSET and OPENDATASOURCE procedures allow one to cause the database to transfer data from the local database to a remote database and vice versa.
The following two steps should be taken to remove the potentially harmful stored procedure calls.
1. Disable access to the xp_cmdshell functions within Microsoft SQL Server.
Microsoft SQL Server 2000
EXEC sp_dropextendedproc 'xp_cmdshell'
Microsoft SQL Server 2005
EXEC sp_configure 'xp_cmdshell', 0
2. Remove the "xplog70.dll" file from the server.
If it is necessary to use the potentially harmful stored procedure calls, limit the exposure by applying IP filters on the SQL servers. Assign explicit ALLOW rules to the interfaces for the application the SQL server is supporting. Disallow communication between SQL Server hosts unless an application necessitates otherwise.
Recommendation 2: Deny extended URLs.
Excessively long URLs can be sent to Microsoft IIS servers, causing the server to fail to log the complete request. Unless specific applications require long URLs, set a limit of 2048 characters. Microsoft IIS will process requests over 4096 bytes long, but will not place the contents of the request in the log files. This has become an effective means to evade detection while performing attacks.
1. Modify "%windir%\system32\inetsrv\urlscan\urlscan.ini"
i. Ensure "MaxQueryString=2048" is present
ii. Ensure "LogLongUrls=1" is present
Recommendation 3: Implement specific approaches to secure dynamic web site content.
Certain measures can be taken to mitigate the risk of these types of attacks by developing a secure code base. The steps below are a few of the best practices for secure coding that will help prevent the attack associated with this incident. Additional information can be found at http://msdn2.microsoft.com/en-us/library/ms998271.aspx.
1. Replace escape sequences
private string SafeSqlLiteral(string inputSQL) { return inputSQL.Replace("'", "''"); }
2. Use parameters with stored procedures
using (SqlConnection connection = new SqlConnection(connectionString)) { DataSet userDataset = new DataSet(); SqlDataAdapter myDataAdapter = new SqlDataAdapter( "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", connection); myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text; myDataAdapter.Fill(userDataset); }
3. Constrain input in ASP.NET web pages
if (!Regex.IsMatch(userIDTxt.Text, @"^[a-zA-Z'./s]{1,40}$")) throw new FormatException("Invalid name format");
Recommendation 4: Install and run authorized Microsoft SQL Server and IIS services under a non-privileged account.
Unless a specific application requires system or administrative level permissions, all instances of Microsoft SQL Server and IIS should run under accounts with restricted user permissions.
Recommendation 5: Apply the principle of 'least privilege' on all SQL machine accounts.
The attackers generally create tables into which they store malware or data collected from the enterprise. Unless specific applications dictate otherwise, restrict the capabilities of the accounts used to modify databases on the servers. In particular, remove the ability to create new tables, denying the attackers a means of transporting malware and stolen data.
Recommendation 6: Require the use of a password on Microsoft SQL Server administrator, user, and machine accounts.
Several SQL servers examined had an empty password on the "sa" SQL account. All accounts with access to resources should be protected with passwords or certificates.
Recommendation 7: Lock out accounts on the mainframes after several unsuccessful logon attempts.
Locking accounts and requiring IT support to restore service aids in protection against brute force attacks. This can serve as an early detection of potential security problems.
Recommendation 8: Run the minimum required applications and services on servers necessary to perform their intended function.
Several servers, to include Active Directory master servers, have unnecessary software installed (e.g. Microsoft Office). In addition, ensure that no unnecessary services are running. This includes SQL Server and SQL Server Express on support and other workstations. Should these services be necessary, restrict access through IP filters on Microsoft Windows or through third-party firewall software.
Recommendation 9: Deny access to the Internet except through proxies for Store and Enterprise servers and workstations.
Attacks on victim networks make extensive use of HTTP, HTTPS, and DNS network ports. Denying direct access to the Internet will frustrate and mislead an attacker.
Recommendation 10: Implement firewall rules to block or restrict Internet and intranet access for database systems.
Disallow all traffic outbound from servers harboring sensitive data. Communication to the SQL servers and data warehousing servers should be tightly controlled. Restrict traffic between data centers and stores to essential ports and services only.
Recommendation 11: Implement firewall rules to block known malicious IP addresses.
Firewall rule sets designed to block all ingress (incoming) and egress (outgoing) traffic to the known malicious IP addresses have been put in place. Note that traffic violating the rules should be logged and observed in near-real time.
Recommendation 12: Ensure your HSM systems are not responsive to any commands which generate encrypted pin blocks. More specifically, HSMs should not accept commands that allow plain text PINs as an argument and respond with encrypted PIN blocks.
A PDF version of this document can be downloaded from http://usa.visa.com.
Guess what? This advisory was ignored by Heartland, Hannaford’s and 7-11 as they were targeted using SQL Injection attack vectors that lead to a massive theft of over 130 million credit and debit card accounts.
The whole purpose of a Garbage Collection
Once a class is defined, you can allocate any number of objects using the C# new keyword. Understand, however, that the new keyword returns a reference to the object on the heap, not the actual object itself. This reference variable is stored on the stack for further use in your application. When you wish to invoke members on the object, apply the C# dot operator to the stored reference.
When you are building your C# application, you are correct to assume that the managed heap will take care of itself without direct intervention. In fact, the golden rule of .NET memory management is simple:
Allocate an object onto the managed heap using the new keyword and forget about it
Once instantiated, the garbage collector will destroy the object when it is no longer needed. The next obvious question, of course, is “How does the garbage collector determine when an object is no longer needed?”
The answer is that the garbage collector removes an object from the heap when it is “unreachable” by any part of your code base.
Assume you have a method in your Program class that allocate a local IceCream object:
Notice that the IceCream reference (iceCream) has been created directly within the “MakeAnIceCream” method and has not been passed outside of the defining scope. Thus, once this method call completes, the iceCream reference is no longer reachable, and the associated IceCream object is now a candidate for garbage collection. Understand, however, that you cannot guarantee that this object will be reclaimed from the memory immediately after MakeAnIcreCream() has completed. All you can assume at this point is that when the CLR performs the next garbage collection, the iceCream object could be safely destroyed.
The base class libraries provide a class type named System.GC that allows you to programmatically interact with the garbage collector using a set of static members. Typically speaking, the only time you will make use of this type directly is when you are creating types that makes use of unmanaged resources.
The whole purpose of the .NET Garbage collector is to manage memory on your behalf. However, under some very rare circumstances, it may be beneficial to programmatically force a garbage collection using GC.Collect(), specifically:
-
Your application is about to enter into a block of code that you do not wish to be interrupted by a possible garbage collection.
-
Your application has just finished allocating an extremely large numbers of objects and you wish to remove as much of the acquired memory as possible.
If this is the case it may be beneficial to have the garbage collector check for unreachable objects, you could explicitly trigger a garbage collection as follows:
When you manually force a garbage collection, you should always make a call to GC.WaitForPendingFinalizers(). With this approach, you can rest assured that all finalizable objects have had a chance to perform any necessary cleanup before your program continues forward. Under the hood, GC.WaitForPendingFinalizers() will suspend the calling thread during the collection process. This is a good thing as it ensures your code does not invoke methods on an object currently being destroyed.
The GC.Collect() method can also be supplied a numerical value that identifies the oldest generation on which a garbage collection will be performed. For example, you wished to instruct the CLR to only investigate generation 0 objects, you should write the following:
As well, as of .NET 3.5, the Collect() method can also be passed in a value of the GCCollectionMode enumeration as a second parameter, to fine-up exactly how the runtime should force the garbage collection. This enum defines the following values:
Now, back to the topic of how the garbage collector determines when an object is “no longer needed”. To understand the details, you need to be aware of the notion of application roots. Simply put, a root is a storage location containing a reference to an object on the heap. Stricly speaking, a root can fall into any of the following categories:
- References to global objects
- Reference to any static objects / static fields
- Reference to local objects within an application’s code base
- Reference to object parameters passed into a method
- References to objects waiting to be finalized
- Any CPU register that references an object
During a garbage collection process, the runtime will investigate objects on the managed heap to determine whether they are still reachable (aka rooted) by the application. To do so, the CLR will build an object graph, which represent each reachable object on the heap. Object graphs are used to document all reachable objects. As well, the garbage collector will never graph the same object twice.
Assume the managed heap contains a set of objects named A,B,C,D,E,F and G. During a garbage collection, these objects are examined for active roots. Once the graph has been constructed, unreachable objects are marked as garbage.
Once an object has been marked for the termination (C and F in this case) they are swept from memory. At this point, the remaining space on the heap is compacted, which in turn will cause the CLR to modify the set of active applications roots (and the underlying pointers) to refer to the correct memory location (this is done automatically and transparently). Last but not least, the next object pointer is readjusted to point to the next available slot.
Iteration Planning
Iterations are the heartbeat of an XP project. When an iteration starts, stories flow in to the team as they select the most valuable stories from the release plan. Over the course of the iteration, the team breathes those stories to life. By the end of the iteration, they’ve pumped out working, tested software for each story and are ready to begin the cycle again.
Iterations are exactly one week long and have a strictly defined completion time. This is a timebox: work ends at a particular time regardless of how much you’ve finished. Although the iteration timebox doesn’t prevent problems, it reveals them, which gives you the opportunity to correct the situation.
An iteration follow an unchanging schedule.
- Demonstrate previous iteration
- Hold retrospective on previous iteration
- Plan iteration
- Commit to delivering stories
- Develop stories
- Prepare release
Team usually start their iteration on Monday morning and end Friday evening. Some others start their iteration on Wednesday morning. They do this because it allows people to leave early on Friday or take Monday off without missing important events and also because it allows the team to conduct releases before the weekend, which is an important aspect of iteration planning.
Planning an iteration
After the iteration demo and retrospective are complete, iteration planning begins. Start by measuring the velocity of the previous iteration. Take all the stories that are “done done” and add up their original estimates. This number is the amount of story points we can reasonably expect to complete in the upcoming iteration.
With our velocity in hand, we can select the stories to work on the current iteration. Ask your customer to select the most important stories from the release plan. Select stories that exactly add up to the team’s velocity. You may need to split stories or include one or two less important stories to make the estimate add up perfectly.
Because the iteration planning meeting take stories from the front of the release plan, you should have already estimated and prioritized those stories. As a result, selecting stories for the iteration plan should only take a few minutes, with perhaps 10 or 15 minutes more to explain.
At this point, the real work of iteration planning begins. Start by breaking down the stories into engineering tasks.
Engineering tasks are task for programmers to complete. Unlike stories, engineering tasks don’t need to be customer-centric. Instead, they're programmer-centric. Typical engineering tasks include:
- Update build script
- Implement domain logic
- Add database table and associate ORM objects
- Create new UI form
Brainstorm the tasks you need in order to finish all the iteration’s stories. Some tasks will be specific to a single stories others not. Brainstorming tasks is a design activity. If everybody has the same ideas about how to develop the software, it should go fairly quickly. If not, it’s a great opportunity for discussion before coding begins. However you should not go into much details.
After you’ve finished brainstorming tasks, spread the out on the table and look at the whole picture. Are these tasks enough to finish all the stories? Are there any duplicates or overlaps? Discuss and fix any problem.
Afterwards go on with the next step required: Estimate the tasks.
As with brainstorming, this can occur in parallel, with individual programmers picking up cards, writing estimates, and putting them back. Call out the estimates as you finish them. If you hear somebody call out an estimate you disagree with, stop to discuss it and come to consensus.
It’s important to estimate the tasks in ideal hours. How long would the task take if you had perfect focus on the task, suffered no interruptions, and could have the help of anybody on the team? Estimate them in person-hours as well: a task that takes a pair two hours is a four-hours estimate. If any of the tasks are bigger than six hours of effort, split them into smaller tasks and consequently combine small tasks that are less than an hour or two.
As final step, add up the estimates and compare them to the total task estimates from your previous iteration. Using this plan, you can commit to delivering all the stories? Is there any slack in the plan for dealing with unexpected problems?
Doing so, you may discover that you aren’t comfortable committing to the plan you have. If so, see if there are any tasks you can remove or simplify. Talk with your on-site customer. Can you replace a difficult part of a story with something easier but equally valuable? If not split or remove the story. Similarly, if you feel that you can commit to doing more, add a story to the plan.
Experience leads making plans that don’t need adjustment.
Risk Management
Good XP teams do achieve a stable velocity. Unfortunately, velocity only reflects the issues the team normally faces. Life always has some additional curve balls to throw. Team members get sick and take vacations; hard drive crash, and although the backups worked, the restore doesn’t; stakeholders suddenly realize that the software you’ve been showing them for the last two months needs some major tweaks before it’s ready to use.
Despite the uncertainties, your stakeholders need schedule commitments that they can rely upon. Risk management allows you to make and meet these commitments.
Risk Management Plan
Every project faces a set of common risks: turnover, new requirements, work disruption, and so forth. These risks act as a multiplier on your estimates, doubling or tripling the amount of time it takes to finish your work.
How much of a multiplier do these risks entail? It depends on your organization. Because most organizations don’t have this kind of information available we’ll use some based on the DeMarco & Lister’s RISKYOLOGY simulator.
| Percent chance | Rigorous | Risky | Description |
| 10% | x1 | x1 | Almost impossible ("ignore") |
| 50% | x1.4 | x2 | 50-50 chance ("stretch goal") |
| 90% | x1.8 | x4 | Virtually certain ("commit") |
These multipliers show your chances of meeting various schedules. For your example, in a “Risky"” approach, you have a 10 percent change of finishing according to your estimate schedule. Doubling your estimates gives you a 50 percent to chance of on-time completion, and to be virtually certain of meeting your schedule, you have to quadruple your estimates.
If you use the XP practices – in particular, if you’re strict about being “done done (agile principle number 7)” every iteration, your velocity is stable, and you fix all your bugs each iteration – then your risk is lowered. Use the risk multiplier in the “Rigorous” column. On the other hand, if you’re not strict about being “done done” every iteration, if your velocity is unstable, or if you postpone bugs and other work for future iterations, the use the risk multiplier in the “Risky column”.
Although these numbers come from studies of hundreds of industry projects, those projects didn’t use XP. As a result, it’s guessed somewhat at how accurately they apply to XP. However, unless your company has a database of prior projects to turn on, they are your best starting point.
Project-Specific Risks
Using the XP practices and applying risk multipliers will help contain the risks that are common to all projects. The generic risk multipliers include the normal risks of a flawed release plan, ordinary requirements growth, and employee turnover. In addition to these risks, you probably face that are specific to your project. To manage these, create a risk census – that is, a list of the risks your project faces that focuses on your project’s unique risks.
[DeMarco & Lister 2003] suggest starting work on your census by brainstorming catastrophes. Gather the whole team and hand out index cards. Remind team members that during this exercise, negative thinking is not only OK, it’s necessary. Ask them to consider ways in which the project could fail. Write several questions on the board:
- What about the projects keep you up at night?
- Imagine it’s year after the project’s disastrous failure and you’re being interviewed about what went wrong. What happened?
- Imagine your best dreams for the project, then write down the opposite.
- How could the project fail without anyone being at fault?
- How could the project fail if it were the stakeholders’ fault? The customers’ faults? Testers? Programmers? Management? Your fault? Etc.
Write answers on the cards, then read the aloud to inspire further thoughts.
Once you have your list of catastrophes, brainstorm scenarios that could lead to those catastrophes. From those scenarios, imagine possible root causes. These root causes are your risks: the causes of scenarios that will lead to catastrophic results.
For example, if you’re creating an online application, one catastrophe might be “extended downtime". A scenario leading to that catastrophe would be “excessively high demand”, and root causes include “denial of service attack” and “more popular than expected”.
After you’ve finished brainstorming risks, let the rest of the team return to their iteration while you consider the risks within a smaller group. For each risk determinate:
- Estimated probability (High, Medium, Low)
- Specific impact to project if it occurs – pounds lost, days delayed, and project cancellation are more common possibilities.
- You may be able to discard some risks as unimportant immediately. Ignore unlikely risks with low impact and all risks with negligible impact. Your generic risk multipliers accounts for those already.
- For the remainder, decide whether you will avoid the risk by not taking the risky action; contain it by reserving extra time or money, as with the risk multiplier; or mitigate it by taking steps to reduce its impact. You can combine these actions.
- For the risks you decide to handle, determinate transition indicators, mitigation and contingency activities, and your risk exposure:
-
Transition indicators tell you when the risk will come true. It’s human nature to downplay upcoming risks, so chose indicators that are objective rather than subjective. For example, if your risk is “unexpected popularity causes extended downtime”, then your transition indicator might be “server utilization trend shows upcoming utilization over 80 percent”.
-
Mitigation activities reduce the impact of the risk. Mitigation happens in advance, regardless of whether the risk comes to pass. Create stories for them and add them to your release plan. To continue the example, possible stories include “support horizontal scalability” and “prepare load balancer”.
-
Contingency activities also reduce the impact of the risk, but they are only necessary if the risk occurs. They often depend on mitigation activities that you perform in advance.
-
Risk exposure reflects how much time or money you should set aside to contain the risk. To calculate this, first estimate the numerical probability of the risk and then multiply that by the impact. When considering your impact, remember that you will have already paid for mitigation activities, but contingency activities are part of the impact.
Some risks have a 100 percent chance of occurring. These are no longer risk – they are reality. Update your release plan to deal with them.
For the remaining risks, update your release plan to address them. You will need stories for mitigation activities, and you may need stories to help you monitor transition indicators. For example, if you risk is “unexpected popularity overloads server capacity”, you might schedule the story “prepare additional servers in case of high demand” to mitigate the risk, and “server load trend report” to help you monitor the risk.
You also need to set aside time, and possibly money, for contingency activities. Don’t schedule any contingency stories yet – you don’t know if you’ll need them. Instead, add up your risk exposure and apply dollar exposure to the budget and day exposure to the schedule. Some risk will occur and others won’t, but on average, the impact will be equal to your risk exposure.
ASP.NET Have emails sent to a folder instead of an SMTP server
<mailSettings>
<specifiedPickupDirectory pickupDirectoryLocation="c:\Temp\" />
</smtp>
</mailSettings>
</system.net>
Product Vision
Projects start out as ideas focused on results.
eg: Sell more hardware by bundling better software. Attract bigger customers by scaling more effectively. Open up a new market by offering a new service. The idea is so compelling that it gets funding, and the project begins.
Somewhere in the transition from idea to project, the compelling part – the vision of a better future – often gets lost. Details crowd it out. You have to hire programmers, domain experts, and interaction designers. You must create stories, schedule iterations, and report on progress. Hustle, people, hustle!
That’s a shame, because nothing matters more than delivering the vision. The goal of the entire project is to deliver the vision. If the details are perfect, but the vision is forgotten the the software will probably fail. Conversely, if you ship something that helps accomplish the vision, does it really matter how you did it?
Where the vision come from?
Sometimes the vision for a project strike as a single, compelling idea. One person gets a bright idea, evangelizes it, and gets approval to pursue it. This person is a visionary.
More often, the vision isn’t so clear. There are multiple visionaries, each with their own unique idea of what the project should deliver.
Either way, the project needs a single vision. Someone must unify, communicate, and promote the vision to the team and to stakeholders. That some is the product manager.
How to identity the vision
Like the children’s game of telephone, every step between the visionaries and the product manager reduces the product manager’s ability to accurately maintain and effectively promote the vision.
If you only have one visionary, the best approach is to have that visionary act as product manager. This reduces the possibility of any telephone-game confusion. As long as the vision is both worthwhile and achievable, the visionary’s day-to-day involvement as product manager greatly improves the project’s chances of delivering an impressive product.
If the visionary isn’t available to participate fully, as is often the case, someone else must be the product manager. Ask the visionary to recommend a trusted lieutenant: someone who has regular interaction with the visionary and understands how he thinks.
Documenting the Vision
After you’ve worked with visionaries to create a cohesive vision, document it in a vision statement. It’s best to do this collaboratively, as doing so will reveal areas of disagreement and confusion. Without a vision statement, it’s all too easy to gloss over disagreements and end up with an unsatisfactory product.
Once created, the vision statement will help you maintain and promote the vision. It will act as a vehicle for discussion about the vision and a touchpoint to remind stakeholders why the project is valuable.
Don’t forget that the vision statement should be a living document: the product manager should review it on a regular basis and make improvements. However, as a fundamental statement of the project’s purpose, it may not change much.
How to create a Vision Statement
The vision statement documents three things: what the project should accomplish, why it is valuable, and the project’s success criteria.
The vision statement can be short. Usually try to limit it to a single page. Remember, the vision statement is a clear and simple way of describing why the project deserves to exists. It’s not a roadmap; that’s the purpose of release planning.
In the first section – what the project should accomplish – describe the problem or opportunity that the project will address, expressed as an end result. Be specific, but not prescriptive. Leave room for the team to work out on details.
In the second section - describe why the project is valuable:
e.g. ”This product is so valuable to us because it gives us an opportunity to create an entrepreneurial product. Its success will allow us to form our own product company and make a good living doing work that we love.”
In the final section, describe the project’s “success criteria”: how you will know that the project has succeeded and when you will decide. Choose concrete, clear, and unambiguous targets.
Why vision is useful?
When your project has a clear and compelling vision, prioritizing stories is easy. You can easily see which stories to keep and which to leave out. Programmers contribute to planning discussions by suggesting ways to maximize value while minimizing development costs. Your release plan incorporates small releases that deliver value.
When the visionary promotes the vision well, everyone understands why the project is important to the company. Team members experience higher morale, stakeholders trust the team more, and the organization supports the project.
