Here's an example of my php code which I will be using as the basis for my final feature later on in the project:
Wednesday 28 February 2007
Testing Feature...
I have started thinking of tests for my feature. I have posted my version on the discussion board to get more ideas from the other group members.
Test Number
Feature/Test Description
Test Data
Expected Outcome
Actual Outcome
Additional Steps Taken
1
Payment Button
Other Features on the page. To Test to see if information is carried across to payments page.
All the information collected from the other features should be transferred across to the payments page.
2
Payment Button
Hyperlink to payment page
Should open the payment page.
Test Number
Feature/Test Description
Test Data
Expected Outcome
Actual Outcome
Additional Steps Taken
1
Payment Button
Other Features on the page. To Test to see if information is carried across to payments page.
All the information collected from the other features should be transferred across to the payments page.
2
Payment Button
Hyperlink to payment page
Should open the payment page.
To see the tabled layout, see the discussion forum.
Test Number
Feature/Test Description
Test Data
Expected Outcome
Actual Outcome
Additional Steps Taken
1
Payment Button
Other Features on the page. To Test to see if information is carried across to payments page.
All the information collected from the other features should be transferred across to the payments page.
2
Payment Button
Hyperlink to payment page
Should open the payment page.
Test Number
Feature/Test Description
Test Data
Expected Outcome
Actual Outcome
Additional Steps Taken
1
Payment Button
Other Features on the page. To Test to see if information is carried across to payments page.
All the information collected from the other features should be transferred across to the payments page.
2
Payment Button
Hyperlink to payment page
Should open the payment page.
To see the tabled layout, see the discussion forum.
Tuesday 27 February 2007
Draft Features Spec + Other Issues
Myself, Richard Gibbons and Rob Morrisby are currently putting together the draft copy of the document. It is going OK, however there are certain issues that have crept up. For example people who have not got a feature need allocating one. We have resolved this by splitting up the features, after we have talked with the people it affects. Maybe for the future it might be handy for everyone to know the format, IE text etc for the final copy so that it makes putting together a lot easier. From the lecture today, we also need to add a project plan and testing. I think this can be a separate section on to the current proposal, composing of a few tests for every ones feature. I will be suggesting this on the forum, so that we can implement this for the final copy.
We need to create a project plan composing of who needs to be doing what during the next 3 weeks. I have created a template, and so far everyone has signed up to it. The project plan should be complete within the next couple of days. Included on that same thread is a list of all the features and allocated rooms, which Jennie Bate will be matching names with the features shortly.
I will be creating a separating Testing thread, which could work in the same way as with the feature documentation, it should be straight forward then.
For my demo on Thursday, I have produced a prototype of how my feature may work, it should be enough for me to get feedback on and shows how it interacts with other features.
One final note is that a lot of the people have not resubmitted their improved feature so we have decided to just submit the one they submitted originally. I have posted a lot of threads on the discussion forum, the majority of people replied how ever a few didn't.
We need to create a project plan composing of who needs to be doing what during the next 3 weeks. I have created a template, and so far everyone has signed up to it. The project plan should be complete within the next couple of days. Included on that same thread is a list of all the features and allocated rooms, which Jennie Bate will be matching names with the features shortly.
I will be creating a separating Testing thread, which could work in the same way as with the feature documentation, it should be straight forward then.
For my demo on Thursday, I have produced a prototype of how my feature may work, it should be enough for me to get feedback on and shows how it interacts with other features.
One final note is that a lot of the people have not resubmitted their improved feature so we have decided to just submit the one they submitted originally. I have posted a lot of threads on the discussion forum, the majority of people replied how ever a few didn't.
Thursday 22 February 2007
Systems Integration...
I will be creating a new thread, with these questions that need to be considered:
What Hardware do we need?
What Software?
How long will it take?
Deadlines?
What facilities are available?
The above questions are just a starting point, but we need suitable ideas for the demonstration next week.
What Hardware do we need?
What Software?
How long will it take?
Deadlines?
What facilities are available?
The above questions are just a starting point, but we need suitable ideas for the demonstration next week.
Proceed to Payment Feature...2
With every ones feature may only require a certain amount of coding, it is still important to decide on how to do it and also how it will link with the other features for the system. My designs have stated that it will gather all the information collected by the features on the same web page as mine and pass it on to the payment section.
In terms of the demo next week, I may just decide to talk through what I will want to achieve with my feature, rather than just demonstrating pushing the button. As well as the link to the payments page, there will be a lot of php coding which will include the use of sessions and other functions available.
In terms of the demo next week, I may just decide to talk through what I will want to achieve with my feature, rather than just demonstrating pushing the button. As well as the link to the payments page, there will be a lot of php coding which will include the use of sessions and other functions available.
Current Update of SB2
With our last meeting held on Tuesday. SB2 has taken another major turning point. The way we have to work and meet deadlines has changed considerably. As well the design and implementation of our individual features, we now have to consider other roles to take on in order to make this project a success. This roles will include Design of the database, IE layout, Systems Integration, Database Structure, Testing and Marketing and Finance.
I will be helping to get our cohort's final proposal put together in the next week, as a representative for Consortium B. In terms of the new roles I will be part of the group that helps with the System Integration.
For the demonstration next week, we need to decide on what we want to achieve at that stage of the product, again this will need to be discussed on the discussion boards first. Also I presenting my feature to which is the proceed to payment button.
I will be helping to get our cohort's final proposal put together in the next week, as a representative for Consortium B. In terms of the new roles I will be part of the group that helps with the System Integration.
For the demonstration next week, we need to decide on what we want to achieve at that stage of the product, again this will need to be discussed on the discussion boards first. Also I presenting my feature to which is the proceed to payment button.
Friday 16 February 2007
Cohort Spec...
As a Cohort we have to produce a series of diagrams and models to show our system. I have proposed the following on the discussion board:
As a cohort we need to get these things done, Any volenteers?
Web design – site maps/menu maps – the structure of the website.
Style Guide - colours, fonts, button shapes, text size, page layout etc etc.
Storyboards/wireframes.
Use Case models (with Use case descriptions) can provide information about the functions of the system.
Entity relationship model to help to design the database.
Requirements Catalogue to provide a list of prioritised requirements.
Point B needs to be decided on quickly so that the whole cohort knows how to redesign their features.
We could split this up between the 3 consortiums again, Or have 6 different threads for the points above so everyone can get involved and add their own ideas. What does everyone think?
As a cohort we need to get these things done, Any volenteers?
Web design – site maps/menu maps – the structure of the website.
Style Guide - colours, fonts, button shapes, text size, page layout etc etc.
Storyboards/wireframes.
Use Case models (with Use case descriptions) can provide information about the functions of the system.
Entity relationship model to help to design the database.
Requirements Catalogue to provide a list of prioritised requirements.
Point B needs to be decided on quickly so that the whole cohort knows how to redesign their features.
We could split this up between the 3 consortiums again, Or have 6 different threads for the points above so everyone can get involved and add their own ideas. What does everyone think?
Features Revised...
I have redone my features according to the guidelines. The image is the same, however I have made changes too.
Justification of Design:
The above design of the button should be in relation to the overall web systems theme. The size of the button should be noticeable and users should be able to identify what the function of the button is by reading the text on the button. The above design may change slightly depending on the final decided layout as a cohort which is yet to be decided.
Functionality/Interaction with other Features:
To store all the information entered or selected in the following fields:
Customer ID
Event ID/Name
Type of Ticket
Price of Ticket
Quantity
Date of Event.
Once the “check out” button is pressed it will save the above information so that it can be calculated on the payments page. It can be designed so that once the button is pressed it calculates the total straight away, or it can just transfer the information on to the Payments page.
This button’s main function is too collect all the information from the following features which are on the same page, they include:
Search Criteria
Quantity of Tickets
Those features will contain information regarding the event name, time, price of ticket and quantity of tickets. This information is vital, as it is needed for the next page.
Implementation:
I would use xhtml and PHP to implement the design of this feature. PHP can be useful with its Session and Cookies feature too, for example so that it can remember existing users. A database created using SQL can be used to store the information entered into the fields. The button could also be used as a validation tool, for example it cannot proceed unless all the required fields are filled in.
Justification of Design:
The above design of the button should be in relation to the overall web systems theme. The size of the button should be noticeable and users should be able to identify what the function of the button is by reading the text on the button. The above design may change slightly depending on the final decided layout as a cohort which is yet to be decided.
Functionality/Interaction with other Features:
To store all the information entered or selected in the following fields:
Customer ID
Event ID/Name
Type of Ticket
Price of Ticket
Quantity
Date of Event.
Once the “check out” button is pressed it will save the above information so that it can be calculated on the payments page. It can be designed so that once the button is pressed it calculates the total straight away, or it can just transfer the information on to the Payments page.
This button’s main function is too collect all the information from the following features which are on the same page, they include:
Search Criteria
Quantity of Tickets
Those features will contain information regarding the event name, time, price of ticket and quantity of tickets. This information is vital, as it is needed for the next page.
Implementation:
I would use xhtml and PHP to implement the design of this feature. PHP can be useful with its Session and Cookies feature too, for example so that it can remember existing users. A database created using SQL can be used to store the information entered into the fields. The button could also be used as a validation tool, for example it cannot proceed unless all the required fields are filled in.
Thursday 15 February 2007
Functional Specification/Outline Design...3
After clarifying what needed to be done for Wednesday 28th March, I have suggested the following on the discussion board:
From what melanie said this morning, what we have currently produced is fine. Just need to make sure that our names are on there. In addition we need some sort of working prototype and I suggest that we create a html page(s) (for each group) of our features on there. The functionality will be limited but we can do simple things like linking the pages together.
I know alot of people will not be here next week, but I was thinking that if we can meet and create the html site, and maybe a few of us do the demonstrations next week, it will take the pressure of the next demo on Thrs 1st March.
Then overall as a consortium we can create use case diagrams and site maps to show how everything fits in.
What does everyone think?
From what melanie said this morning, what we have currently produced is fine. Just need to make sure that our names are on there. In addition we need some sort of working prototype and I suggest that we create a html page(s) (for each group) of our features on there. The functionality will be limited but we can do simple things like linking the pages together.
I know alot of people will not be here next week, but I was thinking that if we can meet and create the html site, and maybe a few of us do the demonstrations next week, it will take the pressure of the next demo on Thrs 1st March.
Then overall as a consortium we can create use case diagrams and site maps to show how everything fits in.
What does everyone think?
Wednesday 14 February 2007
Functional Specification/Outline Design...2
I have posted the following, with a basic use case diagram.
Yea it looks like the login only. The logout feature is somthing everyone can use on their page once the user has logged in. Also we need to decide on how the site is going to work. For example is the user going to log in first, then decide on which section to go to, for example is he or she going to make an event, record an event or attend an event? Are we going to have a home page which will link to the login page but also show the current events along with any advertising features?
I think how the features are split up are ok and we can decided in our individual consortiums as to who is doing what. I think consortium A should do the login feature, but now we could have an extra home page feature too.
Enclosed in this thread is a basically use case and site navigation diagram. What does everyone think?
The use diagram is on the discussion forum, because i can not upload it on here.
Yea it looks like the login only. The logout feature is somthing everyone can use on their page once the user has logged in. Also we need to decide on how the site is going to work. For example is the user going to log in first, then decide on which section to go to, for example is he or she going to make an event, record an event or attend an event? Are we going to have a home page which will link to the login page but also show the current events along with any advertising features?
I think how the features are split up are ok and we can decided in our individual consortiums as to who is doing what. I think consortium A should do the login feature, but now we could have an extra home page feature too.
Enclosed in this thread is a basically use case and site navigation diagram. What does everyone think?
The use diagram is on the discussion forum, because i can not upload it on here.
Tuesday 13 February 2007
Functional Specification/Outline Design...
I will be suggesting the following for this part of the project:
From that lecture it seems that there are a few features that have been repeated and need resolving. I propose the following:
Each group (1-7) has a Rep. the Rep can then collect all the designs for their group.
Also maybe a consortium rep too, this might not be needed however it will split up the workload. This person can be in charge of collecting all the designs for all the 3 groups. Depending on how each consortium has delegated the features, this may not be necessary.
Then we need a few people or person to put the final document together. Any volunteers?
Once we have decided on the above, each group needs to submit their features that they have just handed in so we can see where the duplicates are, and then re-organise to see who does what. If we can split up each section by consortium, then by group as we previously did.
So we need to decide as a whole, what features we have got and then take it from there. I think it is important we decide on group/consortium reps so everyone knows who to submit their work too and so that there is not any duplicates.
As a starting point we can use this thread to let everyone know who the reps are, and to post the features.
Obviously what I have suggested is not the only way, what are other people’s suggestions?
Functional Specification/Outline Design for system
I am not sure what we need to do for this, but if you think about it we have got 2 weeks to do it.
We have to create a mind map, if we split this up into 3 parts, Make, Attend and Record Event. I suggest that the 3 group reps together do this, as they will have an overview of who has done what.
The draft for the functional and outline design part I think is a more detailed approach to what we have done. For example as well as what it will look like, but maybe some example code and how it will all fit together.
A draft is in by Monday, so it does not have to be complete. Again any suggestions?
I think the above is possible, once we are properly organised. However I think we need to use our time a lot better instead of leaving it until the last minute.
From that lecture it seems that there are a few features that have been repeated and need resolving. I propose the following:
Each group (1-7) has a Rep. the Rep can then collect all the designs for their group.
Also maybe a consortium rep too, this might not be needed however it will split up the workload. This person can be in charge of collecting all the designs for all the 3 groups. Depending on how each consortium has delegated the features, this may not be necessary.
Then we need a few people or person to put the final document together. Any volunteers?
Once we have decided on the above, each group needs to submit their features that they have just handed in so we can see where the duplicates are, and then re-organise to see who does what. If we can split up each section by consortium, then by group as we previously did.
So we need to decide as a whole, what features we have got and then take it from there. I think it is important we decide on group/consortium reps so everyone knows who to submit their work too and so that there is not any duplicates.
As a starting point we can use this thread to let everyone know who the reps are, and to post the features.
Obviously what I have suggested is not the only way, what are other people’s suggestions?
Functional Specification/Outline Design for system
I am not sure what we need to do for this, but if you think about it we have got 2 weeks to do it.
We have to create a mind map, if we split this up into 3 parts, Make, Attend and Record Event. I suggest that the 3 group reps together do this, as they will have an overview of who has done what.
The draft for the functional and outline design part I think is a more detailed approach to what we have done. For example as well as what it will look like, but maybe some example code and how it will all fit together.
A draft is in by Monday, so it does not have to be complete. Again any suggestions?
I think the above is possible, once we are properly organised. However I think we need to use our time a lot better instead of leaving it until the last minute.
Sunday 11 February 2007
Features Continued...3
We are all on task with only a couple of group members left to do their designs. This week has not been too bad once the tasks were split up. I think as a group we all have a good idea as what we need on our section.
I have decided to put all our groups work together again and for the consortium depending on where the other two groups are at.
I have decided to put all our groups work together again and for the consortium depending on where the other two groups are at.
Wednesday 7 February 2007
Proceed to Payment Feature...
I have come up with the following for the proceed to payment feature.
Design:
The colour or theme of the button is yet to be decided and is not important at this stage of the development.
Functionality:
To store all the information entered or selected in the following fields:
Customer ID
Event ID/Name
Type of Ticket
Price of Ticket
Quantity
Date of Event.
Once the “check out” button is pressed it will save the above information so that it can be calculated on the payments page. It can be designed so that once the button is pressed it calculates the total straight away, or it can just transfer the information on to the next page. It will also open the payments page where it will contain a summary and total of all of the above.
Implementation:
I would use xhtml and PHP to implement the design of this feature. PHP can be useful with its Session and Cookies feature too, for example so that it can remember existing users. A database created using SQL can be used to store the information entered into the fields.
Functionality:
To store all the information entered or selected in the following fields:
Customer ID
Event ID/Name
Type of Ticket
Price of Ticket
Quantity
Date of Event.
Once the “check out” button is pressed it will save the above information so that it can be calculated on the payments page. It can be designed so that once the button is pressed it calculates the total straight away, or it can just transfer the information on to the next page. It will also open the payments page where it will contain a summary and total of all of the above.
Implementation:
I would use xhtml and PHP to implement the design of this feature. PHP can be useful with its Session and Cookies feature too, for example so that it can remember existing users. A database created using SQL can be used to store the information entered into the fields.
Features...Continued 2
Jennie has came up with 7 features which I agree on and the allocated work load seems fair. I will be designing and creating the proceed to payment button which will be linking this to group 7s page. First thoughts are to maybe use php for recording all the information from the various text fields and drop down menus and also calculating the total ticket price.
Tuesday 6 February 2007
Features Continued...
I have suggested the following which I have posted on the discussion board. I think it might be a good idea to each member of the group having separate sections, allowing them to decide on what to go into it.
Choose Event Name:
This feature allows you choose the event name you want to attend. It links to the event database which has all the event info below. This will contain name, location etc.
Search:
This feature allows you to search the event database
Quantity:
This allows the user to select how many tickets etc they want. Drop down menu?
Proceed to payment:
This feature allows the user to proceed after they have selected the event they want to attend. Maybe just a button?
Attending status:
This feature allows the user to select there status, attending, maybe attending or not attending Drop down menu?
We need to decide on any other features and how they are going to work. Seeing as there are 7 of us in our group, if we can think of two more features then there will be one each. Once we have done that need to decide on an overall layout. Within these sections the individual can decide on what buttons are needed and so on, but is that going to be too much work?
What does everyone think?
Features...
We basically now have to split up individually design features for the system. I am going to suggest that we stick to these original groups we did for the proposal:
Login/Register - Group 1
Event - Group 2
Payments - Group 7.
Each group will then split up the features between them. We need to decide as a whole group on the theme and remove any repeated features, however i do no think there is any. There will have to be a similar layout.
Login/Register - Group 1
Event - Group 2
Payments - Group 7.
Each group will then split up the features between them. We need to decide as a whole group on the theme and remove any repeated features, however i do no think there is any. There will have to be a similar layout.
Monday 5 February 2007
Consortium B Final Proposal...
I will be putting all the 3 parts of the proposal together and submitting it later on today. It has been hard doing this, this week because of the other assignments due in. I will be posting a final copy on the discussion forum before I submit it.
Friday 2 February 2007
Implementation - Events Management Proposal
We have split up the tasks into pairs. I have worked with emily on the hardware and software aspect for the proposal including implementation too. This is what we have suggested:
Implementation
For the creation of the features such as drop down menus selecting the events, quantity of tickets, type of ticket (child or adult), date/time (Calendar), storing events and designing a template layout of styles (fonts) we can use the below languages:
Xhtml/CSS – creating the basic site
PHP – recording sessions and user input.
JavaScript - Data Validation
SQL – Storing event recordings.
The overall theme for the software should be consistent through out the website including the navigation setup.
Software:
For the above we could use the following:
Text pad, Notepad
Dreamweaver – creation of buttons and forms
Oracle (SQL)
Any other available compiler for java. For example Netbeans or JGrasp.
Adobe Photoshop/Elements for editing of images and video clips.
Hardware:
We will have one server to store all of the above. It should have the following specifications:
Xeon Dual Core Processor 3200
2GB DDR2 RAM – to allow multi-tasking. For example allowing simultaneous modifications to the server.
500 GB Hard drive space – to store all the software.
Keyboard/Mouse – for user input.
Price range £200.00
Client machines will actually implement the software will include:
Intel Core 2 Duo Processor 1.8Ghz
1 GB DDR RAM – to run the above programs
19inch Flat Screen Monitor – to view pictures/movies.
80 GB Hard drive space – to use for a temporary basis.
DVD RW optical drive
Network interface card (NIC) – connect to the server
256 Mb nVidia Geforce Graphics Card.
Keyboard/Mouse – for user input.
Price range around £450.00
The above specifications are only a guideline of what is required. In addition to the above depending on the amount of server and client machines, more networking components maybe required, for example routers and switches.
As mentioned above this is only a rough outline, it will depend on what we want to do later on.
Implementation
For the creation of the features such as drop down menus selecting the events, quantity of tickets, type of ticket (child or adult), date/time (Calendar), storing events and designing a template layout of styles (fonts) we can use the below languages:
Xhtml/CSS – creating the basic site
PHP – recording sessions and user input.
JavaScript - Data Validation
SQL – Storing event recordings.
The overall theme for the software should be consistent through out the website including the navigation setup.
Software:
For the above we could use the following:
Text pad, Notepad
Dreamweaver – creation of buttons and forms
Oracle (SQL)
Any other available compiler for java. For example Netbeans or JGrasp.
Adobe Photoshop/Elements for editing of images and video clips.
Hardware:
We will have one server to store all of the above. It should have the following specifications:
Xeon Dual Core Processor 3200
2GB DDR2 RAM – to allow multi-tasking. For example allowing simultaneous modifications to the server.
500 GB Hard drive space – to store all the software.
Keyboard/Mouse – for user input.
Price range £200.00
Client machines will actually implement the software will include:
Intel Core 2 Duo Processor 1.8Ghz
1 GB DDR RAM – to run the above programs
19inch Flat Screen Monitor – to view pictures/movies.
80 GB Hard drive space – to use for a temporary basis.
DVD RW optical drive
Network interface card (NIC) – connect to the server
256 Mb nVidia Geforce Graphics Card.
Keyboard/Mouse – for user input.
Price range around £450.00
The above specifications are only a guideline of what is required. In addition to the above depending on the amount of server and client machines, more networking components maybe required, for example routers and switches.
As mentioned above this is only a rough outline, it will depend on what we want to do later on.
Events Management Continued...3
I have suggested some ideas for the proposal and posted them on the discussion board. They are as follows:
Looking over the features that myself and Emily has thought of should be ok, our page we are proposing will be limited anyway. Maybe a few more suggestions?
As for the proposal, Looking back at the ones we did back in systems last year we could use the same headings:
User Requirements
Functions of the proposed system (Features)
Hardware
Software (Implementation)
Manual
Test Data
Warranty
Training
Customer Support
Delivery
Price/Cost
Obviously we may not need all of the above, any suggestions? Then we can split the work into pairs again or any other means.
Looking over the features that myself and Emily has thought of should be ok, our page we are proposing will be limited anyway. Maybe a few more suggestions?
As for the proposal, Looking back at the ones we did back in systems last year we could use the same headings:
User Requirements
Functions of the proposed system (Features)
Hardware
Software (Implementation)
Manual
Test Data
Warranty
Training
Customer Support
Delivery
Price/Cost
Obviously we may not need all of the above, any suggestions? Then we can split the work into pairs again or any other means.
Thursday 1 February 2007
Update on Events Management...
With the deadline coming up soon, we have still yet to get anywhere with this part of the task. I think this is mainly because of Systems and programming assignments due in on Monday. I have posted the below on the discussion board to see if any see what people's reactions are to it.
"I know everyone has been busy with programming assignment but we need to talk about how and when we are going to do this part of the task. If we decide on the features soon, we can split the work load and it should not be a lot between the 7 of us, but in doing so we need everyone to post ideas too."
I have been at an interview in Manchester all day today hence I have not had a look at this task, however I will see if there is any change to this tomorrow afternoon then take it from there.
"I know everyone has been busy with programming assignment but we need to talk about how and when we are going to do this part of the task. If we decide on the features soon, we can split the work load and it should not be a lot between the 7 of us, but in doing so we need everyone to post ideas too."
I have been at an interview in Manchester all day today hence I have not had a look at this task, however I will see if there is any change to this tomorrow afternoon then take it from there.
Subscribe to:
Posts (Atom)