Software Engineering with an Agile Development Framework/Print version
 |
This is the print version of Software Engineering with an Agile Development Framework You won't see this message or any elements not part of the book's content when you print or preview this page. |
The current, editable version of this book is available in Wikibooks, the open-content textbooks collection, at
https://en.wikibooks.org/wiki/Software_Engineering_with_an_Agile_Development_Framework
Introduction
Introduction to Approach[edit | edit source]
We are following a development framework that incorporates agile development approaches in a structured framework. (see manifesto, manifesto description, more). Agility implies
- individuals and iterations over processes and tasks
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan.
The focus of the project is on the production of robust working systems (software, hardware and maintenance documentation). Planning, comprehensive development documentation and processes are important but are 'means to an end' with a focus on content rather than format/representation. It is expected that you discard most of the models you develop (although you do have to keep them for assessment!).
We aim, then for the middle ground between Bureaucracy and Adhocracy.
At any one point you should expect to have five interacting streams of work underway. At different times, different streams are more important.
The varying proportions of each stream coalesce into "sectors" defined by a deliverable output, steering and communication with the client.
The sectors here can be seen to resemble a structured development process.
We are going through three iterations. The first iteration is aimed at building understanding within the development group and client. The second iteration is aimed at designing and releasing (to the client) a system that meets many of the functional requirements. The third iteration, "robust delivery" is intended to review the success of the second iteration in meeting business requirements, to review functional requirements (there will probably be more), and to deliver a robust and stylish "bullet proof" implementation.
At any time, you will be working in a sectors made up of the 5 work streams, being one of three iterations and having a focus on a particular area.
Each sector is defined by what it produces. We provide you with a suite of tools that may be used within each sector, but so long as you can provide evidence of a rational process (see evidence portfolio below), we are less concerned with the internals of the sector.
Iteration 1: Understanding[edit | edit source]
| Sector | Deliverables |
| Evaluation | Management document (group established, environmental context) |
| Functional requirements | Interview with client established |
| Design concepts | Ethical design |
| Design specification | System metaphor |
| Implementation | Conceptual prototype (Release One). |
| Evaluation | Proposal to client |
Iteration Two: Functional Delivery[edit | edit source]
| Evaluation | Project estimation |
| Functional requirements | Functional requirements document |
| Design concepts | Design concepts presentation |
| Design specification | Design specification (style guide etc), Stable development platform: The framework for your system should be developed and tested. For example, for a database with a web front end we would expect you to demonstrate connectivity and basic database functions via the web (insert, delete, query, update) plus any standard infrastructure (login etc). |
| Implementation | Functional deliverable (Release Two). Deliver to the client a system that meets most of their needs. This system should be usable and stable |
| Evaluation | Analysis of functional deliverable |
Iteration Three: Robust Delivery[edit | edit source]
| Evaluation | Direction for Iteration 3. Complete Ethical processes. |
| Functional requirements | Revisit functional requirements |
| Design concepts | Design concepts update, Content production |
| Design specification | Style guide, system specification, implementation and deployment plan |
| Implementation | Robust delivery (Release Three) |
| Evaluation | Project evaluation and completion. Client satisfaction. |
Whole process
Principles[edit | edit source]
Prototyping: Build something in order to answer specific question, learn from it and move on.
Client satisfaction
Client involvement
Documentation (and evidence portfolio)
How to read book[edit | edit source]
Sectors {{Adfmetabox |title |Bite |2 hours |Inputs |Evidence |Stakeholders }}
| title |
|
|
5 work streams[edit | edit source]
The rainbow sector diagrams in the book are intended as templates for steering your own project. In the first two iterations we have linked the boxes, in the third iteration the sectors are blank.
The trick is to get from the inputs on the left to the outputs on the right.
1. Draw the activities you need to get from the inputs to the outputs. If something is not driving towards the output, then ask yourself, why are we doing this?
2. Pay attention to all five workstreams.
- Evaluate
- Steer
Examples[edit | edit source]
Capstone Project[edit | edit source]
The capstone project is an important component of most Information Technology degrees, the Bachelor of Information Technology (B.InfoTech) at Otago Polytechnic is no exception. A complete list of projects is online at www.otagopolytechnic.ac.nz
Fincher et al. (2001) describe “keys for success” for projects. While they intend these measures to be used in establishing programmes, rather than specific projects, they do present a useful yardstick for successful projects. The Otago B.InfoTech is perhaps unique in its strengths in complete systems, including both hardware and software.
A significant challenge in the design of capstone courses is relationship between process and product. As academics we argue that a strong process will result in a good product but instructors face little direction in the identification of a suitable process. A major issue is that of systematically incorporating prototypes into the software design and development lifecycle. In this paper we have identified a development framework which successfully does that integration. This framework was developed from exemplar projects and provides a best system framework. The framework is also used to explore the development process of weaker projects.
Role of development methodology[edit | edit source]
This chapter aims to explore the role of development methodology in successful capstone projects, in particular the extent, nature and integration of prototyping.
In computing development projects the choice of development methodology is as perennial a subject for debate as is the choice of programming language. A methodology has to be selected for any given project and the selection may be based on a myriad of factors. Many educational institutions contain a capstone project whereby students, often in groups, work to complete a significant project. The choice of development process becomes pivotal in a capstone project (Beasley 2003; Chamillard and Goold 2003;. Bridgeman 2003, Clear 2003). In computing education, the choice is complicated by the introduction of the teaching imperative. The issue we face is finding not only the best approach for development but the best approach for teaching it.
Clear et al. (2001) described what they call the “process versus product tension” (p95) in the design of capstone courses. They refer to the decision as to whether the focus of the capstone course should be on the development process, or on the product of that development: a working system. They argue that as the capstone course emulates work as a professional “it is advisable that an acceptable methodology or process be adopted and followed. What specific methodology or adaptation thereof is chosen is less important than the use of some formal process”. Chamillard and Braun (2002) describe the problem thus:
| “ | “Given the importance of process in real software development activities, we want to ensure that our students get appropriate exposure to process issues. On the other hand, we also do not want our students to believe that if they follow an appropriate process, it does not matter if they generate a working product! We must therefore also provide the appropriate emphasis on the product the students are developing to ensure it meets the project requirements”. (p229) | ” |
What then, is an appropriate process for capstone projects? Traditionally, most capstone courses have used a derivation of the Software Development Life Cycle (SDLC, e.g. that described by Hoffer et al. 1999). In recent years, instructional designers have mixed this with components of agile modelling and especially prototyping (Fincher et al. 2001).
Hakim and Spitzer (2000) argue that the “challenge is to systematically incorporate prototypes into the software design and development lifecycle”.
In this paper we aim to identify a framework for successful projects.
Exemplar projects[edit | edit source]
In the following sections we examine the qualitative evidence of the development process of exemplar projects. Groups were selected to give a range of project category. Quotes are given from the students’ reflective reviews to portray the complexity of the decisions and process.
 Case study ACKI
