When preparing the final stages of your project, you need to start thinking about delivering your system into production. Typically you need to pass from development environments through to testing, integration, user acceptance and finally production. In order to have a good plan that can be successful, here are some things that you need to consider: 1) Are the processes already in place to allow smooth transition? 2) Are there good guidelines and quality assurance procedures involved that will ensure repeatable deliveries? 3) Are all the technologies you are using already in production? 4) Is there experience of how long a typical migration through all environments might take? 5) What is the absolute fastest time that the migration cycle can be completed in? 6) What are the "no go" traps? What quality assurance points are in place that could stop your migrations? 7) Is your build process entirely automated and fully repeatable? 8a) How many people are involved in the migration process? 8b) How many of the people involved in the migration process do you know face to face? 8c) How many of the people involved in the migration process can you go and physically sit next to in the event of problems? 9) How many companies are involved in the migration process? All these points, and surely more, can have big impacts on the delivery process. I recommend doing a trial delivery very early on so that you can discover what the hurdles are. Of course, some quality control…
Tag: Architecture
Requirements Gathering geht schief!
If requirements are gathered by someone who isn't an end user, but who is an expert in the domain, there is the likelyhood that the requirements will be only roughly accurate. If that gatherer then leaves the project and you lose touch with the end users, your'e even more likely to lose your way. On a number of occassions I have seen the end users arguing with the developers as a project comes to a close, over whether what was implemented was what was required. More frequently than not, the system will do what is required, it's just that it does it in a different way. There is more than one way to write a Word document for example! Systems that are complex naturally have more than one solution. It depends on how the persons implementing that solution think - their entire background, culture and education can affect the solution. A fully trained kitchen fitter might have a very different perception of how a kitchen design system should work compared to a software Architect, Developer or Business Analyst. But if the system allows them to design a kitchen, is it relevant if the dialogs, screens, functions and/or business processes of the system are different? Take an SAP system for example. These come preconfigured with thousands of business Processes, Forms, Dialogs, Data Models, etc. SAP allows for example, a company to implement a Supply Chain application. But there are many, many companies which have changed their business processes to match their…
System Colours
We had an interesting experience on our project a few weeks ago. We asked the users for colour specifications for the GUI. Now bearing in mind they have been using a system that is 20 years old, they came up with "green back ground", "blacks", "grays", etc. Here is a demo: OK - I admit I used the brightest green I could find, but the point was that with modern look and feels, we thought it would be better to stick with default colours: Lessons learned? Work closely with the customer but don't be afraid to recommend the sensible options when they arise.
Making Off Shoring Work
Here is a paper I wrote some time back on how we made off shoring successful at a client site.
Kelly Johnsons 14 Rules of Management… for software!
Clarence Kelly Johnson is a famous aircraft designer who worked from the 30s to the 80s on high tech government projects. His management style has become famous because most of his projects ran extremely successful. In fact there are 14 rules of management attributed to him. Here, I attempt to convert them into rules of software management: 1.The software project manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. 2.Strong but small project offices must be provided both by the customer and software development company. 3.The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems). 4.A very simple coding and source control system with great flexibility for making changes must be provided. 5.There must be a minimum number of reports required, but important work must be recorded thoroughly. 6.There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don't have the books ninety days late and don't surprise the customer with sudden overruns. (sic I would even go further and do this every second week). 7.The software development company/department/team must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. 8.A good review system (as currently used by…
7 Sheets of Requirements
Vision "Replace an enterprise information system that has been developed over the last ten years, to allow it to become stable on a modern architecture, to allow two new business units due to a split in the business to develop along their own paths, and to introduce new features that will take the business into the multinational domain." Inception The business wants to know how much such a system will cost. Although its vital for the entire business to be able to continue, it does make sense to get a grip on the costs of such a system, because with a vision like that, they are likely to explode. So the business has approached the IT department and asked for a conceptual phase to be carried out that includes analysis of requirements, conceptual analysis, migration plans and cost estimates. Great, three months ago we started on the technical side. No requirements at this stage, other than the vision. We managed to put together the architecture though, with big caveats with regards to realisation based on actual requirements. Hang on... shouldn't we have stopped before writing about the architecture and waited for requirements? Well the project manager insisted we keep to the deadlines, so perhaps we could "put something together"? His budget, he can spend it how he likes (I get paid by the hour). Two months ago, we completed the migration document. Again, because of a lack of requirements, it was largely conceptual, with lots of pretty flow charts to…
SAP, SOA and a GUI
When I first learned about SAP, I was led to believe it was insular. Sharing its data or uploading data to it was possible, but expensive and discouraged. If you have SAP, stick with it. Then came XI, the SAP eXchange Infrastructure which is the SAP offering for Enterprise Application Integration (EAI), or now rather Enterprise Service Bus (ESB). With it, you can build marvellous Service Oriented Architectures (SOA). So what? Well, my experience of XI is that its used as a replacement for IDOCs, BAPI, EDI and the like. Instead of those hard to use protocols, simply subscribe to a published web service. But hang on... If SOA is in use, couldn't we go a step further? SAP isn't very good at really rich clients (GUIs), and chances are, to develop one would cost a huge amount. So what about the idea of building your business logic on top of existing SAP functionality, so that you extend it to suit your business processes, and then build that rich client on top of the SOA that SAP can offer from your business logic? An example would be the project I'm working on at the moment. We need to build a planning tool for use in Service Stations for trains. Service stations consist of a large number of platforms where trains can be serviced. Some types of service can only be done on some platforms (axle change for example). As well as planning which trains go where and when and for…
Imagine you’re spending your own money
As part of the Architecture definition for a project I'm working on, I have been preparing a cost estimate. The idea is that the client wants to know if they need to tender the project out to third parties, or whether it can be developed in house by the shared central IT department, used by several business units. In a meeting with the client today I presented my initial estimates. Me: "So as you can see, the upper cost will be 820 thousand CHF." Business Unit Project Manager: "Hold it there. You do realise there is a cost threshold at 600 thousand right?! Above that, we have to tender the project out, and that will add a delay of two months!" Me: "Sure. In the pre study, there is a project plan showing that an initial estimate places the work at around a million CHF. And in that study, it allows time for the tendering process. But good news, it shouldn't cost as much as a million..." Business Unit Project Manager: "Can't you somehow reduce the costs? You need to bring it down a little more...We are already running late." At this point, my unprofessional answer (which I managed to hold in) was along the lines of "OK. Instead of me wasting my time doing a real estimate, just tell me how much you want it to cost, or rather how much less you want it to cost than your boss already thinks it will, based on the pre study.…
SLOC
SLOC is "Software lines of code" and is an old measure of productivity when taken as lines of code written per day. There is lots of debate about its use, whether its good etc. But when comparing like for like, it should give valid results. I once worked out that there were something like 20 lines of code a day developed in EAI at my last client (with say 300,000 lines of code in total). We said it wasn't too bad, compared to the old days of OS development quoted as around 5 LOC per day... I'm reviewing a project here with around 160,000 LOC (thats an assumption that the GUI is the same as the back end, which is around 82,000 LOC). It was developed in 5 months over 820 man days. That makes around 200 LOC a day, so ten times more quickly developed than on the EAI project. It includes generated code, but probably as much as the EAI tool gives you, showing that if you want to build an SOA, that old EAI tool is slow to develop with. I then took a look at the maxant demo I did. It has around 36,000 LOC (again an assumption that the GUI has the same amount of code as the back end which is around 18,000 lines), and I did that in around 70 man days. So that's around 500 LOC a day. Both the project I'm now reviewing and the maxant demo have 150 lines per…
Cartoon
This is one of my favourite software related cartoons. Unfortunately I don't know where it came from, so I cannot give credit to the originator. Sorry! (scroll right down to the bottom of the page, since the blog software is trying to be clever...)
