⚠️ This page has been archived

✅ New page with updated info: ssw.com.au

Welcome

Login/Join ssw.com.au
Good Morning 
Sat 04 Mar 09:00 AM in Sydney

Newsletter Statistics

Total Members: 39349
New This Week: 175
New Today: 39
Monthly SSW Newsletters

People Online

Visitors: 146
Members: 9
Total: 155

Contact Us

Email info@ssw.com.au
Phone (02) 9953 3000
Directions Directions to SSW

Search Knowledge Base

 

Search SSW

 
 

SSW XPDM delivers functional, value-adding software - faster

XPDM XP

 

 

Software must help business become more efficient and build better relationships with their Clients. This means that software must also be cost-effective and quick to market. Traditionally, software has been slow to build and difficult to change.

SSW's Development Method XPDM, built on eXtreme Programming, allows businesses to address their most important challenges first, and respond quickly to a changing commercial environment. We prefer to work on-site, in close consultation with you and your business users, becoming an integrated part of your team.

SSW XPDM delivers functional, value-adding software - faster.


eXtreme Programming

There are four key values of XP: Communication, Simplicity, Feedback and Courage.

SSW XPDM Supports
  • Delivering a working application within 1 - 3 weeks from the start of development
  • Time/materials project approach
  • Rapid requirements development
  • Agile application development
  • On-site development (and high level of Client/user project integration)
  • Reassessment of project plan and priorities on regular basis
  • Multi-skilling project team members

These values keep the project alive through continual review and adjustment of the project goals. They emphasise continuous interaction between architects, developers, project managers, business managers and end users throughout the entire development life cycle. By continuous interaction between the team players, XP allows, for example:

  1. Software Architects to determine the requirements fast with Business Managers (" Client Stories " and " Release Plans ")
  2. Project Managers to keep a schedule of Mini Releases only 1 - 3 days in length (" Mini Release Plans ")
  3. Developers to write and review code continuously (" Pair Programming ")
  4. End Users to test and provide feedback on versions of the software on a regular basis (" Release Plan Review "), and
  5. Business Managers to review and change the priorities as the business requirements move

SSW eXtreme Programming Development Method

