Software Engineering with an Agile Development Framework/Iteration One/Value proposition
This text from background to Value proposition. Needs lots of work
Use of product: the extent to which interacted with by live user within expected lifespan of product; both frequency and intensity of interaction are considered.
Value of process: the extent to which being involved in the process generates follow-on business value (to both client and institution).
Quality of work: quality of produced product or process.
Working Product – installation plan and user manual should be on user plan and due dates, installation must be working and ready Testing: being rigorous about your testing, getting other people to use with without your intervention test cases, automated testing, a good thing to do. Always have a working product, always have something that is somebody said, “I want the delivery tomorrow thanks” “we have 4 of the functional requirement” “I say scrap it, you have something working” “what wed rather have is working, working, working , not done” Do the nightly build? Don’t bite of more than you can chew in a day, be careful with versions, also aware of continuous integration Use pair programming, 2 people with one keyboard is more productive than 2 separate keyboards Be aware of release planning – you should have on a piece of paper, or whiteboard, what the dates are and what you are delivering on those dates. Get them using the system as soon as possible And lastly, if your not already, use a whiteboard, make all this stuff, they key thing here, make all this stuff visible what they talk about in the book is key metrics, make them visible, write up your functional requirements and a tick them off on a date when they are done or expected to be done, and put them up on the whiteboard
Multiple deliveries
Systems that you are likely to develop in project:
Value proposition borrow text from value proposition paper.
Abstract This paper proposes a value proposition (or earned value) model for considering computing capstone projects with real clients. The value of student industry projects are considered in terms of value of product, benefit of process, and in terms of quality of work. This model is developed from discussion of an assessed value of example projects. Characteristics of projects in different value categories are explored and potential uses of the model discussed. Keywords: capstone projects, computer education, value proposition
1 Introduction Many computing degrees include a capstone project (Fincher and Petre 2001). Chamillard and Braun (2002) argued that “the most critical aspect of the (software engineering/capstone) sequence is the use of real projects, with real customers” (p227). The value of these projects is of interest for several reasons. In the initiation of capstone projects the project size and scope may be specified in course documents in terms of a nominal hypothetical value for the required project size and complexity. At the end of a project, the value may have a role in assessment (eg Mann and Smith 2005 describe a 80% weighting on deployment and implementation with a threshold for assessment of attaining “client satisfaction”). The value of a project can also be seen to have importance in development. Cockton (2004) describes value propositions as driver in human computer interaction. On a larger scale, Boehm (2003) describes the role of value in project monitoring and control. A single project may be examined in terms of its potential value, especially with expectations for innovation, and be seen as having potential for developing as business, perhaps in an institution supported incubator (Tidd et al.2001). At an institutional level there is interest in valuing any contribution to industry and community, especially where the claim is for the value of applied research (ie in Pasteur’s quadrant, Stokes’ 1997). The capstone literature is full of claims for the value of individual projects (eg Garrett et al. 2003), for the value of courses Bruhn and Camp’s (2004) “win-win-win” situation for all: 1. The students gain real professional skills; 2. The industry receives useful products; and 3. The faculty successfully engages students in meaningful education that prepares them for transitions from academic theory to industrial practice.” Bruhn and Camp give an example of “one healthcare corporate sponsor reports that one team saved them over $100,000 in consulting services, plus a projected savings of thousands annually in overhead and operational costs”. But beyond such anecdotes of individual projects there is little in the literature regarding the economic value of capstone projects. We argue that the value to the industry is more complex than just this “receives useful products”. We first examine client satisfaction as a means of valuing projects and then attempt to give a monetary value to projects. We then propose an earned value model of considering projects and finally, consider the implications of such a model. 2 Client satisfaction The value to the client is usually expressed as client satisfaction which could be used to calculate a monetary value. Each client may be asked to provide a letter expressing their satisfaction with the project (Figure 1). These letters are a source of pride for the students and many institutions but they are difficult to use for ascribing value of the project to the business. The most obvious flaw is the dual role of these letters – their primary role is a tool in assessment – after working with students for a year, unless the interaction has gone very badly, most clients will try to say positive things (the school report phenomena). A further difficulty is inconsistency of language. Nevertheless, clearly there would be many projects where a positive client response lines up with what we would consider to be a good project. Similarly, a bad project will often elicit a tempered response. Most capstone supervisors will also recognise mismatches of client response and quality of project (“Great project – fail”, or “Terrible project – pass”). 3 Value proposition In accounting, the client satisfaction would be considered in terms of “prepared to pay” Copeland et al. (2000). In this section we examine this “prepared to pay” using the capstone projects described by (Mann and Smith 2004, 2005) as examples. These projects range from websites to complex applications and embedded systems (see full descriptions in Mann and Smith 2004, 2005). A project to develop a remote water monitoring buoy (Richards et al. 2005) has resulted in a business now preparing to sell monitoring buoys for $70,000 each. This business can be clearly valued at several hundred thousand dollars. This is despite not having any significant intellectual property. Potential is also found in projects undertaken for large organisations. In 2005, a project for a major meat company investigated RFID by adding the chips to the labelling system: After this exercise the company is now embarking on a multi-million initiative to convert the production lines to RFID capable. Although the product of this work was RFID in a very small part of the production system, the company found this very valuable “this project has enabled us to obtain a very good understanding of RFID and the knowledge gained will be of much value to us”. A consultant to spend several months working with a company as it explored new technology in this way would cost at least $50,000. Similar examples include the proof of concept of a content management system for an accountancy firm and proving the potential of mobile access to corporate data for a large institution. Some projects result in a tool that the client can directly make money from. An electrical engineering company servicing dairy farms had a need to measure power quality in rural areas. A project team developed a recording voltmeter suitable for use in agri-industrial environments and a software application. This unit is now being hired out at a cost of $200 per day. The engineers could have purchased a system for around $7000 but they are now in a position to manufacture the devices themselves, this. being new business for our client. Many capstone projects are designed to act in support of the business infrastructure. Such infrastructure projects are more difficult to ascribe a value (how much are the checkouts worth to a supermarket?).
 Case study Workflow management system for architectural office
