Contract Phase:
-
You do not own the code unless you pay for it.
ie. Intellectual Property Rights, (IPR) reside with the developer unless the contract explicitly states otherwise.
-
Even when you request the IPR for the code base, you still will not own pre-existing libraries that the developer has created and used previously unless the contract explicitly states otherwise.
-
In general, purchasing the IPR to pre-existing code involves additional cost and negotiation.
-
Even when you own the IPR, you must ensure that you have in fact received ALL of the code required to re-create the application.
This often requires a separate third party verification process.
-
Even when you have all the code, you still will need the development environment(s) used to create the application.
This may require the purchase of licenses for 3rd party development software and a separate third party verification process.
-
Generally speaking IPR is not worth the trouble.
A better solution is a developer's license which also allows rebranding and selling, often with a shared royalty scheme if the original developer is invited to be involved.
[Note: vuWare does all software development in Virtual Machines so that transfer and verification of the codebase and development environment is a relatively swift and simple process.]
-
Accurate estimation of development durations requires a great deal of discipline by the developer to realistically calculate time frames.
Developers often, (almost always), succumb to the temptation to shave time estimates in order to win a contract, (sometimes intending to recoup their losses on "variations" fees. See point 2 of the "Specification Phase".)
-
Open-Source software licensing MAY REQUIRE YOU TO SHARE YOUR BUSINESS IPR with the general public.
Specification Phase:
-
A programmer can't produce your perfect application unless you specify it exactly.
This will require a considerable amount of effort and communication on the customer's part at all stages of the development process.
It is often a good idea to assign a single person as a dedicated liaison with the developer.
-
Software specification is a multi-stage iterative and ongoing process required at all stages of the development process.
Software developers often rely on the fact that customers are not aware of this to extract "variation" fees from the customer for features never specified at the outset.
It is in fact impossible to fully specify a software application from the outset since in a very real sense the software IS the specification.
The industry average is that 40% of the total development cost is re-work due to incomplete requirement specifications.
The cost of re-work during the development and testing phase is between 3 to 10 times as much as re-work and documentation during the specification phase, ie. "Start later, Finish earlier".
-
Developers should be included in the specification phase as early as possible.
Because of their expertise and experience, they will be able to contribute technical insights and suggestions that will probably not occur to the customer.
-
Specifications must include as a minimum all outputs (deliverables) from the software in detailed unambiguous detail.
-
Customers should also consider non-functional requirements such as number of simultaneous users and response time and useability.
Useability is somewhat intangible but can be measured via a choice of human input methods.
-
Open-Source software and tools can often reduce the up-front licensing costs and sometimes have a compelling solution.
Open-Source software will still require ongoing commercial support and maintenance.
You are still obligated to follow the Open-Source software licensing WHICH MAY REQUIRE SHARING YOUR BUSINESS IPR with the general public.
Also modifying an existing external code-base is technically challenging, (and therefore expensive) both in developer time and effort.
The product should match the business. Don't try and match the business to the product.
A poorly matched free application can be more costly than a bespoke solution.
You can only know how well the match is if you have accurate specifications.
-
You should try and separate the business requirements as much as possible from the technical specifications, but consult the developer/architect where neccessary.
ie. The business requirement should be detailed but not technical.
-
You should have traceability of every technical decision back to a business requirement so that you maintain the project's focus.
"If you don’t know where you are going, you will wind up somewhere else." – Yogi Berra
-
The overall specification phase should consist of a natural progression starting with almost exclusively business input and ending with almost exclusively technical input... but with plenty of collaboration in between.
-
The technical constraints that matter are generally self-imposed... ie. existing IT infrastructure requirements.
Usually its a cost issue... ie. You can always achieve a technical solution but at what cost?
-
Business requirements should be written in a lay-person's language.
eg. "Handle Christmas peak of 1280 users", "Screen should respond in 8 seconds", etc.
-
Clearly document all business data including workflow, current problems, anticipated risks, and required performance metrics.
-
Detailed UML "Unified Modeling language" diagrams are perfect for specifying both business and software architectures.
-
Screen shots should only be shown in a mock up prototype.
-
The business requirements group should check the technical specification and design for traceability to the original business requirment.
Effectively the technical specification is delegated in good faith that the team can meet the business requirements.
-
Most businesses don't pick up misunderstanding until the commissioning phase, which is why Agile development is becoming so popular.
-
If you use the Agile development model instead of the Waterfall model then having business requirements weighted by business priority is essential to prioritise the Agile back log.
"The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and Maintenance.
In the unmodified "waterfall model" progress flows from the top to the bottom, like a waterfall.
The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible.
Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995),[1] although Royce did not use the term "waterfall" in this article.
Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).
This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice."
Design Phase:
-
The design should take into the account the cost of not having the solution align with the business.
Studies suggest that 60% of all software features are not used.
-
The design should attempt to maximise the leverage of existing assets e.g code, infrastructure, licenses.
It should not however be constrained by these, since this can result in a requirements-product mismatch.
-
A prototype in a visual storyboard format should show to the business visually the look and flow of the final product.
-
Software prototypes can be an unwelcome distraction for the developer.
It can take a lot of effort to produce a prototype... and its difficult get the client to pay for it.
With a little bit more time it is possible to have a working demo instead based upon code to be used in the final release.
-
The design should separate business rules as a layer.
-
The design should include functional as well as non-functional requirements such as performance and scalablity considerations.
The design should be paused if these requirements are incomplete or ambiguous and a defect raised against the requirments.
Development Phase:
-
The customer should endeavor to deliver all agreed data and resources to the developer when specified.
Failure to produce deliverables to the developer in a timely fashion can often cause dramatic dislocations in the project's overall progress.
-
Customers should remain involved in the project as much as possible during development to re-assure themselves that adequate progress is being made, (see point 2 of "Developer - Customer Relationship") and to ensure that the specification "tracks" the application functionality as closely as possible.
Customers should not stress developers with a constant harangue for reassurance and information which they could obtain themselves through shared project monitoring, (see point 2 of "Developer - Customer Relationship").
-
Many software developers are moving towards the "Agile" development model.
"Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organising cross-functional teams."
Testing Phase:
-
Tests should be conducted against the business and technical specifications not against the appplication under test.
-
Testing should be prioritised based on business priority and code volatility.
It is not possible to test all combinations on all releases, especially when data is involved.
-
Defects should be graded and a certain level of cosmetic defects allowed into the initial production release.
This way the developer can get paid and the defects fixed as part of a maintenance agreement.
-
Performance testing involving many users has to be automated as it is impossible to simulate manually.
-
Privatizing production data to be used in development, testing and traing has to comply with data privacy laws and be adequately budgeted for.
-
Test data should be as realistic as possible. It will be more testible if it is not simply random characters.
"In some cases 50% of the test effort is preparing test data to cover all business rules."
Commissioning Phase:
-
Feature Requests are not Bugs and vice versa.
Customers will often request additional functionality during commissioning and complain that they are bugs because they wanted this functionality and it is missing.
This is in fact most often a specification failure not a development one.
The customer has not properly included it in the formal specification either before or during the development phase.
New features are NOT added during commissioning.
Commissioning is for ensuring that the current feature set and functionality is working properly prior to final deployment.
-
Customers often, (always) attempt to spin out the commissioning phase for as long as possible since they see this as a last opportunity to get everything they can without additional payment.
This will cause a great deal of friction between the two parties and can result in the project's failure if the relationship breaks down at this point.
-
Software has versions for a reason.
It is impossible to deliver the perfect application in version 1.0.
Any attempts to do so only lead to unneccessary expense and delays.
It is considerably easier (and cheaper) to add new features and functionality to a working application than to try and get everything working at once in the first release of a newly developed application.
It is therefore important to keep the initial specifications as modest as possible.
Post-Project Work:
-
Software developers usually hope to be invited to maintain an ongoing relationship with the customer, providing support and requested upgrades where neccessary.
This is generally an appropriate approach and can be quite benefical to both parties, (as long as they are still on speaking terms after the initial product has been commissioned).
At the end of the development phase, the developer is the leading technical expert in all aspects of the software system.
-
New software versions should only be undertaken after the intial version is fully stable and all parties have had adequate time to become familiar with all the ramifications of the existing system.
-
Major software vendors with no exceptions, all go to great lengths to "tie" their customers in to their products.
They attempt to make it impossible or at least impractical for their customers to migrate to a different platform.
They do this by using proprietary closed-source protocols and libraries wherever possible and by on-selling add-ons to their product that won't work with any other system.
They also expect to generate a major part of their ongoing revenue by selling "upgrades" of their system to the customer, often effectively forcing the customer to upgrade or else face losing support or existing functionality.
The end result of this "galloping featurism" are immensely complicated behemothic software systems that often require (expensive) embedded consultants supplied by the vendors to maintain the installed systems.
In many instances the actual core functionality of these systems could be implemented from scratch in a short time frame for less than the annual maintenance and upgrade costs of the installed system.
It would be fair to say that this is the current situation in most large companies throughout the world at present.
Developer - Customer Relationship:
-
Developing bespoke software is an arduous and stressful process and tensions inevitably develop between the customer and developer.
These need to be managed with good humour and empathy by both parties as to what the other is going through.
Good inter-personal communications, trust and patience are essential by all concerned.
-
During the actual coding phase, the customer will often wonder about the apparent lack of progress since they will see money going out and nothing tangible appearing in return.
This is because the code will typically not be functional enough for external testing until the last 10% of the project's total duration, (including commissioning).
The customer can however re-assure themselves of progress by monitoring a live shared Gannt chart and perhaps perusing the public interface of the code base version control system.
If the customer can dedicate an in-house programmer as the liaison then this will greatly improve the level of transparency between the two parties.
|