|
|
Group: Kevin Barclay
The ACKI development aimed to create a box that sits between computer and keyboard, for users with limited mobility (Barclay et al. 2001). This was a generic solution for the needs of unique users. The box emulated the keyboard to feed analog or digital input form any device. Several aspects of the development process stand out. A stable testbed was established meaning that a detailed testing protocol could be established with an integrated test routine. The group kept a detailed log book of process and defined test outcomes. Different levels of prototype met different needs, the testbed was used to investigate technical issues, while whiteboard pens emulated joysticks to explore level of control, what does input device need to do. This project aligns with an Agile Development Framework even though it was a hardware based project. For each component “miniature lifecycles” were used with an – analyse-design-test cycle.
|
| Case study School network
|
|
Group: Boudewyn Erkens, Lorna Lou, Rebecca Sidaway
This project aimed to meet the ICT needs of a local primary school. In addition to network design and implementation, the group worked closely with the teachers in meeting professional development needs. While the project was hardware and training, the group followed the topdown structure of the SDLC. The training needs in particular were met through training needs analysis and then lessons were designed and implemented. The network solution was prototyped using a rapid installation and borrowed equipment which the school used for a month to see if the solution met their needs.
|
5.7 Alternative CAD interface
The SDLC was used as the basis for a project that aimed to develop a drawing board interface to architectural CAD systems (Lawton and Meikle 2003). Much of the project was development and configuration of hardware and then user testing of each iteration. The team developed many different prototype systems, and although using many of the same components, they built largely from scratch each time on a rig they developed.
“Aspects of prototyping were revisited again and again ... and again. Some aspects proved to be overly time consuming, and in one case a decision had to be discarded for this very reason.”
“Paper” interfaces will be developed with the assistance of architectural draughting students. The students will be asked to evaluate each version of the interface and contribute suggestions or criticisms. This will influence the following draught of the interface, as well as the requirements of the menu file (the interface code for the CAD application).
The hardware will be assembled and installed for testing with potential users. As with the criticisms, observations and suggestions will be evaluated and incorporated into the system. This stage is repeated until the functional requirements have been met”
The iterative stages of analysis, logical design and prototyping were run concurrently. Aspects of the project involving prototyping included a drawing surface, the construction of the frame, a pointing device, the projection system and the customisation of the AutoCAD interface. Problems were encountered, as well as unforeseen benefits of the system.
5.8 SMS The development of a system for the control of several remote devices via a cellphone was the goal of this group. This system involved the development and integration of several hardware and software components. The group followed an SDLC process, developing a hardware and software prototype in analysis: “we threw together an application…after getting this test application working we came up with a few problems with our design…we now had our functional requirements nailed down, and signed off, and could continue in-depth planning…”
The group developed a working system “prototype” and in implementation replaced major components sequentially.
5.9 Edubuilder The construction industry is an area where there are multiple layers of complexity, interacting roles, differing timescales and consequences of decisions. This is a prime target for a good interactive learning experience supported by technology. This project undertook to provide a content management system in an area where there is a vast store of expert knowledge available but few good information sources that take advantage of interactive media. The group followed the SDLC and began by working through a huge pile of building standards and struggled to find an underlying theme to hold it together. They used several metaphors before coming back to the building itself and the project plan chart. They developed a diagrammatic prototype and in discussion with several “clients” it became apparent that the different timescales, contexts and user views of a Gannt chart, that this was the elusive concept. To test this premise the group developed several prototypes to prove the concept, these ranged from a single sketch to a semi-functional interactive mockup of the system. These prototypes were used to explicitly test various aspects of the premise. In order to implement this concept the group realised some complex technical procedures were needed. The group used a carefully managed testing regime that identified a need for a test, the development of code, a test procedure and recording. As requirements were well defined, a stable system was developed and a rigorous testing regime utilised, the implementation at the end of the project was remarkably rapid yet the deliverable was robust and useful. 5.10 Information system for suit hire Despite being an ideal candidate for a traditional information system, the client for this project was not entirely convinced that he needed a computerised system. To alleviate this concern the group developed an early prototype on the computer that mirrored the paper based system. The client was convinced that he would gain efficiency while not losing the basis of the paper based system. This prototype also allowed the development of strong functional requirements. The group was also able to test their understanding of the current system by “operating” the prototype in parallel with the existing system, at the clients’ premises. Once analysis was completed, the group discarded the prototype. They then went through normal logical and physical design involving several prototypes. The client was unavailable for five months during this stage but the group was able to test the prototypes according to the strong functional requirements they had developed. The resulting system was substantially different from the original prototype in operation of the business but it retained the look of the paper based system. 5.11 Familtrak A familiarisation tour (“famil”) is a trip taken by people in the travel agency to familiarise themselves with the products they are selling. They are supposed to write up an account on their return but hardly ever do. The client for this project wanted a system to facilitate the reporting and dissemination of such. This was much more than a simple database, the solution involved a webpage, XML, GIS and a high degree of interactivity (Hamilton 2003). .The initial functional requirements were worked out between the group and the client. The group then undertook several weeks of validating and improving the functional requirements. This included much observation of work patterns, a questionnaire and a paper based prototype. A prototype was first used to represent the set of functions the system would be required to carry out. In logical design, a second paper based prototype was used to develop the structure of the system. The group first tested the prototype entirely on paper with the client, and then in a very clever move scanned in the paper and linked it together, resulting in a low fidelity but high interactivity prototype. This meant that “testing was completed before any code was written”. The was released to the client for actual production use three months before due date and the group was then able to work on perfecting the system and developing some of the more difficult aspects (linking spatial and multimedia aspects). 6 Exemplar Processes From the exemplar projects some themes emerge. These we distil into an exemplar development framework.
1. “SDLC” identified methodology 2. Prototyping used 3. Strong functional requirements used 4. Functional requirements tested with low fidelity but high interactivity prototypes 5. Stable platform for development developed early 6. Prototypes part of integrated testing plan 7. Early functional deliverable to client 8. Robust final deliverable 9. Still need ‘normal’ design – prototyping doesn't replace 10. Prototypes used in communication with client 11. Maturation by revolutionary (cf evolutionary). Staged replacement for hardware.
Some of these factors are perhaps expected measures of quality; it is not surprising that they appear here: we did not look at spelling or good intra-group communication but they would be expected on such a framework also. What we have though is evidence that the exemplar groups do these things. Some factors are surprising; we did not expect to find the maturation process so similar for the exemplar projects.
7 Validation In order to further explore the importance of the development framework, we undertook an analysis of the full set of documented projects. The first author worked through the documentation with a third person who did not know the history of the projects to assign a five-point scale to each of eleven factors. These scores are compared to the grades for the projects. It should be noted that this analysis uses grade used as measure for quality and we recognise that there are other factors at play here. We also recognise the potential bias of the authors in making this assessment, although this should have been partially mitigated by the impartial third person. A simple summation of the eleven factors provides a very high correlation (r=0.756) with the grade received for each project (Figure 3: for this and subsequent statistics the exemplar projects are excluded). Further, the relationship is not affected by the type of project.
Figure 3: Process score summation is closely related to quality, this is unaffected by the project type.
Figure 4 shows all the projects assessed according to the development framework. All factors are positively correlated with the grade. Some anomalous projects can be identified: Project “78 HW A” was a hardware procurement project that did not follow the framework, whereas “174 IS A-” was a retrospective project where processes had been followed but evidence was lacking resulting in a slightly lower grade. Most of the constituent factors that make up this score could be considered general measures of quality. Other measures such as efficacy of group work, or spelling, would probably also have positive relationships. This is still useful, we would also identify these factors as critical success factors. Some of the factors are not quite so obvious; the type of implementation – revolutionary or staged replacement as opposed to evolutionary – is striking in the pattern of being carried out by better groups.
Figure 4: Projects assessed by development framework, ordered from top by grade. The darker shading indicates a 4 or 5 where this factor is used. Exemplar projects above the line.
Perhaps more important than the overall correlations of the process factors, is the relationships between them at different ends of the spectrum – what are the poorer groups doing differently? By examining Figure 4 carefully (or looking at the correlations – not shown), some interesting patterns emerge. Poorer groups did less prototyping, which is understandable; they did less of other things too. What is critical is that when they did prototyping they did not also do “normal design” nor have stable systems, early delivery etc. Poorer groups that used prototypes in early stages also had very weak functional requirements, did not have strong testing plans etc., in other words the prototype became the development in total. Groups in the middle ranges that did prototypes tended to have weaker logical and physical design, instead they saw the development as one of making the prototype robust. These patterns can also be seen in the comments of the marking panel for groups in the lower half of the grades (Table 2).
Wrote code as proof of concept prototype then tried to design it. 'one half of the team was designing and the other half coding and both at different rates'
Technical decisions made in getting prototype out haunted later development good process limited by technical skills
Functional prototype developed early but without design, that bad design stuck, Digitised a bad process as some stages of SDLC missed.
Initial concepts done with prototype, anything deemed to be too hard never got considered as a real requirement SDLC but skipped from initial idea to implementation
Couldn't achieve much technical complexity so scoped down to make prototype deliverable
After successful prototype almost no progress for the rest of the year. At last minute, they independently implement the rest of it and retrospectively did SDLC analysis
Prototype developed for proof of concept stuck SDLC very weak.. Client happy but insufficient technical complexity
Palm development. Never had stable platform. Couldn't make it work.
Table 2: Comments from marking panel for C and fail groups
8 Conclusion Hakim (2000) argued that the “challenge is to systematically incorporate prototypes into the software design and development lifecycle”. In this paper we have identified a development framework which successfully does that integration. This framework was developed from exemplar projects and provides a best system framework.
Stein (2002) also identifies properties common to successful projects. But cautions “it is true however, for each property I can find … less successful project(s) containing the same property”. By examining how the development framework compares with what poorer groups are doing, we have been able to identify how this framework might apply to weaker groups. In particular, we have demonstrated the risk of weaker groups doing prototypes instead of normal design, or conversely, sticking to a naïve view of the SDLC that results in poorly tested designs.
This paper has not considered the level of technical complexity of a project. Goold (2003) discusses the effect of both technical skills of group members and the scope of the proposed project. It would be worth examining the complexity of projects, and how this relates to both the grade and the development framework adopted. We found that the framework applies equally well across different types of project (see also Avrahani 2002).
The tension between product and process can be lessened by adopting a process that can be seen to produce good products while being flexible and robust. We believe that the development framework developed in this paper will provide a foundation for capstone courses.
9 Acknowledgements We would like to thank the years of students for providing such a wealth of information. Also the work of the other lecturers on this course. Patricia Haden, Phoebe Eden-Mann and Zuzette van Vuuren helped with analysis. This research was carried out under Otago Polytechnic Category B Ethical Approval. References
Barclay, K., Mann, S., Brook, P. and Doonan, A. (2001) Development and Testing of an Adaptive Computer Keyboard Interface Paper in the Proceedings of 14th Annual Conference of the National Advisory Committee on Computing Qualifications Napier, p13-22 Beasley, R. E. (2003). “Conducting a successful senior capstone course in computing.” The Journal of Computing in Small Colleges 19(1): 122–131. Bridgeman, N. (2003). Project success: defining, designing, constructing and presenting a capstone project. 16th Annual NACCQ, Palmerston North, NACCQ.211-216 Clear, T. (2003). “The waterfall is dead, long live the waterfall!” SIGSCE Bulletin 35(4): 13–14. 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. 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, Cincinnati, Kentucky.227-231 Fincher, S., M. Petre and M. Clark, Eds. (2001). Computer Science Project Work: Principles and Pragmatics. London, Springer. 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 Goold, A. (2003). Providing process for projects in capstone courses. Proceedings of the 8th annual conference on Innovation and Technology in Computer Science Education, Thessalonki, Greece, SIGCSE ACM.26-29 Hakim, J. and T. Spitzer (2000). Effective prototyping for usability. ACM Special Interest Group for Design of Communications, Proceedings of IEEE professional communication society international professional communication conference and Proceedings of the 18th annual ACM international conference on Computer documentation: technology & teamwork.47-54 Hamilton, M. (2003). Familtrack. Proceedings of the 16th Annual NACCQ, NACCQ.484 Hoffer, J. A., J. F. George and J. S. Valacich (1998). Modern Systems Analysis and Design. Reading USA, Benjamin Cummings. Lawton, B. and A. Meikle (2003). Alternative CAD user interface. Proceedings of the 16th Annual NACCQ, NACCQ.487 Ponting, D., L. Quarrie and G. Robertson (2003). Serve i.t. right: hospitality training CD-rom. Proceedings of the 16th Annual NACCQ.495 Rudd, J., K. Stern and S. Isensee (1996). “Low vs High-fidelity debate.” Interactions 3(1): 76–85. Singh-Cosgrave, B., Sinclair-Fox,C., McLellan, G., Mann, S. and McGregor, G. (2001) Interactive CD for Teaching Development Based Subjects Concise Paper in the Proceedings of 14th Annual Conference of the National Advisory Committee on Computing Qualifications Napier, p460 Stein, M. V. (2002). “Using large vs. small group projects in capstone and software engineering courses.” The Journal of Computing in Small Colleges 17(4): 1–6.
4 Results
4.1 Initial findings It is worth investigating external features of the projects to indicate development characteristics of successful projects. Between 2001 and 2003, 65 projects have been completed. 35% gained As, 32% Bs, 16% C and 17% failed. The projects can classified into eight categories as shown in Table 1 along with marks distributions for each. With some small exceptions (“total systems” are all successful, ‘hardware’ has a higher than expected failure rate), there are no strong relationships between the type of project and the grade. Good grades are possible whatever the type of project.
Table 1: Classification of projects and grade distribution.
Total System 3 Hardware 15 Applied software 7 Information system 13 Multimedia 12 Content management 6 Network 3 Other 6 Total 65
Figure 1: Effect of group size on project grade.
There is an effect of group size, as shown in Figure 1. While groups of two or three show similar patterns, the students working alone have a much higher chance of failure. We believe that there are two underlying factors here: the quality of students (i.e. why are they working alone), and that they miss the benefits of working in a group.
Most students follow a document centred development approach. The students were wrong however, size does not count, the rumour about assigning grades by weight is not true. Figure 1 demonstrates a very weak relationship between the final grade and the number of pages in the documentation (n=49, complete documentation available in the library). Once above a minimum threshold of around 100 pages, any grade is possible. There are a cluster of top grades at around 260 pages. The projects with greatest amount of documentation did not get top grades and clearly poor projects cannot be rescued by a mass of documentation.
Figure 2: Weak relationship between pages and grade (n=49)
Good projects can not be identified by type of project nor by the quantity of work. So we come back to the question, what are the good groups doing?
MOAS[edit | edit source]
Iteration One
Iteration overview.[edit | edit source]
Having gone through nearly two years of doing assignments with specific instructions, the students arrive second year classes in software engineering expecting to be given a detailed brief. When they don't get one from us, they turn to the client, hoping to find one there. Usually they don't get one there either.
In 2008 our software engineering class is working to develop the "Living Campus Information Infrastructure" . What does that mean? Good question, and one the students have been asking both us and their client, Paula.
In this project we are not being deliberately vague, we genuinely don't know where this project is heading. This makes teaching the course interesting, in adopting the agile concept of embracing change we are also experiencing the values of courage, simplicity, feedback and respect. This applies to the students and the academics equally, which makes for a shared learning experience.
We're also following the manifesto, valuing those things on the left more than those on the right:
- individuals and iterations over processes and tasks
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan.
We mix this agile approach with a framework - three iterations. Each has milestone deliverables, the first is understanding and communication, the second a functional delivery, and the third: a robust delivery.
So the goals of the first iteration are all about building understandings - not what the project is going to result in, nor even what it has to do. Rather, the focus is on why - why is this a project that needs their help. In other words - what is the business opportunity.
The first iteration is also about building confidence and communication (within the group and with stakeholders).
In the first iteration the goals are to build up understanding of the business opportunity, and how the teams might use their skills in information technology to work towards meeting that opportunity.
One of the first things they do is to meet with the client. The purpose of this meeting is to establish connections with the client. It is not the time to be expecting detailed functional requirements.
By the end of the first iteration we will have:
- established a development team
- established firm communication links with the client
- established that we are on common ground with the client about the high level need for the project
- established a methodology and work practices.
The first iteration is quick. For a full year capstone project, this should take a maximum of two weeks. Two weeks, that's hardly long enough! Yes it is. On each of the tasks described in each chapter, an information box indicates how long each task should take. If it's taking longer than this, then you're doing something wrong.
Iteration One/System metaphor
| System metaphor |
|
 |