|
|
Group: Dirk Tuinman, and Jason Hasler The project management project was perfectly managed and well appreciated by the client: ""initial indications are that the new EPM system will make the administration of projects easier and more efficient to track, manage and report on, and most importantly, less time consuming".
{{{3}}} |
A workflow support system for an architectural office resulted in measurable savings in time for the business. The system, a hybrid project management system, contacts management system and file management was explicitly developed to meet the legal requirements of an architectural practice.
An event management system (Wade et al. 2004) is a tool that produces graphical images and equipment schedules that assist with communication about event layouts between conference centre customers, staff and consultants. The system quickly became part of the business system, being used to manage 84 major events in the first few months and in active use three years later. Similar systems cost more than $20,000.
Other business infrastructure financial systems include tenancy management systems, an ecommerce sales system for an international clothing company, and an booking/invoice system for a chain of restaurants. Each of these, in active use before the end of the project and servicing a critical business function can be seen to be of high value to the business. Depending on the scale of the system (and business) a commercially developed customised management system could cost anything from $10–100,000. Some business infrastructure projects deliver technical solutions. In 2005 a project for a regional media company delivered the ability to capture and rebroadcast content. Another project, the Museum Object Acquisition System (Garrett et al.. 2003) provided a 3D artefact display solution for a museum which in currently in active use (www.otagomusuem.govt.nz). MOAS replaces an object capture approach that had been costing the museum $1000 per object and not delivering the benefits required. In addition, the museum is still working with the students (now graduates) to market the system itself. For some projects the drivers are non-financial. A rest home management system was driven by changes in health legislation. “I write to express my grateful thanks for allowing Leith House to be involved in the third year project that has produced such fine work. I was very happy working with the three students that were involved with this huge undertaking. They were so professional and thorough in their approach. This programme gives to our business a first class professional care package which actually runs the whole of the staffs’ day, enabling them to better deliver the care in a more structured way”. Also, the Health and Disabilities Act has required that we have a system that documents the outcomes of all actions and there are hundreds of these every day. It has been so difficult in the past to be able to measure and portray to the H&D that we meet their requirements. We now have confidence that we have a superb way of proving that we do meet their requirements and deliver the highest care to our residents. We have now, the tools to achieve great results. I am indebted to your department an am delighted with the excellent result that will be ongoing for many years to come”. For some projects the initiative is the development of a new business. One project, for example, was the development of a platform to support an after school distance tutoring programme. The successful development of the platform was critical to the ongoing business success. In another development, a sports management new business is entirely reliant on the sports contract management system developed as a project. On a less tangible front, projects may be intended to support non-business infrastructure. A race car engine performance monitoring system (Benson et al. 2005) was intended to increase car performance (a commercial but different system retails for $20,000). Similarly, a cricket training device was intended to improve the reaction time of eye muscles as batsman follow high speed deliveries. Such intangible benefits can also be seen in exhibition development (Mann and Smith 2005), a 3D rugby training system and a kiosk for a gold-fields exhibit. It is, unfortunately, difficult to cost these projects. The clients are community based institutions with a limited ability to pay. Many of these developments have wider benefit, Scicards, for example (Goodsir et al. 2005) was part of a wider initiative to promote science to primary age children. In addition to this perhaps, immeasurable, benefit, the publicity surrounding the initiative was extremely valuable to both the client and institution. By the time the project was submitted, the webpage (branded with both organisations) had had 14,000 unique visitors and had received extensive media coverage.
| Case study Small schools cluster infrastructure
|
|
Group: Ruurd Overhoff, Hendry Lees and Ahmed Sagheer
A resource sharing system for small primary schools.
|
Projects supporting school based initiatives and other community projects have had similar outcomes. At the extreme are projects with community benefits in other countries.
The marketing value of the projects is difficult to calculate. Approximately half the projects generate a news item in the regional news media. Several have been covered in national press (MOAS, SciCards, Rest home, power monitoring), one has been the subject of a TV advertising campaign (Fox et al. 2004) and three have attracted national and international print and television (Smarttop, BallCam, eFence).
4 Model
It would be possible to formalise the values ascribed to each project and aggregate these values. This, though, would be a flawed process. In the somewhat idealised section above too many factors have been ignored. The notion of “earned value” (Ergdogmus 2002, and Huang and Boehm, 2005) recognises that the benefits ascribed to a development should be tempered by other factors, in our case, the quality of the work.
We can then, propose a four factor model of earned value for considering capstone projects:
1. Use of product
2. Value of process (to client and institution)
3. Quality of project
4. Pedagogical benefits
The latter, the pedagogical benefits has been widely discussed elsewhere. Each of the remaining factors can be defined as follows: Use of product: the extent to which interacted with by live user within expected lifespan of product; both frequency and intensity of interaction are considered. Value of process: the extent to which being involved in the process generates follow-on business value (to both client and institution). Quality of work: quality of produced product or process.
While recognising that these are not entirely independent measures, we argue that examining capstone projects against these three measures will highlight substantial differences in earned value. In the following sections we explore this earned value model by way of application to the existing project set. 5 Model applied The full corpora of projects (n=102) were assessed according to the earned value model. Each project was classified high/medium/low for each measure. This process was not formalised but done to explore the model. The summarised data are shown in Table 1 and Figures 2 and 3.
Table 1: Summarised Earned Value Proposition Data for Capstone Projects.
Count of Value_quality Use_of_Product Value_of_Process Value_quality High Medium Low Grand Total High High 7 1 1 9
Medium 3 2 5 10 Low 2 2
High Total 10 3 8 21 Medium High 6 2 8
Medium 5 10 9 24 Low 2 1 9 12
Medium Total 13 13 18 44 Low High 4 2 6
Medium 5 12 3 20 Low 1 2 8 11
Low Total 10 14 13 37 Grand Total 33 30 39 102
Figure 2: Table as a datacube (shaded according to frequency light none or <3; medium between 4 and 7; and dark 8 and above, axes low/medium/high).
Figure 3: Key clusters highlighted
Figure 3 shows the datacube with key clusters highlighted. The interaction of the measures can be seen with a dominance of the ordinal, with a reasonably even distribution along it. In the section below we examine the characteristics of key clusters, both the strong (frequent) groups and those that are weak or missing from the corpora.
5.1 High use product
5.1.1 7 High product, high process, high quality This group of projects are the star projects described as exemplars in Mann and Smith (2004, 2005). They are the high quality projects that delivered both product and process benefits for the client. These projects tend to be for repeat clients. Most of these are local government or community institutions (museum, library etc) but the project types are wide ranging. Examples in this group include exhibition developments, an event management system and a 3D object capture system, all of them could be considered total systems that are well packaged. Almost all had an early delivery of functional product. Two slightly lower quality projects achieved the same outcomes in product and process, but without spark.
5.1.2 6 High product, medium process, high quality
A second group of projects had high value products but the clients probably did not get as much from the process itself. The common thread in these projects is a slightly distant client (emotion rather than distance): an accounting system was developed for a client who was instructed by head office to deploy such a system, a school technician was told he was having a project done for him, an academic stood in for an absent colleague, and so on.
| Case study Compuletics
|
|
Group: Steve Griffith, Lisa Seuseu,
Projects might include significant event management.
|
5.1.3 5 High product, medium process, medium quality
This group can be characterised as having a keen client with clearly scoped project and the project team got away with slightly lower quality of work. These are mainly web-database systems but with some back-end application processing (cf just data i/o) or more complex display or interactivity (eg spatial). Only two projects got away with being of very low quality but still resulted in a highly useful product. One of these was working with an education development – deficiencies were overshadowed by excited children, the other, the development of a database to support homestay accommodation – although poorly designed and implemented – anything would have been an improvement on the non-functional paper system.
5.1.4 9 High product, low process, high or medium quality These projects have high product high use despite little involvement of client in the development process. They tend to be projects with tightly defined functional requirements at outset and tight simple solutions. Seven of these projects involved electronic or microprocessors developments. Only one project managed high product with low process despite low quality (gaming house). This for a client so desperately in need of help that anything would be beneficial, the product developed was functional but it was poorly written, had poor design etc.
5.2 Medium product use
5.2.1 3 Medium product use, high value process, high or medium quality
Only three projects fall into this category. These are projects for which the major benefit for the client is in the process. The actual product may be a little disappointing. Two of these were educational infrastructure projects, the third a sports training simulator. For all, the product is in actual use but the far greater benefit to the client was the increased understanding of their own needs and/or community involvement in the development process.
In the case of the 3D rugby decision simulation, while the product was actively used for a three month period during development, it was not packaged in such a way as to allow extensive further use. The improved understanding of their own business (sporting) context has had great benefit to the client who is now leading the development of an integrated system for the national union.
5.2.2 3 Medium product use, medium value process, high quality. Only three projects fall into this category of being considered high quality products but only reaching medium product and process value.
One of these was a project management system that the group scoped down during development to a relatively small tool. This superbly developed tool was perhaps too elegant for the client who, expecting complexity, clung to existing systems and failed to use the tool to its full potential. An almost identical scenario can be seen for a tourism familiarisation tool that was too elegant for its own good. One excellent project has only had medium use and had little process benefit, halfway through the project the client decided to buy the expensive alternative commercial product with less features. The group carried on to complete the project.
These projects could perhaps be seen as slight overkill, the academic imperative of excellence setting a higher standard than was needed for the industrial reality.
5.2.3 10 Medium product use, medium value process, medium quality. This large group of projects could have been much more exciting. Medium quality work turned them into workman-like rather than their exciting potential. These are mostly web-database systems that we could call content management systems, but in reality are dynamic websites that are somewhat light on functionality and content. For several, the missing factor was adequate testing prior to deployment so that while in use, some features are not working properly, meaning the system’s ongoing utility is limited. A further nine projects are low value in process and only had medium uptake of products. These are largely adequate projects but again, they didn’t quite live up to expectation. In this group are several eCommerce websites that, while functional, did not quite make it to being fully integrated.
5.3 Low product use
5.3.1 Low product use but high quality Only three projects here deemed of high quality. One had high process value; although the project originally intended a development stage, the analysis became the focus of the project. It is perhaps not surprising that with an emphasis on implementation and deployment in assessment, this is the only ‘process project’ The two high quality projects with low product use and low process value can be considered as missed opportunities. Both of these are excellent technical developments (and both won external awards) but we failed to capitalise on the developments.
5.3.2 7 High process value, medium and low quality
These are projects that despite a lack of use of the product and varying quality of work, can be seen to have been of high value to the client. In most cases the client went on to develop products using ideas developed in the project. For all of these the original intention was a working product but most finished up being “first-failure call it prototype 1”. Despite being apparent failings, some of these projects have had significant impact on the client’s business. The electric fence data network, for example, was a long way off “product” but has lead to substantial development income for the client. We have tried in recent years to avoid projects that might be seen as failed developments such as these, rather we have recast them in early stages of development as having a product: that being an intentional prototype (or series of prototypes) to answer specific questions.
5.3.3 18 medium process, medium/low quality These are project for which no product was produced but there were still some benefits to the client. Some have made a business pathway clear, sometimes that this is in an area worth investing in, in others, an area or technical approach they wish to avoid. Strangely perhaps, this group contains several intentional prototype projects. It seems that when we switch focus to a prototype development, a higher (or at least different) set of requirements become apparent. While the required experimental approach might be understood by academics, in particular that a well designed experiment with negative results is better than a poor experiment with apparently positive results, this approach has not been well adopted by students.
In one case a group failed to understand the effects of scale on perception for a set of reaction time training lights. In another, a GIS/GPS development got bogged down in a tangential technical area but missed the overriding question about utility initially posed by the client. Several projects took simply too long to reach a first prototype stage – a stable platform that would have allowed testing of concepts. Sometimes a macho attitude towards the use of tools such as phidgets (Greenberg and Fitchett 2001) may be to blame here with students instead struggling to program in assembler or low level tools. It is interesting that some of the most innovative and media friendly projects are in this category.
5.3.4 11 Low process, medium and low quality It is difficult to see benefits to clients for this category at the opposite end of the spectrum from the “star projects”. In some cases the only benefit is in the 4th dimension, the pedagogical benefits, but for most these projects are not successful. These projects have little in common in terms of complexity, type of project or scope. They do, however, mostly (9/11) share a characteristic of not having a “real client”, instead having internal clients or Chinese-wall structures. 6 Discussion The value of projects is likely to become an increasingly important aspect of capstone projects. The earned value model may be of use in each of the various stages of each capstone project. In the initiation stage, the intended positioning of the project on the model could be used in communication between client, students and supervisors. It is hoped that this positioning will provide a common understanding of the benefits of the proposed development. At the end of the project, a positioning on the model might aid in assessment. This would clarify the contribution the work has made and make explicit any claims made as to product value. The awkward “client satisfaction” can be usefully disaggregated into product and process. The act of positioning one’s own project on the model may be a useful catalyst in the reflective process for students. During development the intended position on the model may be useful in determining direction for the project. This may be particularly the project is (by design or accident) becoming the development of a prototype. The characteristics of previous projects in this category highlight a fine line between value and situations where the work involved outweighs benefits to the client. This work has highlighted that we do need to be cautious about claims for value of end product. It is too easy to claim benefits on the basis of what the product might be able to do, any attempt to place a monetary value on projects (individually or in aggregate) should carefully take into account the earned value, that is the quality of the projects and the separately costed benefits for product and process. A useful area of further research would be to develop costing questions and equations for the different value categories. At a wider level the distribution of the projects on the model raises management questions. Clearly we would want all projects to fall in the top right – generating high value to clients in process, product and the academic stamp of quality, but equally clearly; most projects fall short of this goal. We can and should ask ourselves what factors drive projects down on one or more axis? One factor is the choice of projects, perhaps sub optimal from client’s perspective. Choices made for pedagogical benefits reduce efficiency. The technical complexity requirements of a project (ie we don’t give credit for typing) may conflict with the desire of client who wants a webpage – instead we insist on developing a content management system (sometimes less than successfully). Another consideration is the assessment of ongoing value. The model has helped identify some projects that have missed their potential. Initiatives to develop innovation processes involving appraisal of product portfolios could use a model such as this to identify potential products for commercialisation. We are not all content with the cluster at the bottom left. While some of these projects may have been suitable learning experiences for the students, there is a significant potential damaging effect on community relations. We should ensure that where clients are involved, is at least medium value for product or more likely process for the client – this will have impact on the choice of project. Fortunately, or perhaps it was a contributing factor, most of these poor projects did not have a direct client relationship. This model also leads to consideration of what are we looking for in projects. Most capstone courses attempt a balance of product and process in teaching (Clear et al 2001), a model such as this may help in identifying alternative approaches. 7 References Benson, A., S. Rao, R. McLean, J. Reid and S. Mann (2005). Race car racing characteristics. 18th Annual Conference of the NACCQ, Tauranga, NACCQ.341 Boehm, B. (2003). “Value-based software engineering.” SIGSOFT Softw. Eng. Notes 28(2): 4. Bruhn, R. E. and J. Camp (2004). “Capstone course creates useful business products and corporate-ready students.” SIGCSE Bull. 36(2): 87-92. Chamillard, A. T. and K. A. Braun (2002). The Software Engineering Capstone: Structure and Tradeoffs. Proceedings of the 33rd SIGCSE technical symposium on computer science education, Cincinati, Kentucky.227-231 Clear, T., F. H. Young, M. Goldweber, P. M. Leidig and K. Scott (2001). “Resources for instructors of capstone courses in computing.” ACM SIGCSE Bulletin 33(4): 93-113. Cockton, G. (2004). From quality in use to value in the world. CHI ‘04 extended abstracts on Human factors in computing systems. Vienna, Austria, ACM Press: 1287-1290. Copeland, T., T. Koller and J. Murrin (2000). Valuation: measuring and managing the value of companies, John Wiley.512 Erdogmus, H. (2002). “Value of learning options in software development under private and market risk.” Engineering Economist 47(3): 308-353. Fincher, S., M. Petre and M. Clark, Eds. (2001). Computer Science Project Work: Principles and Pragmatics. London, Springer. Fox, A.-M., L. Takau, S. Yuan, P. Haden and S. Mann (2004). Fish n Clicks. Proceedings of the 17th NACCQ, Christchurch, NACCQ.492 Garrett, P., D. Youngman, J. McCormack, C. Rosescu and S. Mann (2003). Characteristics of success - virtually there. Proceedings of the 16th Annual NACCQ.269-272 Goodsir, K., A. Douglas, S. Holo, A. Mann, A. Sewell, L. Smith and S. Mann (2005). SciCards. 18th Annual Conference of the NACCQ, Tauranga, NACCQ.352 Greenberg, S. and C. Fitchett (2001). Phidgets: Easy Development of Physical Interfaces through Physical Widgets. Proceedings of the ACM UIST 2001 Symposium on User Interface Software and Technology,, Orlando, Florida., ACM Press. www.cpsc.ucalgary.ca/grouplab/papers/ Huang, L. and B. Boehm (2005). Determining how much software assurance is enough?: a value-based approach. Proceedings of the seventh international workshop on Economics-driven software engineering research, St. Louis, Missouri, ACM Press.1-5 http://doi.acm.org/10.1145/1083091.1083095 Mann, S. and L. Smith (2004). Role of the development methodology and prototyping within capstone projects. Proceedings of the 17th NACCQ, Christchurch, NACCQ. 119-128 Mann, S. and L. G. Smith (2005). A+, Guaranteed: Insisting on best of practice within capstone projects. Proceedings 18th Annual NACCQ, Tauranga., Proceedings 18th Annual NACCQ.243-248 Mann, S. and L. G. Smith (2005). Exhibiting reality: collaboration in practice. Proceedings 18th Annual NACCQ, Tauranga., Proceedings 18th Annual NACCQ.65-74 Stokes, D. E. (1997). Pasteur’s quadrant: basic science and technological innovation. Washington DC, Brookings Institute Press.196 Tidd, J., J. Bessant and K. Pavit (2001). Managing Innovation: Integrating technological, market and organisational change. Chichester, John Wiley.338 Wade, D., L. Roger, A. Sewell and S. Mann (2004). Event Layout Design System. 17th Annual NACCQ, Christchurch.538
Case study
edit| Case study Scales labelling system
|
|
Group: David McDonald, Chris Lee, Ian Simpson for Wedderburn Scales
This group showed that projects don't have to be "sexy" to achieve client satisfaction. The team took a process that was labour intensive and prone to error and made an elegant solution.
|
| Case study VirtualDub
|
|
Group: Nathan Latton
A project may be a small part of another project. The Virtual Dub system developed by Nathan Latton provided video stabilisation services for another project - Ballcam..
|
| Case study Scicards
| ||||||||||||||||||||||||||||||
|
Group: Keryn Goodsir, Andrew Douglas and Sheila Holo for Otago Museum
When we took on the Scicards project the client was already committed to going live with the system in less than a month. The value proposition and the order of development was critical to the success of this project. The effect of this was that between 29th April and 31 October 2005 when the project was finished, the site had already had more that 14,000 unique visitors, 2855 on one day that the site featured on national television. This responsive and robust delivery was matched by a strong focus on the needs of the users, bourne out by feedback:
 The project was divided up into three different release dates in April, July and September. 2005. Each release consisted of five different cards some of which linked to online activities on the website. The group's role was:
