David Woodfield

Project Design

davidwoodfield — Thu, 18 Feb 2010 16:12:53 +0000

Colour Articles

http://www.smashingmagazine.com/2010/01/28/color-theory-for-designers-part-1-the-meaning-of-color/

http://www.smashingmagazine.com/2010/02/02/color-theory-for-designers-part-2-understanding-concepts-and-terminology/

http://www.smashingmagazine.com/2010/02/08/color-theory-for-designer-part-3-creating-your-own-color-palettes/

Smashing Book

Library books

Kuler

Twitter API Project

davidwoodfield — Thu, 18 Feb 2010 15:56:34 +0000

Case Study

I’m going to pretend that I’m working for a company and I’m an Intranet developer, my boss has approached me and explained that senior management want to incorporate the social networking phenomenon Twitter into the company Intranet. They would like me to come up with a prototype and produce a critical evaluation of the service in the form of a report.

Features

A list of given twitter users and avatars
View twitter time line of individual users
View twitter profile of individual users
View latest tweets from collection of the given users
Self updating time line
Create new tweet
View own tweets

Prototype

The finished prototype will be an HTML web page. The technologies used will be HTML, CSS and JavaScript. These technologies are cross-platform and run inside a web browser in HTML format.

What is Twitter?

“Twitter is a real-time information network powered by people all around the world that lets you share and discover what’s happening now.” (http://twitter.com/about)

Twitter works by letting you read or write messages of up to 140 characters. These are known as tweets. Each user has a time line that displays their tweets, tweets can be public or private depending on what settings you choose. Your Twitter home page displays tweets from all the people you are following, listed in chronological order. To follow another twitter user, you simply navigate to their profile, opt to follow them and the next time they tweet it will appear on your home page.

Twitter also supports direct messages and mobile phone usage. It is one of the most talked about Internet service in the world.

Twitter API

The twitter API is located at http://apiwiki.twitter.com. There is a comprehensive wiki on the API which is simple and easy to use.

There are actually three Twitter APIs, there is the REST API and streaming API which both connect to users information and tweets and there is the search API used to query all tweets and users.

It is an HTTP-based API making use of GET requests. POST and DELETE requests are used to submit, change or delete data and require authentication.

Authentication is handled either by basic authentication or OAuth. Basic authentication sends user credentials in the header of the HTTP request. This makes it easy to use, but insecure. OAuth is a token-passing mechanism that allows users to control which applications have access to their data without giving away their passwords. OAuth is Twitters preferred method of authentication although they have no plans to remove the basic authentication, eventually they would like to suspend it.

Requests to Twitter can be returned in a variety of formats, currently the supported formats are: xml, json, rss and atom.

Twitter controls the amount of requests to the API and advises developers to program for error responses. The default rate limit for calls to the REST API is 150 requests per hour. Rate limiting only applies to methods that request information with HTTP GET command, although Twitter has daily limits for users to discourage spam. The search API also has a rate limit but Twitter does not disclose what the figure is stating the rate is both liberal and sufficient for most applications.

Twitter will try to return appropriate response codes for each request and developers are advised to cater for these.

200 OK: Success.
304 Not Modified: There was no new data to return.
400 Bad Request: The request was invalid.
401 Unauthorised: Authentication credentials were missing or incorrect.
403 Forbidden: The request is understood, but has been refused.
404 Not Found: The URI requested is invalid or the resource requested, such as a user, does not exist.
406 Not Acceptable: Returned by the Search API when an invalid format is specified in the request.
420 Enhance Your Calm: Returned by the Search and Trends API when you are being rate limited.
500 Internal Server Error: Something is broken.
502 Bad Gateway: Twitter is down or being upgraded.
503 Service Unavailable: The twitter servers are up, but overloaded with requests.

Responses 400 and 403 will always contain an accompanying error message to explain the error.

The Twitter API has certain rules that developers of 3rd party applications must adhere to. The rules are:

Identify the user that authored or provided the Tweet, unless you are providing Tweets in an aggregate form or in anonymous form in those exceptional cases where concerns over user security and anonymity are involved.
Maintain the integrity of Tweets and not edit or revise them. Tweets may be abbreviated for display purposes and as necessary due to technical limitations or requirements of any networks, devices, services or media.
Get each user’s consent before sending Tweets or other messages on their behalf. A user authenticating with your application does not constitute consent to send a message.
Get permission from the user that created the Tweet if you want to make their Tweet into a commercial good or product, like using a Tweet on a t-shirt or a poster or making a book based on someone’s Tweets.
Clearly disclose when you are geotagging a user’s tweets. If you are looking for guidance on an approved disclosure, see the Geotagging Best Practices.

The last bullet point touches on geotagging tweets, this is a recent addition to the api and is a simple piece of meta-data to identify the tweeters location. This functionality is popular in mobile phone applications or is at least “trending”.

Place holder

davidwoodfield — Wed, 25 Nov 2009 13:36:38 +0000

This is a place holder for future weekly project blog posts.

Extreme Programming Plan

davidwoodfield — Wed, 25 Nov 2009 12:56:27 +0000

Research

Email
Web Chat
Software development methodologies
Data Storage
Sever side programming languages
Web application architecture
Client side programming languages
Rich Internet Applications
Comparison of webmail providers
Common properties of website design (chapter 1 smashing mag?http://media.smashingmagazine.com/pdfs/sm-book-chapter1.pdf)

Iteration 0

Write system vision
Write system metaphor
Build environment and select and install development tools
Customer lists all the stories they expect to appear in the application

Give stories short names in addition to a short prose or graphical description. Write the stories on index cards and put them on a frequently passed wall. (Extreme programming explained)

Write user acceptance tests

This object represents one or more precise scenarios that the customer writes to test a given user story. it defines initial values and preconditions, along with result values and postconditions.When the acceptance tests for a story are all passed, the story is complete. A goal of XP is that each story should be small and detailed enough to permit only one acceptance test per user story.

Plan theme or themes for first quarter
Pick a quarters worth of stories to address those themes
Focus on the big picture, where the project fits within the organisation
Plan and list reuseable components and design
Initial design of reusable components

Weekly Iteration

Review progress to date, including how actual progress for the previous week matched expected progress
Select a weeks worth of stories
Write automated tests that will run when the stories are completed
Design and code story
review design and code
test story
if fails – go back to step 3
Integrate story into system
Intergration test story
if fails – go back to step 3
Acceptance test story
if fails – go to user and try to understand what you didn’t before
Passed
Go back to step 1 until all stories are completed for this week.
Complete blog entry for this week.

Quarterly Cycle

Initiate repairs
Plan the theme or theme for the quarter
Progress check
Focus on the big picture, where the project fits within the organisation

Time Expired

Release working system to customer

Software Development – Senior Management

davidwoodfield — Tue, 24 Nov 2009 17:09:29 +0000

Resources & References

Layout

Abstract
Introduction
What is a project?
What is a successful project?
What is a failed project?
What is senior management?
The relationship between senior management and the success of a project
The relationship between senior management and the failure of a project
Conclusions
References

Resources for PHP Webmail

davidwoodfield — Tue, 24 Nov 2009 16:51:45 +0000

PHP

IE BUGS

http://net.tutsplus.com/tutorials/html-css-techniques/9-most-common-ie-bugs-and-how-to-fix-them/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%253A+nettuts+%2528NETTUTS%2529&utm_content=Google+Reader

JavaScript & jQuery

jQuery Plugins

General

CSS

Version Control

Software Methodologies

davidwoodfield — Tue, 17 Nov 2009 00:22:20 +0000

Methodologies

In this section I will list the properties of system development and briefly explain the system development life cycle. I will introduce several different methodologies and illustrate which methodology I have chosen and why.

System development projects have similar properties broken down into stages, these stages are normally.

Decide that a new system is needed
Find out what the new system should do
Decide how the new system will function and look
Build and test the system
Implement the system
Use and maintain the system

(Weaver, P, 2004)

Software projects usually adopt a methodology to carry out these steps, there are various methodologies that approach these steps differently. Software methodologies are also know as life cycle models.

Life cycle models provide a framework for managing and structuring a project, while approaches and methods provide the activities, tasks and deliverables used within the framework. (Weaver, P, 2004)

Waterfall

The waterfall model is the simplest software development methodology, work packages are broken down into stages. In a strict interpretation of the waterfall model, each stage is subject to a quality assurance check and only if the stage passes this check is it signed off as being complete. The next stage is started once the previous stage has finished, this insures that each new stage starts from an agreed baseline established at the end of the preceding stage.

It is well suited to formal project planning and control, and its insistence of QA reviews and sign-offs makes it relatively easy to build into contractual projects. (Weaver, P, 2004)

The stages of the waterfall model are:

System requirements
Software requirements
Analysis
Program design
Coding
Testing
Operations

The implementation steps listed above are shown below in the diagram. From the diagram you can see that none of the stages overlap, the diagram illustrates the time structure of a project using the waterfall model. The next stage is not started until the previous stage has been completed.

(Royce, W. W, 1970)

The waterfall model is used extensively in industry, particularly on large projects. It is suited to projects where requirements are well defined and are not likely to change. Its ready made structure makes it easy to build a simple plan and the sign off process at the end of each stage is a neat indicator to how well the project is going.

The first reservation, and the greatest disadvantage of the waterfall model, is that the product of the development process, ‘the target system’, is not available for testing or trial by its intended users until the end of the project. (Redmill, F, 1997)

The waterfall model delivers a system at the end of development, a disadvantage of this approach is that users will not be able to test the system until final deployment. If the length of the project is large user requirements may change. This is a big problem as the waterfall model does not allow backtracking and re-visiting of steps. The longer the time period and the larger the project, the greater the chance of user requirements changing and the greater the chance that the project will fail.

The waterfall model does have fatal disadvantages, however it continues to still be used. Mainly because it represents a natural order of events, simply put: design, build, test and deliver. This natural process is used in many projects, even if not the main methodology. Methodologies split into sub-sections or iterations may apply the waterfall model to each mini – project or iteration. Although the waterfall model is the oldest, simplest model it continues to survive.

Spiral Model

Where requirements are not well known in advance the spiral model may provide an alternative to the waterfall method. (Weaver, P, 2004)

The spiral model is a more dynamic method able to adapt to changing requirements. Initially a lot of work is spent producing requirements meaning more time can be spent developing user interfaces. The model uses an iterative approach to develop the system. In the initial cycle high level requirements are drawn up and an initial prototype is built. This prototype is reviewed, requirements are clarified and the result is an updated requirements specification. The cycle is repeated and each iteration brings the prototype closer and closer to the final product.

In the spiral model the risks are assessed at each step and the path or best direction to proceed is chosen, which best overcomes the assessed risks. If a risk is deemed to be insolvable or it is clear that a project cannot continue, the project will be cancelled. This identification of a fatal risk is a factor that the waterfall model does not cater for as in the waterfall model this fatal risk would only be discovered at the end of a project. The spiral model checks for risks at each iteration, therefore if a fatal risk was found the organisation could save money by cancelling the project rather than continuing and wasting money.

In a typical cycle of the spiral model, the spiral begins with the identification of the objectives, a plan B or an alternative means of implementation and the risks imposed of the application.

After the risk analysis a prototype is developed for the initial requirements. This step also involves evaluating the alternatives relative to objectives and risks. This process should identify areas of risk significant to the project.

If risks are identified the next step will involve developing a strategy for resolving the sources of risk. Actions at this stage could be, prototyping, simulation and other risk resolution techniques.

In the next step the nature of the product is assessed, this could be future requirements or operations and a detailed design of the product.

The final step is to produce a plan for the next cycle. This plan depends on what stage of development you are at, but it could be a requirements plan, a development plan or possibly an integration and test plan.

The diagram below illustrates the concept of the spiral model.

(Boehm, B, W, 1988)

The primary advantage of the spiral model is that its range of options accommodates the good features of existing software process models, while its risk-driven approach avoids many of their difficulties. (Boehm, B, W, 1988)

As mentioned earlier the main advantage to the spiral model is that it handles changes in user requirements and is a much more flexible and dynamic model than the waterfall model.

One problem with the spiral model is that is doesn’t provide a clear structure of development from the offset. It is this difficulty that may prevent contracts being accepted because the deliverables from a spiral model project are not well specified in advance.

The spiral model also assumes the developers have a high level of risk assessment. The spiral model is practically built around risk assessment and therefore if the developers are not highly competent they will not be able to identify major risks and therefore a project that appears to be running smoothly may well be heading for disaster because of poor risk analysis.

Incremental Model

Incremental development is a staging and scheduling strategy in which various parts of the system are developed at different times or rates and integrated as they are completed. (Cockburn, A, 2008)

In the incremental model a system is divided into phases, each phase is run as a mini project. This model often results in a number of releases over a period of time. Although each phase will be different they will all be built on a common set of requirements. As later phases are delivered they will inevitably cause some rework in the software delivered by earlier phases.

Rather than delivering your software to your client towards the end of your project in ‘big bang’ as the conventional methods do, it might be better to deliver the system to them as a series of intermediate working sub-systems over a period of time. (Dawson, C. W, 2009)

Each increment is a mini project in itself and therefore can make use of the waterfall or spiral model in each increment. The incremental model works best when system requirements are clear for the entire system and are relatively stable. If the requirements are unclear then each new increment could lead to major rework of earlier increments.

To demonstrate the incremental approach take a look at the diagram below. The diagram shows a large cube made up of smaller cubes. The smaller cubes are the different increments. At stage 1 of development a few increments have been completed, each further stage adds more increments until the system is completed.

Incremental Development, Stage 1

Incremental Development, Stage 2

Incremental Development, Stage 3

(Cockburn, A, 2008)

Some advantages to using the incremental model are that the user gets something early so that they can get an idea of the system’s capabilities. The user can also provide feedback after each increment if they find that something isn’t right. Also, by delivering something early it can give the developer a sense of achievement and the user a clear understanding that progress is being made on the project. Another advantage is that the user does not need to be trained on the entire system in one go. They can familiarise themselves which each increment and then feel comfortable once all the pieces are installed. (Dawson, C. W, 2009)

A difficulty with using the incremental model is that it may be difficult to break the system down into chunks that are actually worth delivering to the user. There is no point delivering small chunks that provide little or no improvement to the system. Another scenario that might occur is that the user is happy at stage 2 and doesn’t need or want to develop any further, they don’t want to pay the extra costs to develop the system further so therefore cancel the remaining parts of system.

Agile methods

The term agile methods was adopted in 2001, it refers to approaches to software development that reduce risk by delivering software systems in short bursts or releases. The agile method aim is to release a working system at the end of each cycle, although each cycle might not produce a working system, the main aim is to release the system.

Agile methods are well suited to projects that have unclear or rapidly changing requirements. (Dawson, C. W, 2009)

Agile methods are based on a common set of 4 values and 12 principles.

The 4 values are:

Individuals and interactions – over – processes and tools
Working software – over – comprehensive documentation
Customer collaboration – over – contract negotiation
Responding to change – over – following a plan

The 12 principles of agile software development are:

The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity, the art of maximizing the amount of work not done is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

(Manifesto for Agile Software Development, 2001)

The most popular Agile methods are:

Scrum
Dynamic Systems Development Method (DSDM)
Crystal Methods
Feature Driven Development
Lean Development
Extreme Programming (XP)
Adaptive Software Development

(Hayes, S., Andrews, M)

The agile development life cycle is demonstrated below

(Version One, 2009)

From the diagram you can see that agile development is like a continuous evolving waterfall model. It encapsulates the properties of the waterfall model to deliver them on a daily basis. It produces solutions in iterations, with the ability to change at its core. Agile development prides itself of using the best bits from all the other successful methodologies.

Agile development is not invincible and still suffers from any of the problems that other methodologies will encounter. Agile methods claim that the model will usually discover the problems earlier than traditional models and therefore save time and money.

Extreme Programming (XP)

Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities—a little at a time—throughout development. (Beck, K, 1999)

Extreme programming is one of the most popular agile software development approachs. It was introduced in an attempt to improve the way is which software is developed.

The approach actively encourages the users to be involved with the development process and anticipates the positive influence they will have on requirements capture. (Dawson, C. W, 2009)

Customers drive the content of the system. The whole team drives the development process. XP lets you adapt by making frequent, small corrections; moving towards your goal with deployed software at short intervals. You don’t wait a long time to find out if you were going the wrong way (Beck, K, 2004)

XP embraces five values to guide development:

Communication
Simplicity
Feedback
Courage
Respect

XP uses principles to bridge the gap between values and practices. The priciples of XP are a set of domain-specific guidelines for finding practices in harmony with XP’s values. The principle are:

Humanity

This principle goes on the basis that people develop software and software development is done by people therefore should meet human demands. It ask what do people need to be good developers. One factor of the humanity principle is to limit the working hours to allow for other human needs.

Economics

This principle ensures that the project has buisness value, meet business goals, and serves business needs. This practice is intended to enhance the option value of both the software and the developers while keeping in mind the time value of money by not investing in speculative flexibility.

Mutual Benefit

This states that every activity should benefit all concerned. It is the most important XP principle yet the most difficult to adhere to. Often the question is asked, why should I write documentation for some unknown person to use in the future? XP attempts to solve a communication-with-the-future problem in mutually beneficial ways:

The developer writes automated tests that help them design and implement better today and they leave the tests for future programmers to use as well.
The developer carefully refactors to remove accidental complexity, giving them both satifaction and fewer defects and making the code easier to understand for those who it encounter it later.
Names are chosen from a coherent and explicit set of metaphors which speeds up the development and makes the code clearer to new programmers.

Self-similarity

This is about taking a structure from one solution and seeing if it will fit in another solution. The idea for XP is that a developer writes test expressing user stories and then implements the story and makes sure the test works. Having the system-level tests before you begin implementation simplifies design, reduces stress, and improves feedback.

Improvement

As the name sugests, this is about improving on what you have done already. There is no perfect process or solution, however one can perfect your process, your design and your stories. The point of XP is excellence in software development through improvement.

Diversity

Teams where everyone is alike are not effective. Teams require a variety of skills and need mulitple ways of thinking about problems. Teams need diversity and variation to succed.

Reflection

Good teams don’t just do their work, they think about how they are working and why they are working. The cycles in XP development include time for reflection. Reflection, however shouldn’t be taken too far and people shouldn’t be so busy thinking about development that they don’t actually have time to develop software. Reflection comes after action and learning is reflecting on actions.

Flow

Flow is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously. The practices of XP are biased towards a continuous flow of activities rather than discrete phases.

Opportunity

XP treates problems as opportunities for change. It doesn’t completely disregard problems in software development it simply states that problems need to turn into opportunities for learning and improvement, not just survival. An example is, if I one person programming alone makes too many mistakes utilise the pair programming technique.

Redundancy

The critical, difficult problems in software development should be solved several different ways. XP claims the cost of the redundancy is more than paid for by the savings from not having the disaster. Having a testing phase after development is complete in XP should be redundant however it should only be eliminated when it is proven to be rundunant after several deployments in a row.

Failure

If you’re not succeding in XP, then fail. If the developer doesn’t know which of three ways to implement a story, he/she should try all three. Even if they all fail, something of value would of been learnt.

Quality

Each increase in quality leads to improvements in other desirable project properties, like productivity and effectiveness. Quality isn’t a purely economic factor, people need to do work they are proud of.

Baby Steps

Baby steps are where iterations are produced is small steps rather than having big changes in big steps. Baby steps acknowledge that the overhead of small steps is much less than when a team wastefully recoils from aborted big changes.

Accepted Responsibility

The practices reflect accepted responsibility by, for example suggesting that whoever signs up to do work also estimates it. Similarly, the person resposible for implementing a story is ulitimately responsible for the design, implementation and testing of the story.

(Beck, K, 2004)

Practices are the things that XP teams do day-to-day. XP states that practices are situation dependent. The practices are split into two categories, Primary and Corollary practices. The primary practices can be used independent of what else you are doing and give immediate improvement. Whereas the corollary practices are likely to be difficult without first mastering the primary practices. (Marchesi, M) groups the practices into four categories:

Requirement Analysis and Planning
Team and Human Factors
Design
Software Coding and Release

Primary Practices

Requirement Analysis and Planning

Stories: the functionalities of the system are described using stories, short descriptions of customer-visible functinalities. Stories also drive system development
Weekly Cycle: software development is performed a week at a time. At the beginning of every week there is a meeting where the stories to develop in the week are chosen by the customer.
Quarterly Cycle: on a larger time scale, development is planned a quarter at a time. This is made up of reflections on the team, the project and progress.
Slack: avoid to make promises you cannot fulfill. In any plan, include some tasks that can be dropped if you get behind. In this way, you will keep a security margin, to be used in the case of un-forecasted problems.

Team and Human Factors

Sit Together: development teams should work in an open space, able to host the whole team, to maximise communication.
Whole team: the team should be composed of members with all the skills and the perspectives needed for the project to succeed. They must have a strong sense of belonging, and must help each other.
Informative Workspace: the workspace should be provided with informative posters and other stuff, giving information on the project status and on the tasks to be performed.
Energized Work: developers must be refreshed, so that they can focus on their job and be productive. Consequently, limit overtime working so everyone can spend time for his or her own private life.
Pair Programming: the code is always written by two programmers at one machine.

Design

Incremental Design: XP opposes producing a complete design up front. The development team produces the code as soon as possible in order to obtain feedback and improve the system continuously. Design is indispensable to obtain good code. The question is when to design. XP suggests to do it incrementally during coding. The way helpful to obtain this is to eliminate duplications in the code.
Test-First Programming: before updating and adding code, it is necessary to write tests in order to verify the code. This solves four problems:
- Cowboy coding: It is easy to get carried away to program quickly and put everything in mind in the code. If we write tests and you have to run them, the tests help us focus on the problem at hand, and can prove that our design in correct.
- Coupling and cohesion: if it isn’t easy to write a test, this means that you have a problem of design, not of testing or coding. If your code is loosely coupled and highly cohesive, you can test it easily,
- Trust: If you write code that works and you document it with automated tests, your teammates will trust you.
- Rhythm: it is easy to get list and wander for hours when you are coding. If you accustom yourself to the rhythm: test, code, refactor, test, code, refactor, it will not happen.

Software Coding and Releasing

Ten-Minute Build: System should be built and all the tests should be finished in ten minutes, in order to execute it often and obtain feedback.
Continuous Integration: Developers should be integrating changes every two hours in order to ease integration headaches.

Corollary Practices

Requirements Analysis and Planning

Real Customer Involvement: people whose lives are affected by your system must become a part of the team and they can contribute to quarterly and weekly planning.
Incremental Deployment: when replacing a legacy system, start to replace some functionalites right away and gradually replace all of the system. Avoid the approach of “All or nothing”
Negotiated Scope Contract: contracts for software development would have fixed time, costs, and quality, but the precise scope of the system would have to be negotiated during the same realisation. Eventually it is better to have a sequence of short contracts in order to reduce risks.
Pay Per Use: a customer usually pays for each release of the software. This creates a conflict between the supplier and the customer, who would want fewer releases each containing a lot of functionality. Connecting money flow directly to software development provides accurate, timely information with which to drive improvement.

Team and Human Factors

Team Continuity: the development teams must remain the same in several projects. The relationship they share in a project are precious and they do not have to be dispersed.
Shrinking Teams: as the team becomes more capable and productive, keep its load constant but gradually reduce its size.

Design

Root-Cause Analysis: every time you find a defect, eliminate it and its causes. In this way, not only will you eliminate the defect, but also you will prevent making the same mistake again.

Software Coding and Releasing

Code and Tests: only code and tests are permanent artifacts and they have to be preserved. The other documents can be generated from code and tests.
Shared Code: anyone in the development team must be able to change any part of the system at any time.
Single Code Base: there is only one official version of the system. You can develop a temporary branch, but it doesn’t live longer than a few hours.
Daily Deployment: every night you must put new software into production. It is risky and costly to have a gap between the version of software released into production and ones you have in your computer.

Extreme programming can fail when the programmers take on too much work at one time. This overestimation causes the project to be delayed and could be down to the programmers taking on more than they are cable of. Another hurdle to extreme programming is if the user or customer is cooperative or simply doesn’t have the time to give their input often enough.

The methodology I have chosen

Everything is software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change. (Beck, K, 2004)

Customers expect software to be soft. Traditional methodologies establish procedures that discourage requirements changes, they resist change. This helps them maintain a predictable schedule, but it does nothing to ensure that the final results meets the customers real, changing needs. (Hayes, S., Andrews, M)

The methodology that I will be adhering to is Agile methods. In particular I will focus on Extreme Programming (XP). Agile practices are not new methods but they certainly cope with new environments and changing conditions. The XP model of, user stories, choosing a user story, writing a test case, implementing the story, testing the story and developing the solution in iterations is an attractive approach that allows for modern techniques and practices, and of course an ever changing environment.

I have worked in a web application environment and it is safe to say, users do not always know what they want. I would receive a requirements document from a business analyst and be asked to implement the solution. After reading the specification, I would have questions that the analyst simply couldn’t answer without the user. The user would need to be contacted and consulted. The most common scenario would be a user coming to visit me at my desk, call me on the phone or email me asking for changes to the features, the design and even the data model. Projects continually became late and some were even cancelled or just forgotten because they weren’t desired by the user any more. The traditional method that my company adapted just wasn’t agile and couldn’t cope with change.

The traditional approach to developing systems using the waterfall, spiral and incremental approach all require specific documentation, design phases, development phases and strict rules. The spiral model tries to handle change but it simply isn’t agile enough. Agile methods can adapt to change and concentrate on producing software, which is ultimately what the customer wants.

From my experience the user wants to know:

If you can do certain things
When those things will be ready
Can you change this or that
When will this or that be ready
etc

Agile methods are perfect for this type of user. Users don’t want to be bogged down with sheets and sheets of documentation and planning, they simply want a system that does want they want and works. In our modern ever changing lifes there is a demand for having something now. Not tomorrow, not next week, now. Agile methods and XP are based around this attitude and the user is always involved.

Tradtional methodologies usually divide development into three major phases, analysis, design and coding. XP makes the assumption that design and coding need to be intimately interlaced. This is so true, because systems just based on data and storage information may well conform to strict standards but the main and essential part to any web application is the user interface and how the website interacts with the user. If the web application has ten different tabbed sections and a particular user only ever needs the seventh tab, then every time this user logs in, the seventh tab should be displayed. This is an example of the data working with the features or the design and coding intimately interlaced. If in this example I had adopted the waterfall model and the customer suddenly decided mid-project that they needed this feature the answer would have to be no, sorry it wasn’t in the specification and trying to make changes could leave the project in a mess and most probably result in it missing its finish deadline.

I will be using Agile methods, predominately Extreme Programming to develop my application.

References

Dawson, C. W. (2009) Projects in Computing and Information Systems (2nd Ed). Dorchester, Dorset: Pearson Education Limited

Weaver, P. (2004) SUCCESS IN YOUR PROJECT A GUIDE TO STUDENT SYSTEM DEVELOPMENT PROJECTS. Glasgow: Pearson Education Limited

Redmill, F. (1997) Software Projects Evolutionary vs. Big-Bang Delivery. Norton, Somerset: John Wiley & Sons Ltd

Royce, W. W. (1970) MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS. [on-line] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf, date accessed: 17 November 2009.

Boehm, B, W. (1988) A Spiral Model of System Development and Enhancement. [on-line] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/spiral.pdf, date accessed: 17 November 2009.

Beck, K. (1999) Embracing Change with Extreme Programming. [on-line] http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/extreme.pdf, date accessed: 17 November 2009

Cockburn, A. (2008) Using Both Incremental and Iterative Development. [on-line] http://www.stsc.hill.af.mil/crosstalk/2008/05/0805Cockburn.html, date accessed: 17 November 2009

Manifesto for Agile Software Development. (2001) Twelve Principles of Agile Software. [on-line] http://agilemanifesto.org/principles.html, date accessed: 17 November 2009

Version One, (2009) Agile Development Poster. [on-line] http://www.versionone.com/pdf/agileposter.pdf, date accessed: 17 November 2009

Beck, K. (2004) Extreme Programming Explained: Embrace Change (2nd Ed). Addison-Wesley Professional

Marchesi, M. The New XP. [on-line] http://www.scribd.com/doc/196734/The-New-XP, date accessed: 17 November 2009

Hayes, S., Andrews, M. An Introduction to Agile Methods. [on-line] http://www.scribd.com/doc/6736392/Agile-Methods, date accessed: 17 Novemeber 2009

Data Storage

davidwoodfield — Tue, 17 Nov 2009 00:20:18 +0000

Data Storage

Data stored on the Internet is usually either stored in a relational database or stored as plain text XML. In this section I will look at the differences between XML and databases and their advantages and disadvantages.

Databases

Databases can be categorised into data models that describe the structure of the database. A data model is a collection of tools usually including a type of diagram and specilised vocabulary for describing the structure. A data model a description of the database structure including the data, the relationships within the data and sometimes the sematics or meanings of the data.

Web Application Architecture

davidwoodfield — Tue, 17 Nov 2009 00:18:44 +0000

Web Application Architecture

One model has evolved as the standard practise for web applications, and that is the Model-View-Controller (MVC) pattern. MVC is an architectural pattern, it is a proven, repeatable way to describe the structure of an application. Every book and website I researched preached the use of MVC. The benefit of using the MVC pattern is that it separates the user interface from the business logic, meaning changes to one of these doesn’t require changes to another.

Model

Contains the application data and logic to manage the state of the application. (Sanders, W., Cumaranatunge, C., 2007)

The application logic in the model performs two important tasks. It responds to requests for information and takes action on the requests to change the state of the application and update the view if necessary. Normally the view is a database and the functions and classes that interact with it.

View

Presents the user interface and the state of the application onscreen. (Sanders, W., Cumaranatunge, C., 2007)

Users interact with the application via the view. A user will use a web browser to access the view, views can be both inputs and outputs. A typical application will contain multiple views.

Controller

Handles user input to change the state of the application. (Sanders, W., Cumaranatunge, C., 2007)

The controller consists of the code that handles communication to the model about actions taken on the user interface elements in the view. This could be a request to the model when a form is clicked or a more contemporary example is when an Ajax request is fired to the server.

Communication

Each element in the MVC pattern communicates with each other in specific ways. This communication is a series of events that is usually started by a user interacting with the interface of the application. The sequence is as follows.

User interacts with an interface element (Submits a form)
The view sends the form details to the controller to decide how to handle it (Sever side class)
The controller changes the model based on how it decides to handle the form submit (SQL manipulation)
The model informs the view that the state of the model has now changed (The SQL query returns true as the action was successful)
The view reads information from the model and updates itself (New page loaded or page refreshed)

(Sanders, W., Cumaranatunge, C., 2007)

In some cases the controller will directly tell the view to make changes, this is only when changes in the view do not require a change in the model. Also the model can update itself based on certain events. There may be a function that gets data from another database and inserts it into your model database every night. In this example a scheduled event takes place updating the model without any user interaction. Each model can also have multiple views associated with it. A web application normally has many pages which can be classed as views. The model, view and controller are thought of as separate parts each part is separate but requires certain references. The model needs to have references to the views, the views need references to both the model and controller and the controller needs a reference to the model.

(Sanders, W., Cumaranatunge, C., 2007)

References

Sanders, W., Cumaranatunge, C. (2007) ActionScript 3.0 Design Patterns. Sebastopol, CA: O’Reilly Media, Inc.

Web Chat

davidwoodfield — Tue, 17 Nov 2009 00:09:40 +0000

Web chat

A web chat is a system that allows uses to communicate in real time using easily accessible web interfaces. The chat happens within the browser and no additional software is needed. I have followed various simple chat room tutorials on the internet and the chats are either stored in a database or a text file. If a text file is used the server checks the text files timestamp to determine if data has been appended to it. A database chat will look for new rows of data in the database table. Chat applications can appear to be in real time by using javascript techniques known as comet (this will be explained in the client side section). Another technology used for real time messenging is BlazeDS. BlazeDS is a technology from Adobe and works with flex applications and Java, both of these will be covered later.