What is a metaphor?[edit | edit source]
In the first iteration, the functional requirements sector involves us having discussions about our approach to the business problem or opportunity. We do this by means of a system metaphor.
A metaphor is a comparison between two seemingly unrelated subjects. They are used in language to enliven, to encourage interpretation and to provide a vehicle for understanding when either there are no direct terms for a concept or other explanataion is cumbersome. By understanding and experiencing one thing in terms of another we can provide a means of exploring a concept even before we’ve really come to terms with what it is we’re talking about.
Perhaps the most famous metaphor is Shakespeare’s opening:
| “ | All the world’s a stage
And all the men and women merely players They have their exits and their entrances |
” |
— As You Like It 2/7 | ||
In ordinary conversation we speak of “pulling your socks up”, “drowning in paper”, “unfolding the road map to peace” and “my memory is a little foggy”. The metaphor we use for something can be quite informative. For example, the words we use for business are often based on a war metaphor: “hostile takeover”, “losing ground”, and so on, and these in turn affect the management of the business. Ray Jackson (quoted in CEO Forum) uses lessons from the military in a discussion of business practices:
I think it taught me that the world is always imperfect, and that your knowledge base is also imperfect. In military operations, you never really have ‘all the facts’, in the literal sense. So it teaches you to operate on incomplete data: take the data you have, turn it into information, and figure out what you need to do. I guess I learnt that clarity is better than certainty: there comes a time when you have enough information to move on. If you wait for certainty it never arrives. The military makes you comfortable with uncertainty.
The other thing I learnt was the need to not procrastinate in making decisions, and to be incisive. You learn a process of continually making decisions, then reviewing those decisions as more information comes to light. This has been very useful in business.
The military also teaches you to carefully manage resources. On a naval mission, for instance, you only have a limited amount of fuel, a limited amount of ammunition, and so on. Your most important limited resource, of course, is your people, so you need to look after and nurture them - you can’t work them to death! The military teaches you to always be very mindful of your resources and how you can best use and conserve them.
I also think you learn a lot about leadership and communication. I like the expression ‘People don’t want to be continually inspired, they just want to know what they should do’. Most military people have a highly competitive, ‘we are here to win’ streak, so that toughness and commitment is there. Some aspects of business are like a battle, so those types of attitudes can be useful. Another useful attitude is to set your goals, and then be steadfast in pursuing them come what may. The goals of war and business are different, of course. War is about defeating an enemy - it’s a zero sum game. In business, on the other hand, your objective may be to be the most profitable company. It’s not a goal that involves defeating an enemy in the same way - it’s more about achieving your own goals.
(See also Marketing’s maneuver theory for explicit - and controversial use of the military/business metaphor: “The Armory - the online resource for the competitive marketer is the exclusive host for The Art of Attack - How to Attack and Dislodge the Larger Competitor”).
Lakoff and Johnson (1980) argue that we live our life by metaphors.
Software development: system metaphor[edit | edit source]
In software development the System Metaphor has been adopted as a core practice by the agile community. Kent Beck, author of Extreme Programming Explained defines a system metaphor as:
“a story that everyone - customers, programmers, and managers - can tell about how the system works.” p. 179.
Wake argues that we seek a system metaphor for several reasons:
Common Vision: To enable everyone to agree on how the system works. The metaphor suggests the key structure of how the problem and the solution are perceived. This can make it easier to understand what the system is, as well as what it could be.
Shared Vocabulary: The metaphor helps suggest a common system of names for objects and the relationships between them. This can become a jargon in the best sense: a powerful, specialized, shorthand vocabulary for experts. Naming something helps give you power over it.
Generativity: The analogies of a metaphor can suggest new ideas about the system (both problems and solutions). For example, the metaphor, “Customer service is an assembly line”. This suggests the idea of a problem being handed from group to group to be worked on, but it also raises the question, “What happens when the problem gets to the end of the line - does it just fall off?” This can bring out important issues that might otherwise lurk and fester.
Architecture: The metaphor shapes the system, by identifying key objects and suggesting aspects of their interfaces. It supports the static and dynamic object models of the system.
Another benefit is Generalisability. We can use the metaphor to move between developments: "Like the lettuce project, but with more of a greywater approach" is a real sentence used in developing a new project.
Choosing a metaphor takes work. Hopefully, you’ll traverse deep and rich ground as you come to agreement over an appropriate metaphor. This an important part of the process and you should attempt to recognise and capture these thoughts. Jefferies (2001), in an evocative description of an agent-based information retrieval system describes “this program works like a hive of bees, going out for pollen and bringing it back to the hive”. Although Jefferies doesn’t describe them, it is likely that they tried other metaphors first. Perhaps “a vacuum cleaner sucking up all knowledge?...no there’s lots of them and anyway the information is structured - not just a big dustball, well perhaps a library? no, that is big and static, what we want is something that selectively collects information, like a fleet of recycling trucks...”.
Some metaphors are used repeatedly in software development. Some common approaches:
1. Spreadsheet Metaphor
2 Script Metaphor
3 Manufacturing Metaphor (e.g. LinesStationsBinsParts or AssemblyLine)
4 Accounting Metaphor (double-entry archive notation)
5 Shopping Cart Metaphor (e-commerce)
6 Auction Metaphor (e-commerce)
7 Blackboard Metaphor (ai)
8 Document Processor (desktop systems where the “model” gets saved as a file)
9 Virtual Space Metaphor (eg. VR)
10 Desktop Metaphor
11 Tools and Materials Metaphor
12 Buttons Everywhere Metaphor
13 Person - what would a person employed to do this job do?
(other sometimes useful metaphors: bank, courts, newspaper, farm, road map, police indentikit)
In cases where no one can think of an appropriate metaphor (with or without vivid imagery), the approach is to develop a “naive metaphor”. This means that you describe the system more literally (a student management system would have student and enrolment objects etc). The disadvantage of this is that it isn’t really a metaphor - you won’t gain any deeper understanding or insights as it is rooted in what you already know. Try and avoid 'nearly computing' metaphors - concepts such as a CD rack are too close to computing to be useful.
Process[edit | edit source]
So, what do we do with this system metaphor? For some Agile proponents, the system metaphor forms that basis for much of the programming, the tenor and subjects of the metaphor directly translating to classes and patterns.
We take a lighter approach. The system metaphor is primarily a tool for discussion here in the functional requirements of the first iteration. It may also prove useful to prompt thought in the Interaction Design of Iteration 2.
The metaphor should be stated in simple terms. As Ryan states: “The system is a bakery” jibes better than “The system interprets text as commands and executes them against builders that produce resultant objects and attach assorted decorators, sorting them via pipes and filters to the correct bins; the user can than browse and eat them as needed.” (C2 2006).
Once you have a metaphor, the trick is to explore all of its characteristics, writing them down on paper or whiteboard. These ideas will flow directly to the user stories or functional requirements.
| Case study Project management software
|
|
Group: Software Engineering 2006
For a project to develop a project management and group collaboration tool, a metaphor of a fridge door was useful:
...and does all these things without getting in way of real job (keeping food cold - our system mustn’t get in way of the project being undertaken). An alternative metaphor for this project was a car dashboard (see below), another was a library.
|
For another project, a community based surf report system for surfers, a single system metaphor proved elusive. The process, however, was very useful. As we explored possible system metaphors - a newspaper; a radio snow report; a school newsletter - the reasons why these didn't work as metaphors effectively built a list of characteristics of our system.
Tricks[edit | edit source]
hile a different metaphor might be better, it is unlikely that a metaphor can be wrong, especially if you are using it as a tool for exploration. If you realise that another metaphor is better, then good, it means that you have made a breakthrough in your understanding.
Rather than “wrong” the worst outcome is that the metaphor becomes a cause of miscommunication. The following is extracted from the c2.com/xp wiki:
Ask yourself, what more familiar things is this problem like? Is it really like ordering coffee from a fancy coffee machine? Is it really mostly like steering (tacking) a sailboat across a lake? driving from Toronto to Paris? (...a journey of less than 90 minutes, since Paris is just on the other side of Brantford. -- RandyMacDonald) (just to avoid the CanadianCulturalAssumption) You mean Paris, Kentucky, right? :) Or perhaps a polar route during a cold winter...
* Whoever tried to clean this up by deleting didn’t fix the underlying problem, so I put it back. Next WikiGnome: clarify the driving-from-Toronto-to-Paris issue or leave as is for now.
No, best left! It illustrates rather beautifully the way subtle misunderstandings can arise. Developer-One says: “This is like driving to Paris”, meaning a short journey. Developer-Two gets a mental image of driving through the Chunnel from the UK to France, and considers how to avoid trains. Developer-Three (in the USA) ponders submarine cars. The misunderstandings here highlight the importance of MeaningDependsOnContext in discussions, especially about something as crucial as the SystemMetaphor. -- BenLast
We have to be careful then , to avoid “false insights”.
Before you discard a metaphor for another, be sure to capture all the characteristics of the first - they will still be useful in the Planning Game. Also, capture the things that lead you to make that change in metaphor. The things wrong with the metaphor can define your system just as well.
A metaphor needs to be familiar enough to the group that needs to use it. To say that it is “an accrual accounting system but for carbon credits” might be a perfect metaphor for the financial accountants but if such accounting isn’t understood by the programmers, then it will act to confuse rather than enlighten.
Sometimes the metaphor limits understanding. The paper based rows and columns spreadsheet was a strong model in the development of spreadsheets (!), but the conceptual leap from the paper to the real power of a modern spreadsheet is quite large. This leads to the danger of introducing “magic”: “it’s like a magic whiteboard”. While this helpfully encompasses all of the basic functions of a whiteboard, the real innovation of the system is hidden behind a veneer of “magic”.
We also need to know when to give up on the metaphor. The project management development described above by the fridge door metaphor was also described by a car dashboard. This worked extremely well as a system metaphor in early stages: unobtrusive but critical monitoring of vital indicators etc, but became cumbersome when used as the basis for the interface design (dials, steering wheel with leather trim and so on).
Metaphors work best when you give them chance to work. As soon as you start slipping back to describing characteristics of computing things (security, login in, etc), try and lift your thinking back to a more abstract metaphor. One way to do this is to think about the metaphor on steroids - what would a super x look like? Be careful though, as discussed above, you have to more specific than a "magic x".
example: dashboard[edit | edit source]
| Case study Dashboard
|
|
Group: Software Engineering 2006
The dashboard metaphor was useful in developing ideas for a project management system (in fact, one to support the Agile Development Framework). Using the familiar concept of the car dashboard providing critical information was a useful way of thinking about what information project groups needed to be able to see constantly; what events would prompt warning lights etc. Some groups continued the metaphor for the whole development process, it, got complicated when we tried to mix the notion of drilling down for more information (not a function one would normally find on a car dashboard).
|
| Case study Talking with Leonardo
|
|
Group: Chrissie Jackson and Jonathon Ung for Otago Museum
The Leonardo Talking Head robot is an interactive robot with a personality. The robot will accept speech and respond back. It is designed primarily for children and has the ability to educate users on the works and life of Leonardo. Leonardo greets visitors when someone activates the sensor. He has four main topics that he can talk about: Art, History, Machines and Science. This project is in conjunction with designers who are making the actual head.
This metaphor was useful in helping us understand the system because it shows the characteristics we need to take into consideration when developing the system.
|
Metaphor for business opportunity[edit | edit source]
If you are really stuck, then one way of making a naive metaphor work is to think about metaphors for the business opportunity (rather than a metaphor for the information system itself. This may be particularly useful when the business opportunity itself is hard to comprehend.
| Case study eLivingCampus
|
|
Group: Software Engineering 2008
The groups first developed metaphors for the whole project:
Some of these metaphors turned out to be too close to computing. The encyclopedia and the CD rack, for example, didn't really offer much new insight - they describe any generic computer system. Perhaps because the Living Campus itself is not something the students had encountered before, we then switched tack, and thought about metaphors for the Living Campus itself. What are the characteristics of familiar businesses (or institutions or processes) that could be used to help think about the Living Campus - then, what are the information needs of those metaphors?
The Living Campus Information Infrastructure project benefited from thinking about information needs of other businesses:
|
References[edit | edit source]
http://en.wikipedia.org/wiki/Metaphor http://c2.com/xp/SystemMetaphor.html last updated 15/2/2006 Viewed 24/7/6 Jackman, R. (2006) Is business war? What military affairs can (and can’t) teach CEOs http://www.ceoforum.com.au/200206_ceoinsight.cfm Viewed 21/7/6 Jefferies, R. (2001) What is eXtreme Programming http://www.xprogramming.com/xpmag/whatisxp.htm viewed 21/7/6 Lakoff G. & Johnson, M. (1980) Metaphors We Live By http://theliterarylink.com/metaphors.html Wake, W. (2000) System Metaphor http://www.xp123.com/xplor/xp0004/index.shtml viewed 21/7/6 Wake, W. (2000) Proven system metaphors http://c2.com/cgi/wiki?ProvenSystemMetaphors viewed 21/7/6 http://knowgramming.com/ http://twoscenarios.typepad.com/maneuver_marketing_commun/2005/05/military_metaph.html
Iteration One/Planning game
| Planning game |
|
|
Requirements and the Planning Game[edit | edit source]
The goal of software engineering is to deliver software that does what it is supposed to do, on time and under budget. As we have learned, traditional plan driven methodologies have consistently failed to achieve this. One key factor has been the strategies for the elicitation of requirements. Plan driven waterfall methodologies determine requirements thoroughly at an early stage, then use these requirements to guide the remainder of the process. The problem is: what happens when the requirements change? This might happen when the business itself changes, or different users consider the software and suggest alternative applications, or the client gains a better understanding of the possibilities of the software.
What is a requirement?[edit | edit source]
• A requirement is a statement identifying a capability, physical characteristic, or quality factor that defines a product or process need for which a solution will be pursued.
Functional requirements describe what the system does (capabilities).
Eg, “The system shall enroll students in courses”
Non-functional requirements describe what the system has (physical characteristics). Includes reliability, quality, safety, maintainability.
Language[edit | edit source]
One of the challenges in the discussion between the customer and the developers is the language used. The customer is an expert in his business domain, and will use language appropriate to that domain. For example an accountant will use terms such as ‘return on investment’ (ROI) or ‘net present value’ (NPV). In the education domain, phrases such as ‘path of study’ (POS) or ‘equivalent full time student’ (EFTS) are part of the familiar vocabulary. The developers meanwhile, are familiar with technical terms and can easily confuse the customer with this jargon.
The Agile Approach[edit | edit source]
Agile methods use an approach to determining requirements that can be described as “just in time” requirements analysis. Meetings are held with the customer and/or users in which a best guess is made of what the requirements might be, given the current understanding of the problem. The language used must be understandable to both customer and developer, as the process is the beginning of an ongoing conversation which will continue throughout the development.
Kent Beck, in Extreme Programming (2005) describes a formal requirements gathering process called “The Planning Game”. This is one of the defined Extreme Programming practices. Remember that the key values in Extreme programming are:
Communication Simplicity Feedback Courage Respect
The Planning Game applies these values by encouraging early, effective discussion with the whole development team, including the customers. User stories are captured onto index cards and displayed for the whole team to discuss. They are then used to plan the development, including releases and estimation of time. Team members prioritise the cards, discuss constraints and describe tests for the completion of the stories. Mike Cohn (2004) has developed Beck’s ideas with his application of user stories to agile development.
What is a user story?[edit | edit source]
“A user story describes a functionality that will be valuable to either a user of purchaser of a system or software.” (p4, Cohn, 2004)
The story describes something that the user will do in a single session, for example, “The student will access a project file”, “The student group will have concurrent access to the project files”.
The user stories include three components:
1. The story itself
2. Comments which may clarify details of the story, or raise a point for later discussion
3. Tests to indicating the completion of the story
Jeffries (2001) describes the process of composing the user stories as “Card, Conversation and Confirmation”. The cards are used to capture the initial requirements, which are then discussed among the team and then implemented and tested. This emphasises the stories’ role as a communication tool, to be used in the development process. They are not used to document the process and are not a contractual obligation. Traditional requirements documents were both of these things.
Using this approach allows the team to spread the decision making across the duration of the project. Big picture decisions can be made early, which allows initial planning. Details can be added later as required. Early, large stories are known as ‘epics’.
How big is a story?
Ideally, it describes a task that will require ½ - 10 days coding, assuming an experienced development team. Learning to estimate the size of a story is an important skill for developers. Planning which stories will be included in each iteration is dependent on good time estimations.
Why use story cards?
They emphasise verbal rather than written communication
They are understandable by all team members
They assist effective planning
They enable iterative development
They encourage deferring detail (Cohn, 2004)
A good story is:
• Independent
• Negotiable
• Valuable to users or customers
• Estimatable
• Small
• Testable
(Wake, 2003a)
| Case study Shac09
|
|
Group: Software Engineering 2007
By thinking about various system metaphors, the class was able to write a large number of stories about people involved in the metaphors (eg Judicial system - "The lawyer applies for a mistrial"). These were easily translated to the real system - an information system to support a sustainable house building competition. These user stories were then sorted and ranked via the planning game.
|
Iteration Two
Overview Iteration Two[edit | edit source]
The second iteration is the heart of the development process. In it we progress from having a high level understanding of the business problem/opportunity to having a system deployed in active use by users.
In the first iteration we have:
- established a development team
- established firm communication links with the client
- established that we are on common ground with the client about the high level need for the project
- established a methodology and work practices.
In the second iteration we progress through a development cycle. We first work out in some detail what needs to be done, work out how to do it, and (you guessed it) do it. We finish this iteration with a deployed system that functions and is useful. Exactly what that system does (and what gets left until the third iteration) we’ll come back to. For the moment, it is important that we know that the date of delivery is the most important variable. This is called a timebox, which means that we adjust what we are trying to do to fit the time and resources available.
Remember that the internals of each of these sectors is not explicitly defined. What is more important is the flow of information as we massage and enhance our understandings as we move to the output of that sector. We should, though, always be able to explain why we are doing something, and demonstrate how it helps us towards the goal.
Although the focus here is on structured processes, we undertake them according to agile principles. We expect that scrum meetings are the basis for each day’s work, that there is a focus on quality and simplest thing that could possibly work, and that the emphasis remains on outcomes rather than processes for the sake of it. Always keep a metaphorical eye on the rainbow for that sector to a) check that all workstreams are covered, and b) know how what you are doing directly feeds the outcome of that sector. We should include the client as much as possible through the process and will be sending formal documentation at the end of each sector (sometimes a detailed proposal, sometimes an update letter).
The evaluation sector is the transition between iterations. In it, we look back at what we have done so far and plan the next sectors. This is an important phase in formalising our interaction with the client by means of a proposal.
Functional Requirements[edit | edit source]
The Functional Requirements sector can be summarised in one word: “what”. Here we work out what the system needs to do (as opposed to how to do it).
The functional requirements are instructions describing what functions the software is supposed to provide, what characteristics the software is supposed to have, and what goals the software is supposed to meet or to enable users to meet. Functional requirement statements begin with “The system shall...”. (Note: there are some moves to replace this with user stories “The user shall...”). They are usually accompanied by system requirements: “The system shall have....”.
To get to these functional requirements we go through a process of collecting and understanding as much information as we can. Very quickly we have to understand every detail of the organisation we’re working with. From the first interview we have to be knowledgeable about the business. Fortunately we have some techniques to help collect and structure this information, working from both above and below the problem. We use functional decomposition to help us understand the business workflow, data modelling to identify structures and relationships and logic structuring to capture business rules. We also observe and question users.
These techniques will lead us directly to directly to functional requirements that define what the system has to do. We test these functional requirements to make sure that they address the business opportunity and are feasible to develop (though we have to be careful not to restrict our thinking). These requirements become the basis for our development and are fed onto the next sector.
Interaction Design[edit | edit source]
In Interaction Design we develop the look and feel of a system that meets the functional requirements. Although we mostly think about interfaces being computer screens, most projects have other non-screen interface elements, for example forms, reports and sometime s physical interactivity systems.
The output of this sector is a design proposal that we will formally present to the client. The client and users should be closely involved in this sector.
This is the most fun and creative stage of the whole development process, but it is also a sector that requires much rigour and care. All five workstreams are likely to be running simultaneously and you should expect to have several balls in the air at the same time.
Four tricks this time:
- Test everything: users don’t behave or think the way you do
- Don’t cheat: building an interface in your favorite IDE and then working backwards through process doesn’t work. Do not skimp on the dialogue diagrams.
- Users should forget they are using your system: the measure of success is primarily in match to the users’ model of how something should be done, and people like things simple so you should be as elegant as possible: a few well designed interfaces are far preferable to a multitude of hotchpotch.
- Go around again. This sector is hard work but is the most satisfying of all. If something doesn’t work, keep trying and if it does work, test it until you break it. It is far easier to get it right here than when you’ve spent ages coding it. And remember, for the users, the interface IS the system, all the other stuff is just mechanics - this has to be right.
The flow here is directly from functional requirements that we turn into tasks performed by the users (whom we consider in some detail). These tasks we develop into diagrams that represent the best possible way of achieving those tasks. Then we think of all the possible things that can go wrong and make sure that our system can support this. While we are doing this, we have one eye on developing a logical data model that supports the information we are working with. At the same time as are doing this we work on developing design themes. Starting with the metaphor, we come up with some alternatives about what the system will look like. This means the style of look, but perhaps more importantly, the style of interactivity.
Then comes the most important bit: taking the theme, the dialogue diagrams and the logical data model and converting these to a wireframe interface. This interface we test as a paper based prototype with the actual user. Expect here to realise you’ve gotten something completely wrong and go back to the dialogue diagram, the design theme, the tasks or even the functional requirements. It is important to recognise the iterative nature of this stage, revising past decisions, adding or changing functional requirements is part of the development process.
We present the results of this development and testing in Interaction Design presentation/document to the client.
Design Specifications[edit | edit source]
In the design specifications we put the detail on the Interaction Design.
By the end of this sector we have a blueprint to give to programmers. They should be able to build exactly what we specify. The design specification integrates both the look and the how. We take the design theme and wireframe and develop detailed interface specifications and complete designed products such as the user manual. Alongside this we continue to develop the database (the key here is ‘no magic’ - all data come from and goes to somewhere). The physical data model is a detailed specification of the information to be stored and manipulated by our system.
Alongside the ‘how’ of the interfaces we also work out the how of the back end. This starts with the database and system architecture (expressed in a diagram), then decisions about coding structures and ends with development and testing of a stable development platform.
The stable development platform is the framework upon which your system is to be built. For example, for a database with a web front end we would expect you to demonstrate connectivity and basic database functions via the web (insert, delete, query, update) plus any standard infrastructure (login etc).
Implementation[edit | edit source]
The implementation stage is about building a system according to the specifications. This is where you get the pay back for all the hard work you’ve done so far. Building upon the stable platform, with a physical database designed and tested, and with detailed interface specifications, this implementation shouldn’t be an enormous task. Fortunately, software engineering also facilitates the implementation sector. We use several tools from Extreme Programming (XP) to help us. We use modular and pattern based development, we use paired programming, and we use test based development. We test extensively and then we test some more. We carefully think out the best way of deploying the system and we do it. While this is happening we train the users.
At the end of this sector we have deployed a system that works and, importantly is in active use by the users.
Evaluation[edit | edit source]
Once the system has been in use for a while we need to take time to do an evaluation. This is more than just a “does it work?” (although that is important too, but also includes a hard look at the functional requirements (were they right?, are there any missing?, and so on) and a reflective look at all aspects of the development. The client should be closely involved in this reflective process.
Iteration Two/Good requirements
will be the page about structuring requirements
Requirements template[edit | edit source]
Requirements Specification[edit | edit source]
Functional Requirements[edit | edit source](What the system does, 10 –12 of these, this is the important bit. Think about how the users will use the system – what will they need it to do? Be specific to your project. | ||
|
=Number examples=||Requirement The system shall:||Description | ||
| FR1 | Allow museum object data entry | The users will need to add new data to the system when items are donated to the museum. |
| FR2 | Enable public access to stored museum data | Researchers may wish to access stored genealogical, shipping and local history information. |
Non-Functional Requirements[edit | edit source](what the system has) | ||
| A. Data Requirements | ||
|
=Number examples=||Requirement The system shall:||Description | ||
|
==D1==||Store object acquisition data ||As objects are acquired by the museum, data relating to the object must be captured | ||
| D2 | Store object location data | Enables the staff to quickly locate any museum object. |
| B. Security Requirements | ||
|
=Number examples=||Requirement The system shall:||Description | ||
| S1 | Prevent unauthorised changes to museum data | Public using the system must not be able to delete files. |
| C. Interface Requirements | ||
|
=Number examples=||Requirement The system shall:||Description | ||
| I1 | Provide an administration interface | Administrators will need to access the system directly for editing. |
| I2 | Provide an interface which reflects the Maritime Heritage theme | This is important to ensure public and government support for the new buildings |
| D. Constraints
What might limit the development of the system | ||
|
=Number examples=||Requirement The system shall:||'Description' | ||
| C1 | Cost less than $20,000 | Little funding available for software. |
| C2 | Be completed by January 2004 | 'This allows the system to be running in time for the new school year' |
Iteration Two/Fishing
fishing for materials
Iteration Two/Data modelling
| Data modelling |
|
|
Data is...
Why do some argue is most important thing:
Static structure of system - like a map
Advantages of database approach Program-data independence Minimal data redundancy Improved data consistency Improved data sharing Improved data quality Reduced program maintenance
Difference between data model and database[edit | edit source]
Modelling process
Data modelling is DESIGN Creative solutions needed Data model is one solution to req’s
Data modelling is IMPORTANT Need a blueprint to build a house
Data modelling is a discipline Professional judgement required
Data modelling through the development process.
Entity relationship model: Detailed graphical representation of entities and associations
Focus is purely data Not what happens to it Depicts the form of the data Not the data values Specific to the needs of the business
Person, place, object, event, concept that is of interest to the organisation single, unambiguous names Student, book, product
Time Space Fuzzy
Association between the instances of one or more entity types name strongly make a sentence to describe the relationship may have attributes – an associative entity
A book is borrowed by a patron A patron may borrow a book
Conceptual Schema A detailed, technology independent specification of the overall structure of a database Physical Schema Specifications for how data from a conceptual schema are stored in a computer’s secondary memory
Let's say we are working on a High School records system. From our initial requirements determination we have a collection of material: class lists, individual transcripts, class results and so on. The tasks in data modelling is to extract the underlying structure of the information. This is the data model.
The core of the data model is the entity. An entity is something about which the organisation holds information. It can be an actual thing or something less tangible like a concept (or student grades). Note that an “entity” here describes the generic level of the things: hence STUDENT, rather than Bob. Bob, Jane and their friends are all instances of STUDENT.
In our simple school we can easily identify three entities: STUDENT, TEACHER and COURSE.
Each entity is described by attributes. These are what we use to describe the instances of each entity. There are strict rules about attributes, they need to be independent and not repeating information. They also need to be atomic (can’t be broken down), and not be dependent on other values.
In the example below, StudentName is unsuitable as it can be broken down into first and surname; StudentAge isn’t necessary as it can be calculated (putting it in by hand is asking for trouble), and StudentGrades is not atomic - it contains multiple values - which will not work (we’ll come back to this one).
We also need some way of uniquely identifying each instance, this becomes the Primary key for the entity. This has to be not change be unique. We could use the name but, despite us all feeling special, our names aren’t. We could combine the name with date of birth and make a concatenated key. Unfortunately, dates are very difficult to deal with (what is the significance of the 12th of September?) and it doesn’t resolve our non-unique problem. So we have to use a new value: a STUDENT_ID.
We can get the same information from these attributes and the data is structured much more powerfully.
The student grades are not information just about the student, they are information about that student's interaction with courses.
The courses a student is enrolled in is more difficult to solve, but the solution is the heart of the power of a data based (and hence database) approach to understanding the business and implementing a solution.
In the example above Bob is taking only Geography (wise choice), so that is easy to deal with. Jane, however is taking French, Geography and History. If we try and store this information in an attribute called Courses it is very difficult to extract this information - while it would be easy to get a list of Jane’s courses, a list of who is taking Geography would be very hard to extract (and involve complicated string manipulation etc).
The real strength of data modelling, is in the identification of relationships. A relationship describes the association between entities. We start just by drawing a line between the entities:
We can see that there are clear relationships between STUDENT and COURSE, and COURSE and TEACHER. We can express these relationships on the picture. Reading in the direction of the arrows, these associations can be expressed as sentences: “a STUDENT takes this COURSE”, “a COURSE is taught by a TEACHER”. (we’ll come back to how many when we look at cardinality).
The STUDENT - TEACHER association, however, is not so clear. The relationship (at least the one we are considering here) is already expressed by the model. We can extract which teacher is teaching which students via the COURSE they are teaching and enrolled in. We don’t need an explicit STUDENT-TEACHER relationship.
Even that this level of consideration, we a being forced to carefully think about the business we are dealing with. We could have described a STUDENT-TEACHER-COURSE model. Why have we chosen not to have the STUDENT-TEACHER relationship rather than not having STUDENT-COURSE?
We also need to express the numbers of instances that might be involved in the relationship. We do this with "crowsfeet", with the crow's foot on the many end.
Here we have “many STUDENTS may take many COURSES”, or conversely “many COURSES may be taken by many STUDENTS”. We express the “many” on our diagram with a “crows foot” (hanging on to the many end).
Early in the development of conceptual model it is OK to have a relationship like this, but we need to do more to make it useful. A double-ended crowsfoot like this is called a "none-specific relationship", we know we have lots of students and lots of courses, but not who is taking what.
One solution to these unconnected lists, is to include attributes for each of the courses someone is taking (below). Unfortunately this doesn’t work either. What happens when someone enrolls in more courses than you have previously thought of, where do the results actually go, and we still don’t have a way of finding out who is enrolled in Geography.
What we need is a new entity to represent this relationship. This is called an associative entity.
We might have identified it earlier as it is really quite strong in terms of ‘thingness’. The relationship between STUDENT and COURSE also has several parameters in its own right: date, result, perhaps internal assessment grades and so on. The fact that the relationship has attributes indicates that it is really an entity.
Again, we come back to the value of this process in understanding the business. Is it just one entity? We can think of several possible names for the entity - are they the same thing.
There are cases where multiple names indicate multiple associations - the Human resources manager authorises payment of salaries (one relationship), but is also on the payroll herself.
This middle entity shows the association between STUDENT and COURSE, ENROLLMENT. When we implement the model, the ENROLLMENT entity (table) does not contain the student’s names, nor the courses - the computer can quite efficiently go and get them. Instead we just use the primary keys from the other entities - they become foreign keys.
There is though, a flaw in our model. Jane Smith seems to be enrolled twice in History. This is not a mistake (except for Jane) - she failed it the first time. In order to allow this to happen we need to represent more information, the year of enrollment. Our model can generate the information required, it will be useful as the development progresses as we work to make it more tightly defined.
The primary focus in functional requirements is the process itself, by developing such a model, we are forced to think carefully about the business we are working with.
Example models[edit | edit source]
This model describes a job management system for an engineering firm.
A different group made this model for the same system.
A system for a library. When developing this model, most people think of "book", but a book means different things in different situations. It is the physical book that is loaned, yet it is the "title" that people actually want to read (and that of a particular category such as large print). Note the two relationships between item and patron for loan and reserve.
This system describes an environmental planning system for agriculture.
Iteration Two/Process modelling
| Process modelling |
|
|
Iteration Two/Context
| Context analysis |
|
 |
Staff
Jim Wilson or Peter Cole comes into the Museum Monday morning. The first thing they do is check the email for any incoming correspondence and check the electronic diary to see if there any appointments scheduled for schools wanting to come for the educational programme.
Recently a request has come from the Otago museum for the Antarctic display to be loaned to them along with some other exhibits that are related. Either Jim or Peter will Loan objects out of the system.
A container of artefacts were delivered to the museum some weeks ago and Peter has had a volunteer entering new data into the information system. He spends about 2 hours going over the newly entered data to ensure that it is entered in the form required. He makes a few adjustments and saves the data permanently.
A phone call takes his attention and he records a school visit in the paper diary. He also makes notes in the diary that another school has pencilled in a visit for the following month via the web site. They mentioned that there was not enough information available on the web site so he must prepare a package of information to post out. He prints off a copy of an information document that is already in the system.
About 2 pm a school group arrives and Peter must show them around and guide them through the exhibits. He spends 5 minutes describing how the children can use the computer in the museum display area to do some limited research.
After the school group leaves Peter queries the database and gathers some information for a researcher who is unable to come to the museum. He then emails this to the client. Peter’s day finishes up with him emailing out information requested and ensuring that the web site is active.
He emails the web site manager to ask that some minor changes be made.
Public Joe public decides he wants to know more about Great Aunt Agatha who came across from England and landed at Port Chalmers early on in the 20th Century. He fires up his trusty old computer and connects to the Port Chalmers museum web site. The web site offers options such as Search Archives, School Bookings, Information Request, About the Museum and opening hours. He clicks on the Search Archives link and is presented with a number of options. The options include searches for shipping records, early people, photographs, cemetery records and early school records.
Joe chooses to search for Aunt Agatha by her surname of Burton. He receives a list of people on the museum database, clicks on the name that he is sure is his Great Aunt and a window with her name and the date of her arrival is presented to him. He notes the name of the ship that she arrived on and does a further search for details of the ship. A message is displayed saying that more information is available but he must come to the museum to do the research.
Joe is not happy about this but his desire to know more will take him out to the museum the following week. Joe then looks at the museum open hours and notices that there is also a link on the web site that allows him to request that the museum send him information for a fee. He seriously considers this option.
School Mary Simpson the Vice Principal of Arrowtown Intermediate has discussed a school visit to the Port Chalmers Museum with teachers. They have decided that they would like to go in October some time. Mary gets on to the web and types in the Museum URL. She clicks on the schools link and is presented with 2 options. One is to make a booking and the other is to request information.
They include booking a school visit, asking for information and contacting the museum. Mary decides that she will make a tentative booking for October 20th. She completes the required information in the booking form, ticks the box that says the booking will be confirmed by phone and clicks on the button to send the information. An email is sent to the museum.
She then downloads an information package as a Word document to present to the Principal for approval.
Researcher Bill Baxter is a historian that has used the museum many times for gathering information for his historical booklets. He has been frustrated many times by having to wade through mountains of paper in his search for facts. Bill can now access limited information from museum via a web site but if he goes to the museum he can have access to the database of information on site.
Bill decides to go out to the museum today to do some research as he is sure that he will still have to look up files. Bill arrives at the museum, walks into the office and is greeted by Peter Cole. Within 10 minutes Bill is sitting at the computer designated for researchers and begins to search the databases. The newly related databases make his job much easier although there is lots of information that is still contained in paper documents.
He is amazed at how related information is displayed and he immediately realises that it is a vast improvement on the old system. Peter has warned him that the museum has a lot of work to do to capture all of the information that is on hand. Although this will mean that he must still come to the museum occasionally it still makes his general research easier.
Iteration Two/Tasks
| Task |
|
|
Tasks are what happens to functional requirements when you mix them with people. For each we carry out an analysis of that task. It is important that the descriptions are from the point of view of the person, not the computer.
e.g.: if the task was to brush your teeth, then focus on the sequence of steps, the clean feeling etc, not how bendy the toothbrush is.
Analysis checklist[edit | edit source]
| Task: | Task number and name - descriptive and concise |
| Function(s) | Function(s) being carried out relationship with other tasks |
| Viewpoint: | Which user is doing it |
| User analysis: | What are the characteristics of the users in this task e.g. Skills experience |
| Environment: | In what environment will the task be carried out; Physical - office noise lighting, Social -stress confidentiality |
| Pre-requisite knowledge: | What does the user need to know before carrying out task: may be information e.g. student ID number or skills e.g. training in SMS |
| Priority: | high/med/low |
| Frequency: | How often is this task carried out by this user group Eg Once a day, twenty times per hour |
| Duration: | How long does this task take eg 5 minutes, one hour |
| Fragmentation: | Does the task consist of several short tasks or must it be completed in one session? Describe which. |
| Independence: | Is the task dependent on other tasks or can it be carried out in isolation from other tasks? |
| Task performance criteria: | How can we measure how well the task is being carried out? From human point of view - measurable standards e.g. Size of queues, satisfaction, accuracy of results |
| Typical use: | Describe the task, what steps are carried out (bullet points)
Make sure this is from the point of the user. Avoid specific reference to computer terms. |
| Variants: | List of variations on the task - user error, change mind, machine eats EFTPOS card |
| Associated tasks: | List very similar tasks by number and name same task - different user group same task - different environment |
Worked example[edit | edit source]
| Task: | Enroll student |
| Function(s) | Function Student enrollment carried out at Customer Services, student at desk. |
| Viewpoint: | Customer Services staff member |
| User analysis: | Trained and experienced in use of SMS, confident computer user,good customer skills. |
| Environment: | Front desk reception, good lighting and layout. Could be busy, noisy, pressured for time. Dealing with confidential information at times. |
| Pre-requisite knowledge: | Student needs to be already entered in SMS (contacts task), POS complete and signed, user trained in SMS |
| Priority: | med - varies with peak times, impt to be efficient if student is waiting for enrollment. |
| Frequency: | Very frequent but varies with time of semester, time of day. 10 per hour in first week of term. |
| Duration: | 5-10 minutes |
| Fragmentation: | Several stages involved, data can be saved at any point and enrollment completed later. All data from enrollment form needs to be entered for completion. |
| Independence: | Dependent on contacts task. Can be completed at same session. |
| Task performance criteria: | Speed of processing, feedback from students, feedback from departments, backlog of enrollments not processed. Error free. |
| From human point of view - measurable standards | e.g. Size of queues, satisfaction, accuracy of results |
| Typical use: |
- collect information from student - find student in SMS - enter details from enrollment form - enter details from POS form - check validation - Visa, birth certificate etc - complete enrollment - print docs for student |
| Variants: | information incomplete - no validation, student not in system, student data not matched to system data |
| Associated tasks: | enrollment - back office - student not present
online enrollment process |
Iteration Two/Interaction design/Data model
Bite:
Time:
Input:
Process evidence: Client:
Data is...
Why do some argue is most important thing:
Static structure of system
- like a map
Advantages of database approach Program-data independence Minimal data redundancy Improved data consistency Improved data sharing Improved data quality Reduced program maintenance
Difference between data model and database
Modelling process
Data modelling is DESIGN Creative solutions needed Data model is one solution to req’s
Data modelling is IMPORTANT Need a blueprint to build a house
Data modelling is a discipline Professional judgement required
Entity relationship model:
Detailed graphical representation of entities and associations
Focus is purely data Not what happens to it Depicts the form of the data Not the data values Specific to the needs of the business
Person, place, object, event, concept
that is of interest to the organisation
single, unambiguous names
Student, book, product
Time Space Fuzzy
Association between the instances of one or more entity types name strongly make a sentence to describe the relationship may have attributes – an associative entity
A book is borrowed by a patron A patron may borrow a book
Conceptual Schema A detailed, technology independent specification of the overall structure of a database Physical Schema Specifications for how data from a conceptual schema are stored in a computer’s secondary memory
Each entity is described by attributes. These are what we use to describe the instances of each entity. There are strict rules about attributes, they need to be independent and not repeating information. They also need to be atomic (can’t be broken down), and not be dependent on other values.
In the example below, StudentName is unsuitable as it can be broken down into first and surname; StudentAge isn’t necessary as it can be calculated (putting it in by hand is asking for trouble), and StudentGrades is not atomic - ot contains multiple values - which will not work (we’ll come back to this one).
We also need some way of uniquely identifying each instance, this becomes the Primary key for the entity. This has to be not change be unique. We could use the name but, despite us all feeling special, our names aren’t. We could combine the name with date of birth and make a concatenated key. Unfortunately, dates are very difficult to deal with (what is the significance of the 12th of September?) and it doesn’t resolve our non-unique problem (Sam went to school with two Jacqueline Clare Robertsons, both born on 30/7/69). So we have to use a new value: a STUDENT_ID.
We can get the same information from these attributes and the data is structured much more powerfully. The courses a student is enrolled in is more difficult to solve, but the solution is the heart of the power of a data based (and hence database) approach to understanding the business and implementing a solution.
In the example above Bob is taking only Geography (wise choice), so that is easy to deal with. Jane, however is taking French, Geography and History. If we try and store this information in an attribute called Courses it is very difficult to extract this information - while it would be easy to get a list of Jane’s courses, a list of who is taking Geography would be very hard to extract (and involve string manipulation etc).
The real strength of data modelling, is in the identification of relationships. A relationship describes the association between entities.
We can see that there are clear relationships between STUDENT and COURSE, and COURSE and TEACHER. These associations can be expressed as sentences: “a STUDENT takes this COURSE”, “a COURSE is taught by a TEACHER” (we’ll come back to cardinality).
The STUDENT - TEACHER association, however, is not so clear. The relationship (at least the one we are considering here) is already expressed by the model. We can extract which teacher is teaching which students via the COURSE they are teaching and enrolled in. We don’t need a STUDENT-TEACHER relationship.
Even that this level of consideration, we a being forced to carefully think about the business we are dealing with. We could have described a STUDENT-TEACHER-COURSE model. Why have we chosen not to have the STUDENT-TEACHER relationship rather than not having STUDENT-COURSE?
We can also express the numbers of instances that might be involved in the relationship. Here we have “many STUDENTS may take many COURSES”, or conversely “many COURSES may be taken by many STUDENTS”. We express the “many” on our diagram with a “crows foot” (hanging on to the many end). Unfortunately, this gives us a none-specific relationship, we know we have lots of students and lots of courses, but not who is taking what.
One solution to these unconnected lists, is to include attributes for each of the courses someone is taking (below)..
Unfortunately this doesn’t work either. What happens when someone enrolls in more courses than you have previously thought of, where do the results actually go, and we still don’t have a way of finding out who is enrolled in Geography.
What we need is a new entity to represent this relationship. This is called an associative entity. We might have identified it earlier as it is really quite strong in terms of ‘thingness’. The relationship between STUDENT and COURSE also has several parameters in its own right: date, result, perhaps internal assessment grades and so on. The fact that the relationship has attributes indicates that it is really an entity.
Again, we come back to the value of this process in understanding the business. Is it just one entity? We can think of several possible names for the entity - are they the same thing.
There are cases where multiple names indicate multiple associations - the Human resources manager authorises payment of salaries (one relationship), but is also on the payroll herself.
This middle entity shows the association between STUDENT and COURSE, ENROLMENT.
When we implement the model, the ENROLMENT entity (table) does not contain the student’s names, nor the courses - the computer can quite efficiently go and get them. Instead we just use the primary keys from the other entities - they become foreign keys.
There is though, a flaw in our model. Jane Smith seems to be enrolled twice in History. This is not a mistake (except for Jane) - she failed it the first time. In order to allow this to happen we need to represent more information, the year of enrolment. Our model can generate the information required, it will be useful as the development progresses as we work to make it more tightly defined.
The primary focus in functional requirements is the process itself, by developing such a model, we are forced to think carefully about the business we are working with.
Examples[edit | edit source]
Data Model 2 Interface[edit | edit source]
No magic
Iteration Two/Interaction design/Interactivity
| Case study Kaikorai Stream Livetime
|
|
Group: for Simon McMillan, Kaikorai College
Kaikorai College straddles an urban stream. Dr Simon McMillan has a long running project to reconnect the community with the environment - using the stream as a catalyst. This project aimed to provide links between the educational curriculum and the stream. Functional requirements included:
The real time graphs can be configured by students to help answer questions that arise from questions in science, social studies etc.
|
Iteration Two/Test based development
Needs an intro to test based development
| Case study Use your noodle
|
|
Group: Gena Salmon, Michael Brown and John Stefani for Iain Bonney
During implementation the group kept detailed test logs.
|
Iteration Three/Style guide
| Case study Inventory Management
|
|
Group: Micheal Yee, Russell Craig, Che Campbell for Ace Suit Hire
|
| Case study Northern Cemetery
| |||
|
Group: Christine Rout, Daniel Butel, Meikle Skelly
This project aimed to provide a resource for a heritage tourism trust. The project was essentially a dynamic webpage for a cemetery but with several added complications, primary among these the 18,000 historical records to manage. The group made a static webpage quite quickly and extensively used several versions of this in communication with the client, from this the group developed the functional requirements. The client was happy and the group “just needed to make prototype robust”. They then proceeded to develop the prototype – making dynamic and adding “functions and polish”. After following this path for about six weeks, the group realised that were heading down a dead end. The approach to development was not working as the client was becoming distracted by details of the prototype (comments on font etc when they were trying to discuss functions), and a realisation that they had missed the logical design steps of task analysis, interactivity design etc. The group then stopped development of the prototype and then went through logical and physical design properly. Going back through these stages highlighted assumptions they had made with the prototype, they had assumed an encyclopaedia approach but a story approach focus was much better. The wireframe designs allowed focus on content.
The group realised early on that the system would be a dynamic webpage. Early in the project (while redoing the logical design) they developed a structure that provided a stable platform for development: a database with read/write/edit that generated webpages in the required language. In the third iteration the group developed style guides to determine the look of each page. From there it was a relatively simple implementation to combine the stable platform and the style guides to produce the finished product.
|
Resources
This section isn't staying like this. It is a staging area for the rest of the book.
Eventually a chapter called resources will contain blank templates for activities throughout the book.
Butterfly[edit | edit source]
Environment report[edit | edit source]
Environmental report
The environment the project will be finally used in, will vary from very quiet when only a few people are viewing it, to very noisy when a school trip views the exhibit. The target project audience is most likely to be very noisy when in numbers. The overall temperature will be fairly constant due to the air conditioning required by the butterflies. Lighting will also be constant, as the project will be indoors, and can be easily controlled. In the habitat there will be a constant temperature of around 28 degrees Celsius with 90% humidity with the temperature only dropping slightly over night. There should be no obvious problems caused by the climate due to the fact that any hardware will be contained entirely inside or entirely outside the habitat.
Alternative matrix[edit | edit source]
Alternative Solution - Matrix Analysis[edit | edit source] | |||||||||
| Tithlyon Solutions- Decision Matrix | |||||||||
|
Project Digifly |
Popup Book/ Text Book | Interactive Exhibit | Interactive DVD/CD rom | Video Documentary | Virtual Reality | ||||
| Functional Requirements | Priority | Weighting 1-10 | ' ' | ||||||
| Allow the museum to have an interactive software activity based on butterflies | Essential | 10 | 40% | 100% | 90% | 40% | 100% | ||
| Allow people to create their own virtual butterfly | Essential | 10 | 10% | 100% | 100% | 10% | 100% | ||
| Allow a butterfly entered into the database to be retrieved by its creator | Essential | 9 | 0% | 100% | 100% | 0% | 95% | ||
| Butterflies shall fly and move around and interact with the environment | Essential | 6 | 50% | 95% | 65% | 80% | 100% | ||
| Butterflies will be deleted off the database after a set amount of time | Essential | 7 | 0% | 100% | 80% | 0% | 100% | ||
| Must cater for ages from 10 and up | Essential | 9 | 50% | 95% | 95% | 75% | 80% | ||
| Flexible enough to handle a different topic | Useful | 3 | 0% | 100% | 80% | 0% | 100% | ||
| Give users the opportunity to take something home that relates to the exhibit | Useful | 3 | 50% | 100% | 100% | 50% | 70% | ||
| Must have a shutdown procedure for when the power is turned off | Essential | 10 | 0% | 100% | 100% | 100% | 100% |
| Have a type of screensaver | Essential | 10 | 0% | 100% | 100% | 100% | 100% | ||
| Show the natural life cycle | Essential | 10 | 100% | 100% | 100% | 100% | 100% |
| Easy To use (For the public) | Essential | 10 | 100% | 100% | 80% | 100% | 50% | ||||||||||
| Total | 107 | 31.78% | 99.30% | 92.94% | 63.60% | 92.38% | |||||||||||
| Constraints | |||||||||||||||||
| Should not appear as a computer to users | |x||x | ||||||||||||||||
| Offer the user a reason to return | | | ||||||||||||||||
| Be able to handle up to 300 – 1000 people a day | |x | ||||||||||||||||
| Be completely robust | |x | ||||||||||||||||
| Function normally within a 28˚C and a humidity of 90% | | | ||||||||||||||||
| Run unattended and require little as possible maintenance | |x|
|
Show version number etc on start-up |
|
Visual relationship between display areas |
|
|Meets constraint | |||||||||||
| 'x' | Breaks constraint | ||||||||||||||||
storyboard[edit | edit source]
Storyboarding was vital to our development. As we all hated documentation, we used storyboards as often as possible which saved a lot of time and misunderstanding as we could all see what others were thinking.
Interface storyboards had multiply stages where many details were changed and many potential problems were found. Most of the storyboarding was done in the first three months with almost post storyboards done on whiteboards in the main being small modification to the original storyboards
The following storyboard was used for presentation to show the client an overall design concept and to illustrate our current understanding of the interface requirements. The final product has two main changes from the following storyboard, there is no VR section instead there is a third person flyer section and the projection display has become the final section. Nether of these changes require any storyboarding to implement so no was ever made.
Functional requirements[edit | edit source]
Functional Requirements
| REQUIREMENT
THE SYSTEM SHALL||DESCRIPTION | ||
| FR 1 | Allow the museum to have an interactive software activity based on butterflies. | The museum provides a learning experience for museum\’s visitors. |
| FR 2 | Allow people to create their own virtual butterfly. | Features will be provided to allow people to design their own butterfly. |
| FR 3 | Allow a butterfly entered into the database to be retrieved by its creator. | A database will keep butterflies so that people can come back and see them again. |
| FR 4 | Limit the amount of time a user can use the system. | To keep the line moving so many people can use the system. |
| FR 5 | Appeal to both adults and children. | The need to appeal to the greatest number of people is an import factor |
| FR 6 | Butterflies shall fly and move around and interact with the environment. | To make the display interesting to watch and a better overall experience |
| FR 7 | Butterflies will be deleted after a set amount of time. | To free up resources for more butterflies and to complete the life cycle. Database files will remain but de-activate because it is bad practice to delete any thing of a database. |
| FR 8 | Show the natural life cycle. | The complete life cycle of a Butterfly showing the four major stages |
| FR 9 | Cater for ages 8 and up. | Able to be used by most people above the age of 8 without aid. |
| FR10 | Flexible enough to handle a different topic. | The overall design should be able to handle being changed to display another concept |
| FR11 | Give users the opportunity to take something home that relates to the exhibit. | The museum wants their visitors to have something physical to take away to inform whilst advertising the museum and the tropical house so as to generate new and repeat visits. |
| FR12 | Must have a shutdown procedure for when the power is turned off. | There are many powered displays in a museum. A shutdown sequence is more complex than a switch therefore its desirable. |
| FR13 | Must have a start-up procedure for when power is turned on. | The same as shut down. Power on is as complex a task that should be ask of museum staff when start the display. |
| FR14 | Have a type of screensaver. | Screensaver will be needed because the monitors will be running for long hours. Also there is a need for a "screen saver" loop to entice and inform users to the product. |
| C1 | Should not appear as a computer to users. | Most people find computers can be intimidating, boring or common. All of which are not aspects that are likely to enthral users to interact with them. |
| C2 | Run unattended and be maintenance free. | Due to the fact that there will be very little maintenance available for long periods of time, there is a great need for the system to run without the need of regular attendance. |
| C3 | Be completely robust. | Able to withstand the wear and tear of a museum interactive exhibit. |
| C 5 | Show version number etc on start-up. | A version number is needed so there is no confusion to what version of software/ hardware is currently operating. Important when servicing or upgrading software. |
| C6 | Function normally within a humid and varying environment. | 28˚C and a humidity of 90% are the conditions within the butterfly house. The system may also be installed for a time in the museum foyer other areas which may have varying conditions. |
| C7 | Be able to handle up to 1000 users a day. | The number of visitor to the museum is very erratic due to the likes of holidays and weather. It is also common to have large group visits such as tour or school groups. This mean that the system may have times that it is constant use throughout a day or not at all. |
| C8 | Offer different levels of information | Able to cater for those who want to know more. |
| C9 | Offer the user a reason to return | Some reason that a user will repeatedly return to the exhibit. |
Taxi[edit | edit source]
Locked in to an expensive software system Historical Data remotely stored and not easily accessible or adjustable Upcoming legislative requirement to have historical records of all booking and dispatch data
Data Dictions[edit | edit source]
Booking Table The booking table is used to store information on specific bookings, which are later referred to on the job table if they successfully become jobs. There are 2 relationships to the Address table, one to reference a pickup address , the other to reference a destination address. There are also 2 relationships to the shift table one to record the operator who made the booking, and the other to record the dispatcher who assigned the job. Relationships Address 1..N Booking (for pickup address) Address 1..N Booking (for destination address) Shift 1 .. N Booking (for Operator) Shift 1 .. N Booking (for Dispatcher) Shift 1..N Booking (for Taxi)
Booking.BookingID General Information This field is the primary key of the table. It is used mainly to reference itself to records on the job table. Values This field contains integers Source On creation of a record the value is automatically assigned by Access Technical Specifications Data type: Autonumber Must be unique: Yes Default value: Assigned by Access Primary Key
Booking.PickupID (Address.AddressID) General Information References an address from the address table to be the pickup address for the booking Source This data is entered when the operator creates a record. It can be edited later. Technical Specifications Foreign Key See Address Table for more information Booking.DestinationID (Address.AddressID) General Information References an address from the address table to be the destination address for the booking Source This data is entered when the operator creates a record. It can be edited later. Technical Specifications Foreign Key See Address Table for more information
Booking.BookingCustomerName
General Information
Stores the name of the customer who made the booking
Values
This field may contain any text up to a limit of 255 characters
Source
This data is entered when the operator creates a record. It can be edited later.
Technical Specifications
Data type: Text
Must be unique: No
Default value: NULL
Address.AddressShortcut General Information Stores shortcuts used in the front end by operators to quickly reference popular public places. Values This field may contain any text up to a limit of 10 characters Source This data is managed in a special interface by a control room supervisor Technical Specifications Data type: Text Must be unique: Yes Default value: NULL
Address.AddressCustomerName
General Information
Stores a customer name associated with the address.
Values
This field may contain any text up to a limit of 255 characters
Source
This data is entered when the operator creates a record. It can be edited later.
Technical Specifications
Data type: Text
Must be unique: No
Default Value: NULL
Booking.BookingTaxiShiftNumber (Shift.ShiftID) General Information This field references a shift of the taxi that does the resulting job Source This data is entered when the dispatcher gives the booking to a taxi as a job Technical Specifications Foreign key
See Shift Table for more information
Booking.PostDispatchNote
General Information
This field contains any notes the dispatcher enters regarding the dispatching of a job
Values
This field contains any form of text up to a limit of 255 characters
Source
This data is entered when the dispatcher gives the booking to a taxi as a job
Technical Specifications
Data type: Text
Must be unique: No
Default value: NULL
Bulk Documentation[edit | edit source]
Group Management Contract
The members of innovate.It shall meet as following:
• Monday from 3:30 onwards (approx 5 hours) • At least one other night of week as pre-arranged (approx 2.5 hours)
In addition the team members will complete at least 2.5 hours of work in own time.
If circumstances lead to the above not being possible then arrangements will be made to make up the time.
Communication • Either member will communicate with the lecturer/client • Presentations will be done as a group • Any meetings conducted with stakeholders/users will require project representative to take detailed notes to take back to the group and filed in a central document holder • Communication amongst team members will be via email and text messaging, using Blackboard as a common information system • Team members must communicate with each other at least once a week • Team members must ask for clarification over any points of confusion – move forward as a team not as individuals • Team members should be comfortable in sharing ideas and have them listened to and discussed by the team • A monthly progress report will be furnished to the client following a set template (located in Blackboard), outside this time, contact will be made as necessary • Client to provide at least monthly feedback following progress report
Procedures • Documentation standards – standard formatting, clear and concise, appropriate use of white space, logical flow of information, headings differentiated from text, table of contents, page formatting/numbering, one font (12pt Times Roman) • Master documents to sit on Blackboard for group access • Hamish to backup documentation from Blackboard weekly (Monday pm) • Standard group logo on all documentation • Images/graphics used appropriately and not for cosmetic effect • Standard of final document to be checked by an independent person yet to be decided upon and based upon relevant experience • Deadlines: use steering sheets, set out each step and save on Blackboard for group access • Presentations: all work presented will be as simplistic as possible and will include all key points
Management
• The group shall adhere to the same Code of Ethics as outlined by NZCS eg assure competence, responsibility, accountability, good practice, moral standards, understanding and management of risk, perception by others, integrity and loyalty, reliability, confidentiality.
• Our proposal outline to the client shall include objectives and deliverables. We will identify required resources and follow the project plan as outlined to the client. Any revisions shall be explained as soon as possible. Documentation will be reviewed before final presentation.
General Strategies • Communication with all stakeholders will be transparent and regular • Any problems that arise that cannot be sorted by the group will go to mediation with lecturers. • Any resources needed will be obtained by negotiation from either Otago Polytechnic or the client.
Abandonment • A team member should be considered to have abandoned the project if they do not make contact with the Project Supervisor or other team member for a period of three weeks, unless advance notice has been given. • Upon abandonment the offending member will surrender all project material and status to the remaining member. • Any replacement members appointed may inherit material and status of project to that point, at the discretion of the Project Supervisor. • If client abandons the project then it will be at the discretion of the Project Supervisor to decide whether the project continues with another client, or whether the team joins or starts another project.
Review • Progress will be reviewed; after contact from the client, during each scrum meeting, and during the evaluation stage of each iteration (i.e. review of prototype). • After client contact, a “client contact” form will be completed.
Allocation of Grades • All members will receive the same grade unless a member doesn’t comply to the statutes of this document. Any grade adjustments will be at the discretion of the Project Supervisor.
Project executive summary
The goal of this project is to provide a dispatch system for City Taxis. The Dispatch System should be ready for use as soon as possible.
We are using a methodology that combines iterative and Agile thinking. We believe that understanding grows throughout a project, therefore through the use of prototyping and regular meetings with stakeholders, constructive feedback will be created to ensure the implementation of a successful system. The system should facilitate dispatches and provide historical records.
Main risks identified so far include: lack of compliance to legislation, loss of privacy, inaccurate data, insecure data..
Project Name: Taxi Dispatch System
Team Name: innovate.It Team Members: Hamish Smith, Shane van Dyk
Client: Allan Ward, City Taxis Project Sponsor: Otago Polytechnic Project Supervisor: Sam Mann
Project Description:
Goal: To provide a system that facilitates taxi dispatches easily and successfully, while accurately recording all data needed. 1. Record data of all dispatches accurately 2. Provide current status of dispatches easily 3. Track status of all taxis 4. Complete all dispatches in a timely manner
Section Two: Business Outline Business statements City Taxis provide transport around the “Greater Dunedin Area”, whether it be for sightseeing, corporate or pleasure.
City Taxis has been providing Dunedin with quality transport services for 55 years.
They are the preferred Taxi Company for all of Dunedin’s leading hotels and motels. Are also the preferred carrier for many of the City’s leading businesses.
Whether the cost for your taxi is a personal expense or is charged to your business or employer, in these days of prudent accounting it is the sensible choice to select that carrier who will deliver quality service at an economical price. City Taxis will do this for you.
Client Mission Statement: We provide a quality service with a fleet of modern vehicles and highly qualified drivers.
We strive for to be the best and nothing less.
With over 55 years of service to the people of Dunedin, we at City Taxis are committed to offering our customers the very best service and value for money.
Section Three: Methodology Project Methodology
The Agile methodology encourages realistic schedules and resource allocation, allows for changing requirements and technical complexity of projects. It also takes into account technical shortfalls of group members and access to appropriate technology. Phased life-cycle approach to help the group realize what activities are to be undertaken, what deliverables for each stage may be, enable different types of communication between activities and different stages, determine whether deliverables of each stage are satisfactory prior to proceeding to the next stage. The relative quickness of each cycle means that the team and client are revisiting the stages of the project a number of times, and therefore there is a higher probability of completing a project that satisfies the client. This also allows the flexibility to adjust to the changing client/ project needs. Regular use of “Scrum” meetings (15 minute regular meetings between team members, and client) facilitates a high standard of communication between team members and the client, and keeps the focus on what is happening next and who is doing what. The use of prototypes allows the client to kinesthetically experience the development of the project at regular intervals. This promotes constructive feedback from the client, and increases the probability of the project moving in a direction that meets the stakeholders requirements. Because construction and evaluation is happening throughout the project, there is a greater likelihood that the finished product will meet the stakeholders’ needs. Understanding is not expected to be obtained by all parties early in the project. It is expected that as all parties are involved in a constructing, evaluating process; understanding will continue to growSection
Project Outline
Project Description
City Taxis needs an improved dispatch system that facilitates taxi dispatches easily and successfully, while accurately recording all data needed. The main hub of City Taxis consists of phone operators and a sole dispatcher. The phone operators deal with customer bookings. The dispatcher allocates the jobs and communicates with the drivers. The current system seems to facilitate the dispatch jobs quite well in the office environment, but at a high financial cost. The current communication system between the taxi drivers and the main office, seems to have time delays and distracts the drivers more than what is considered necessary. The ability to store data that is easily accessible is paramount, as future legislative requirements specify that certain data is accessible by police. The immediate desire of the client is that a system is put in place that accurately records the dispatch data for future reference, while providing an easy to use front-end interface.
Project risks Software development is intrinsically risky and uncertain which is why we need clear and measurable goals at the start of the project. The main project risks include the inability of software to perform to expectations of users and the inability of software developers to produce a working or functioning system for users. Also:
• Failure to gain user commitment • Lack of adequate user involvement • Misunderstanding user requirements • Failure to manage end user expectations • Conflict between different users • Inadequate user training • Running out of time
Green Card, Red Card Early on in the process we left a card system for City Taxis staff to use to comment on their current system. Things they like could be written on green cards, things for improvements on red cards.
Discussion 23 July
• A booking always requires a phone number and a name • Situations are going to occur where there is no street address. In this case, the pickup needs to have a location which is to be given a suburb and an area • In theory, it doesn’t matter if there are duplicate location entries in the address table • Shortcut do not dynamically updates, and would have their own interface for editing • Instructions is an optional field • Address numbers are not compulsory • Rules that apply to pickup also apply to destination • Vehicle type is an optional field and by default is blank • Time required is compulsory and defaults to current time • Number of passengers is optional • Large boot is to be removed from the form • True value for Bike Rack will generate “, Bike Rack” to be concatenated into the vehicle type field of the dispatch screen. This happens when dispatch data is generated • A booking requires both a pickup and a destination
Current State of Booking Form • Data does not get recorded properly if there is no street name • There are currently no booking validation processes, anything appears go in regardless of how little data there is, although no data is created if some pieces of data are missing • If a blank booking is made no data goes through, yet the dialog “Booking Saved” is displayed • A booking requires a pickup and a destination address otherwise no new data is recorded
TaxiDispatch Functional Release
13 August 2007
Before going to City Taxis I made a last minute change to the code on the booking form to make phone numbers optional. This suits their needs at the moment better.
On arrival I split the database putting the backend on a folder on the computer to be used as the dispatchers workstation, mapped as the “T: drive” on City Taxis’ local area network. I packaged up the frontend into an install file, and had the setup file created to a shared folder on our polytech computer. The program was installed on all machines on the City Taxis network and testing began.
Problems and suggestions arising from the test included: • Dispatch job screen not working correctly. Jobs will not clear if there is more than one on the screen. This is probably nothing more than a programming bug. • The are delays experienced after saving a booking or clearing the booking form of around three seconds. Most of the time this is OK but could be a problem during busy times. Even so at any time a three second delay is long enough to be annoying. • There is no ability to cancel a booking. • We haven’t facilitated for different vehicle types. No restrictions are imposed, meaning a booking can be made for 6 passengers in one car even though this is not physically possible. • The drop-down boxes to help with address details do not work with the down arrow key. • Special instructions do not appear to be going into the database. • Various corrections to the street database and additions to the list of location shortcuts were made, some still need to be made. • A suggestion was made for the next release that the dispatcher needs to be able to reposition a car on the board at any time.
I spent the first hour or so showing the booking form to the staff on duty and supervised their usage thereof. Afterwards I sat at the dispatchers desk watching dispatchers and generally made myself available to write down suggestions, comments, and problems. Some problems with data I was able to fix instantly on site using the polytech computer to access the backend and edit data on tables directly.
Order of Development
• Look at dispatch board and discuss wireframe interfaces • Design wireframe interfaces • Paper based prototype • Design options • Platform discussion • Create basic prototype • Make platform decisions • Task analysis • Detailed interfaces • Back-end development/migrating • Creation of logical procedure layer • Building/modifying booking front end • Building/modifying dispatch front end • Building/modifying historical and configuration front ends • Data dictionary • Technical documentation • Software manual • Help structure • Testing • Testing on site • Live robust release
Ruled Out • Physical Board: not practical, does not fit in with needs of client
Combination Options: 1. Access tables + Access queries + Access forms 2. SQL Server + Access queries + Access forms 3. SQL Server + Stored procedures (SQL server) + Windows application 4. SQL Server + ColdFusion + HTML 5. Access tables + ColdFusion or PHP + HTML 6. SQL Server + ColdFusion or PHP + Google Maps
Ruled Out • Option 6: Google maps does not match up with the requirements of the wireframe interface • Options 1 and 2: These options use Access forms which do not practically support the features of the wireframe interface • Options 4 and 5: These options use HTML as a front end. This does not have a proper coding environment, and would make for complicated and difficult attempt to support our wireframe interface
Leaving • Option 3: SQL Server + Stored procedures (SQL Server) + Windows application
The SQL server is the best suited backend because, unlike Access, it is designed for a multi user environment and has better stability and facilities for backups. It is also less restrictive in what we can do with the data.
Stored procedures on a SQL server would make a good logical layer because they are held close to the actually data, and once it is created it will make front end development much easier. There is bigger scope for customised procedures to fit in with the needs of the front end.
A standalone windows application is also the best platform with which to make a front end, because as we will be designing and building it ourselves, we can make it meet our requirements. Microsoft Visual Studio is probably the best environment to code with, as it will have facilities to connect with a SQL server data source.
Your Fashion[edit | edit source]
1. The system shall store user profiles (user has to be a member with username and password to use the website and create a profile) 2. The system shall give tailored feedback 3. The system shall store user purchase history 4. The system shall be an ‘expert’ system 5. The system shall be comprised of web-based components 6. The system shall incorporate a virtual community/forum 7. The system shall have an online auction for second hand clothes 8. The system shall save search parameters 9. The system shall ‘intelligently’ provide targeted promotional offers 10. The system shall access the retailer’s items database 11. The system shall display the store’s relevant products 12. A user shall be able to rate other users’ profiles regarding clothing choices 13. That users can edit their profile 14. That users can delete their profile 15. The system shall provide users with the option of producing multiple profiles 16. The retailer can upload new clothing lines at anytime 17. The system shall allow users to view other users’ profiles if the user agrees to this option 18. The system shall incorporate quality graphics with plenty of white space to promote ease of use 19. The system shall allow for updates while still being used online 20. The system shall notify developers of any downtime eg message output “Screen B in Retailer XY, 111 George Street is not responding” 21. The system shall be portable using mobile platforms eg cellphone, PDA, MP3 player (therefore profile file size is important) 22. The system shall be able to build a profile online using a 56K connection 23. The system shall be able to send targeted text messages using Bluetooth technology 24. Users shall be able to search on past purchasers (eg bought within last 3 months, 6 months, 12 months, etc) 25. Users shall be able to append their wardrobe items to build upon their profile (may need to be capped eg 50 garments using low resolution images) 26. The system shall limit suggestions to top five rated out of all possible combinations according to the user profile 27. A user shall be able to continually build upon their profile by adding information eg making additions to the virtual wardrobe 28. Retailers shall be able to use the system to send purchase suggestions to targeted user profiles (eg women aged 30-35 who earn >$35,000pa and are pear-shaped with fair skin) 29. A user shall be able to search for wardrobe suggestions online via advanced searches eg particular style, retailer, price, etc 30. User shall be able to view generated fashion items, interchangeable with other suggested items 31. User shall be able to text suggested outfit to others requesting feedback (using 3G technology eg Rate this outfit for me please = 1,2,3,4,5) 32. The system shall be able to weed out bogus profiles (eg non-proportional biometrics provided by users to create unrealistic profiles)
The above diagram also shows the coathanger concept where coathangers are used to rate each item. The more green hangers an item has the more suitable that item is for the user, and the more red hangers an item has, the more unsuitable that item is for the user. Hangers can also be half green and half red as the hanger rating comes off a suitability index so an item can be 3.5 coathangers out of 5. We looked at using a colour slider bar for ranking items but decided to go with a star rating (using coathangers as that is unique) instead.