We designed the content for all of the above, and contracted the artwork to an illustrator as per our specification.
Countless hours were spent establishing a stable platform for our first release which was due approximately four weeks after our initial project meeting. Our stable platform was a prototype with a database connection to the local server BITDEV at Otago Polytechnic, which was successful and helped us in further testing before we deployed it. The stable platform involved building an Information System that was used to collect user information and their respective cards. Once this was completed we concentrated on creating the content of the website. This entailed many brainstorming group sessions and resulted in storyboards used to illustrate our ideas for the ‘look and feel’ of the website. The storyboards were approved and discussed with the client and the illustrator prior to illustration. These were supplied disjointedly, due to the illustrator having other commitments. Within two weeks of the release date we received some of the illustrations, others only came days before the release date. One huge factor to this was that the client changed the release date to earlier. Due to the time restriction we had to sit down with the client and prioritise which components of the website were the most important. Functional Requirements for the First Release are as follows: The system as implemented does:
The Hair Activity, for example was designed to encourage young scientists to think about specific ingredients in hair products. The user applies the products and the hair reacts according to the hair type. In the shoe activity, the users examined the functionality of the components of a shoe. Including the different compounds that make up the components of a shoe and how different components apply to different sports/activities. The Sport Activity enabled users to learn about gravity and action through the trajectory of projected objects. Demonstrated by catching interesting objects. The Collector’s Book System is where users can collect and store their virtual cards. Users can view pop-up facts as they collect each card. Linking and arranging the cards in a special way led to rewards during the year. We delivered a fully functional system to the client on the 29th April 2005 meeting all requirements stated above. This set a precedence for the rest of the project and showed that we were competent and committed to meeting the client’s requests. The first release was performed under intense time constraints. In the second stage, decisions were made to ensure a robust system that would provide durability. After much discussion with the client regarding the longevity of the project, long-term in-house management and the possibility of extending the life of SciCards Online we undertook some investigation and recommended adopting a commercial provider and recommended GeneratorWEB as the long term solution. The system required a stable platform and an actively maintained database which we were unable to provide at the end of the project. Mike Hodges of GeneratorWEB was contracted at this point in time to allow for the compatibility of the components developed by us with regard to GeneratorWEB. Now with a new management system, a whole new set of functional requirements was required. Our main objective was to concentrate on the development of the content of the website, and we also had to assist in the transition to GeneratorWEB by amending our files from the First Release. Mike Hodges was able to use the database developed by us. Requirements for the Second Release – fulfilled to client’s satisfaction
A special reward animated the Sports Card. Upon entering the Sports Card into the Collector’s Book, the card came alive! The reward system was initiated to encourage users to add their virtual cards to their Collector’s Book and complete activities. Third Release was 1st September 2005 Requirements for the Third Release – fulfilled to client’s satisfaction
Upon completing the Travel Activity, a secret Code is revealed – when entered into the users’ Collector’s Book the cycling character rides his bicycle around the book.
We are proud of our project and how we have handled the challenges we faced. SciCards Online has been a monumental success, including television appearances, newspaper articles and positive feedback from all over the country. The expectations throughout the project were extremely high and the pressure was felt by everyone involved. SciCards Online has been up and running since 29th April 2005 (First Release), and has been robust and consistent throughout the year. The database records as well as website statistics prove that the system has been in use since the first release. We believe that starting our project immediately, with early deliverables required us to be extremely organised in our approach to project management. Documenting everything as it happened also was a great tool for keeping track of the project’s progress – being able to look back at what we had written helped us understand exactly what was going on at that point in time. Approximately 80% of the time working on our project was spent working together – we feel this worked well for us, as we always knew what each other was doing, where we were at and how much we had to go. Fortunately there was no group conflict. Throughout our project we were always aiming for 110% we wanted to be the best we could be, and be proud of ourselves at the end. We each believe that we have done very well, to accomplish this much from where we started. Our Third Year Project has prepared us for “the challenges that lie ahead” by equipping us with the necessary skills to manage projects, deadlines and client relations. These are all skills that we will use in the future.
| ||||||||||||||||||||||||||||||