SSW eXtreme Programming Development Method
Figure: Phases in block colour are done with the Client

  1. Initialise the Project

    Does SSW use Microsoft Project?

    Yes, because some clients tell us to use it, however we don't love Microsoft Project. Simply because a job will become more expensive with the extra layer of administration.

    We prefer to keep costs down, so we use SSW eXtreme Emails! - this tool was developed for the eXtreme Programming approach.

    We give the first meeting for free. During this time we spend about 1-2 hours with a client and try to give as much advice and value as we can. That way, even if you don’t end up using SSW, you get some valuable information. The purpose of this meeting is to:
    1. Assess the overall scope of your project
    2. Determine the best technology to use
    3. Introduce the SSW team
    4. Explain our development method
    5. Discuss our Consulting Order Form and Terms & Conditions . This document is vital to ensure our contract with you is understood.

    During the Initial Meeting, it may be determined to commence work straight away - depending upon the size and scale of the project. If this is decided, we will sign-off the Terms & Conditions and Consulting Order Form and commence billable work.

  2. Determine the Priorities
    Does XP exclude the Big Picture?

    No! SSW XPDM encourages you to look at a whole system at the beginning, but it prevents you from getting bogged down in future details before you have to. This way, we always keep focused on delivering the most important things.

    If the client chooses to go forward, then he commits to one full day to work together. The first step in any software project, once the contract has been signed, is to determine the Priorities. We speak to you about your business. We start at a very high level, and then drill down into the highest priorities (set by the Client) first. SSW and the Client together write "Client Stories". A mockup is then done and a release plan (in priority order) is put together. This work is chargeable.

  3. Write the Client Stories
  4. Scenario

    These are the initial stories that have come out of a meeting between Mr. Northwind and SSW Project Manager and SSW Developer:

    • Manage customers
    • Enter orders
    • Manage products
    • Would like an automated method of transferring order into courier companies like DHL, UPS and FedEx. This would save filling out the forms and faxing the information by the accounts staff
    • Secure for users
    • Secure login customers to check status of their orders
    A Client Story is not a technical document, but rather a simple, 3 sentence explanation in an email of what the Client needs the system to do for them. The purpose of the story is to get an estimate of how long that story will take to design and implement. A Client story, where possible, is turned into a mockup form or a series of mockup forms, which give the look and feel of the application.

    If a story is going to take more then three days it will be cut down so it becomes 1 to 3 days. If the Client requests "A system to manage customers", this will take longer then 3 days. So we break the work down into the smallest units possible. In this case the above request to "manage customers" may be broken down into "add/edit/delete customers" and "searching customers."

    At SSW instead of using cards we manage our releases using emails. The emails pertaining to a release are stored in a public folder - each folder will usually contain about 2 weeks worth of development work.

    XP Release Plans In Outlook
    Figure: We use public folders to manage our releases.

  5. Write the Release Plan
  6. The Client Stories are pieced together into a Release Plan.

    A Release Plan covers tasks that will be performed over 1 - 3 week period. It lists what functionality will be delivered, and the time and cost estimates associated with those tasks. Each Release Plan is treated as a separate proposal and must be signed off after review by the Client.

    At SSW we use an application we built called eXtreme Emails! to manage our releases. This makes constructing a release plan as easy as clicking a button!

    XP One Click
    Figure: Releases are created with one click of the mouse with SSW eXtreme Emails!

  7. Review the Release Plan
  8. The Release Plan is agreed to by the Client and the Developers, ensuring that both sides are happy with what is expected for the next Release. Keeping Release Plans to 1 - 3 weeks means that priorities must be agreed, so that the core components of the software are delivered first.

  9. Plan the Mini Release

    A Mini Release is a technical description of the Release Plan, broken down into 1 - 3 day programming tasks. Remember, the Release Plan is a series of functional requirements in an order agreed upon by the Client and SSW. These tasks are broken down into Testing and Development, in that order!

  10. Write the Tests
  11. According to XP, Tests are written before Development takes place. This means that ALL development that occurs must run according to the rules set down. This is an efficient way of catching and fixing bugs in code.

    The idea here is to plan a set of unit tests that you can run each time you add functionality to an application. This is a great way to ensure that you haven't 'broken' any of your existing functionality when you add new features - if all the tests still pass then you know you're in the clear!

    XP NUnit In Our Products
    Figure: Running Unit Tests using our in-house application - SSW Code Auditor

    NUnit Pass
    Figure: A successful testing run

    NUnit Fail
    Figure: Test failures catch problems early

  12. Develop the Mini Release
  13. What is Pair Programming?

    Pair Programming is two developers sitting side-by-side, working together on the same design, function or form (on the one PC). Software is complex and the benefits of working together are:
    * Less time stuck on a problem - you have someone familiar with the project to help you work through the problem
    * Your code with have less a strange workarounds - because if something doesn't add up to a developer, he has someone to ask
    * Cleaner code - because you know someone else is going to be looking at your code
    * Support - when you need changes down the track, you have 2 people to call on

    Do we do Pair Programming at SSW?

    Not if we use that definition. At SSW we have our own version of Pair Programming. We work in 2's but each developer has a PC and they sit right next to each other. We do this because we get the benefits of 2, but have a lower cost overhead.

    Is there an Overhead?

    Some projects are done quicker with 2 people - especially when they are complex. But on most projects there is an overhead, because of the extra communication between the developers - you now have to please someone else - not just yourself.
    We generally estimate the overhead as 20% extra. But this is more than offset by the cleaner code and better solutions that come from two brains working together.

    The Development Tasks are the names of all the Forms, Functions, Objects, Stored Procedures that will be used in the next 1 - 3 days development. Once the tasks have been agreed, the tests are written and development commences. Progress is reviewed at the end of every Mini Release. SSW prefers to write most production code using our own version of Pair Programming. SSW manages projects and codes according to its own set of standards and rules .

  14. Test the Release
  15. At the end of the Release Plan schedule (1 - 3 weeks) SSW releases a version of the software to the Client for review. The Client reviews the delivered version against the Client Stories created at the first step. Where deficiencies arise, they are fixed before future development takes place (SSW strictly believes in fixing bugs before writing new code ).

  16. Approve the Release (Debrief)
  17. When the project comes to the end of the final release, the application goes into final review by the Client. If the project was on a fixed-price basis the 30 day warranty commences. At the end of 30 days the application is signed off by the client. If issues are found subsequent to the 30 day period, the issues are resolved at SSWs standard hourly rates.

  18. Deploy the Release
  19. When both sides are happy with the version, the application is deployed into production or if required we sit with the Client again and determine the next release by working through the Client Stories once again.

  20. Training
  21. In many instances new applications are built according to the direction of management, and the users are the last ones to actually check out the new system. SSW XPDM traps this at the very beginning, bringing the real business staff into the design process. On top of this, SSW technical staff work directly with your business users to demonstrate and implement the software.

  22. Support
  23. Different Clients need different levels of support. We understand that your needs must be met, for user assistance or high-resource emergencies. Contact us for more information.

  24. Further Development
  25. We understand that your business continually changes. That's why we use SSW XPDM. Should your business needs require further development, we can begin the process again.

Sounds Interesting - But why this way?

SSW XPDM is about minimising risk and maximising benefit. There is no doubt that Software Development is still an inexact science with a whole gamut of risks and benefits. SSW XPDM ensures that risk is minimised to only a 1 - 3 week period. If either the Client or SSW is completely way off reality after the first Release Plan, it is captured quickly, and design and development can be adjusted accordingly.

SSW XPDM maximises the good things about Software Development (such as reviewing code, and getting feedback). Through this, we hope, better software applications are delivered.

OK, you've sold me - What's the cost?

Following SSW XPDM requires a high level of commitment from both the Client and SSW. The Client becomes an essential ingredient thoughout the project. This means that we need your time, to design and review, regularly, and we'll probably be working alongside you for most of the project.

SSW XPDM DOES allow you to think clearly about what you want, and get that delivered sooner. If this has got you thinking, please free to give us a call .

Managing Software Consultants

SSW developers follow a series of standards to ensure successful projects and good quality code.

But we've also taken some thought and learnt some lessons about what it's like being on the other end of the software development stick. These Rules are there to help you manage your software consultants effectively.

Links

www.eXtremeProgramming.org You are about to leave the SSW site
www.xprogramming.com You are about to leave the SSW site
www.refactoring.com You are about to leave the SSW site
www.c2.com You are about to leave the SSW site  

Acknowledgements

Adam Cogan
Cameron Shaw



Load Time: 0.0 Seconds