1. Tietojärjestelmien peruskurssi Systeemisuunnittelu ja prototyyppimenetelmä Malin Brännback

2. Software Development Process F Idea F Requirements (feasibility study) F Plan schedule F Architecture F Construction F Inspection

3. I R A C I Plan&schedule

4. Idea F From observation, inspiration, experience, or a business problem F This idea is the concept or primary goal for the application u to build a computer game for your children this Saturday afternoon u whether to develop a new contact management system; cost/benefit analysis for why this is a better aid for the sales force –The idea is approved

5. Requirements (part of feasibility study) F A project team is generated from the examination of the idea u set up the scope of the project u define a feature list u specify the limitations and constraints u prioritise the requirements

6. Requirements (part of feasibility study) F The game: rules of the game; how many players F Contact management system; interviewing users, perform a complete task analysis, develop a detailed document of precise requirements

7. Planning and Scheduling F The project plan defines how the project will be accomplished F A rough, high-level schedule and a time line can be estimated F This schedule is based on guesses and not on details because they are developed at a later stage

8. The examples F The game: to do it now and finish before dinner F The contact management system: u a strategy for completing the system u a high-level schedule will be estimated based on that plan

9. Developing the architecture F There is no one right way to design software u There are some requirements and basic laws of physics and engineering, but much latitude with those restrictions F Therefore you need a methodology, which is not a cookbook but a path, as you walk down the path, you use experience and knowledge to create a design

10. Starting construction F Use the architectural design just developed F For the game: you just sit down and start coding F For the contact management system if OO design: u each programmer on the team is assigned a set of classes based on the architectural design and can begin

11. Construction F Initiating the inspection: u code walk through u unit testing u integration testing u systems testing –purpose is to inspect bugs and other errors as early as possible

12. Inspection F For the game: u you pound out some code and give it a quick inspection u pull apart and fix it F For the contact management system: u more intense build/inspect cycle

13. Basis for a methodology F An analysis phase, design to understand the present system and suggest the functional requirements of an alternative system F A prototype phase to construct a prototype for evaluation by users F A set of evaluation and prototype modification stages F A phase to design and develop the target system using the prototype as part of the specification

14. Prototyping F Step-by-step development F validation F an approximation of a type that exhibits the essential features of the final version F The design needs to be tested thoroughly first (mass production; Mercedes) u one-off final versions (bridge building) u IS are also one-off

15. IS prototyping F One-off designs; the cost of building a prototype has been a major proportion therefore rarely included F addresses problems in traditional systems analysis u the user sees the final version - too late u user rejection F response to user dissatisfaction

16. IS prototyping F Improved form of systems investigation and analysis F aid to design F Useful when: u application area is not well defined u the organisation is not familiar with the technology (hardware, software, communications, designs, etc.) u communication between analyst and users is poor u rejection costs are high u assess the impact of the IS

17. Prototyping vs. iterative design F Prototyping used to mean quick and dirty F recently the same as iterative design F two types (Turban) u throwaway u evolutionary

18. Throwaway F Traditional prototyping F make a pilot which is then thrown away and preliminary design takes place

19. Evolutionary F Mini-system that is refined iteratively over a long trial period F Iterative prototyping is sometimes called participatory design

20. Primary features of prototyping 4 Learning is explicitly integrated into the design process 4 short intervals between iteration, fast feedback 4 involvment of users 4 low cost 4 requirements are allowed to evolve (  prototype surprise!

21. prototyping F Special tools u report generators u hypertext F systems prototyping F interface design (horizontal and vertical prototpying F iteration becomes a practical possibility F developed in a few days F Drawback; system requirements may change

22. Other intentions F Discard because: u inefficient u incomplete - performing only some tasks u poorly documented u unsuitable for integration u incapable of holding the number of records necessary u inadequate - designed only for one type of users

23. Usability engineering and prototyping user interface designs F Early usability evaluation can be based on prototypes of the final system. u Faster u cheaper u better understanding of the user interface design F Problems with the waterfall model is that there is no user interface to test until last possible moment.

24. Usability engineering and prototyping user interface designs F It is not possible to involve the users in the design process by showing them abstract specifications document, since they will not understand them as well as a prototype F cost and time savings can only be achieved by reducing the prototype compared with the full system

25. Reducing prototypes F Vertical prototyping; Cut down the number of features F Horizontal prototyping; reducing the level of functionality of the features so that they seem to work - but do not

26. Vertical prototyping F Narrow system which includes in-depth functionality with few selected features F tested under realistic cisrcumstances F videotex system - user can access a database with real data

27. Horizontal prototyping F Full-features system F entire user interface F No underlying functionality F simulation of interface where no real work can be done F Videotex: execute all navigation and search commands but without retrieving any real information

28. Scenarios F Ultimate minimalist prototype in that they describe a single interaction session without any flexibility for the user F A scenario is a word with many meanings. It is a description of u an individual user u using a specific set of computer facilities u to achieve a specific outcome u under specific circumstances u over a certain time interval