Possible incorporation of Prototyping in the Conventional Approach to Systems Development FEASIBILITY STUDY REQUIREMENTS ANALYSIS SYSTEMS ANALYSIS SYSTEMS.

Slides:



Advertisements
Similar presentations
Lecture 3 Planning and Development Methodologies.
Advertisements

Information technology solutions development Fundamentals of Information Technology Session 3.
ICT Class System Life Cycle.  Large systems development projects may involve dozens of people working over several months or even years, so they cannot.
Systems Analysis, Prototyping and Iteration Systems Analysis.
Chapter 12 Systems Development Three common methods for MIS development: The systems development life cycle (SDLC) Prototyping End-user development Five.
The System Development Life Cycle
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
System Analysis and Design (SAD )
Lab/Sessional -CSE-374. SYSTEM DEVELOPMENT LIFE CYCLE.
Chapter Twelve Approaches to Systems-Building. The Traditional Systems Lifestyle The systems lifecycle is a traditional methodology for developing an.
Chapter 6 Prototyping, RAD, and Extreme Programming
Chapter 8 Prototyping and Rapid Application Development
MSIS 110: Introduction to Computers; Instructor: S. Mathiyalakan1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Lecture Exam Monday, March 27th 5:30 – 6:30 l bring a blue bubble sheet l lab sections 10, 11, 12 take test in Classroom Building 302 l lab sections 13,
Karolina Muszyńska Based on
SDLC. Information Systems Development Terms SDLC - the development method used by most organizations today for large, complex systems Systems Analysts.
Introduction to Systems Analysis and Design
THE SYSTEMS LIFE CYCLE ANALYSE DESIGN IMPLEMENT MAINTENANCE IDENTIFY/INVESTIGATE.
Agile Modeling and Prototyping Systems Analysis and Design, 7e Kendall & Kendall 6 © 2008 Pearson Prentice Hall.
1 Building and Maintaining Information Systems. 2 Opening Case: Yahoo! Store Allows small businesses to create their own online store – No programming.
Tietojärjestelmien peruskurssi Systeemisuunnittelu ja prototyyppimenetelmä Malin Brännback.
Transaction Processing Systems and System Development Life Cycle
Chapter 8: Systems analysis and design
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
Advanced Topics in Requirement Engineering. Requirements Elicitation Elicit means to gather, acquire, extract, and obtain, etc. Requirements elicitation.
11.1 © 2007 by Prentice Hall 11 Chapter Building Information Systems.
Development and Impact of Software Solutions Application of software development approaches.
Principles of Information Systems, Sixth Edition Systems Design, Implementation, Maintenance, and Review Chapter 13.
Requirements Engineering Requirements Elicitation Process Lecture-8.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
Chapter 12: Systems Investigation and Analysis. Agenda  How to Develop a CBIS?  Systems Development Life Cycle (SDLC)  Prototyping  Join Application.
INFO 637Lecture #51 Software Engineering Process II Defining Requirements INFO 637 Glenn Booker.
PROTOTYPING When “systems development” was essentially “programming” then it could be considered that all systems were developed as prototypes forward.
Systems Life Cycle A2 Module Heathcote Ch.38.
IFS310: Module 3 1/25/2007 Fact Finding Techniques.
Systems Analysis and Design in a Changing World, Fourth Edition
Topics Covered Phase 1: Preliminary investigation Phase 1: Preliminary investigation Phase 2: Feasibility Study Phase 2: Feasibility Study Phase 3: System.
Chapter 6 Prototyping, RAD, and Extreme Programming Systems Analysis and Design Kendall & Kendall Sixth Edition.
SOFTWARE ENGINEERING MCS-2 LECTURE # 4. PROTOTYPING PROCESS MODEL  A prototype is an early sample, model or release of a product built to test a concept.
ANALYSIS PHASE Purpose of information systems in organisations Information systems exist in organisations to serve organisations. Therefore the aims.
System Construction System Construction is the development, installation and testing of system components.
Systems Development Life Cycle
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
The System Life Cycle The systems lifecycle is the set of stages that are followed when developing an information system.
Principles of Information Systems, Sixth Edition 1 Systems Design, Implementation, Maintenance, and Review Chapter 13.
Click to add text Systems Analysis, Prototyping and Iteration.
Systems Development AIMS 2710 R. Nakatsu. Overview Two philosophies of systems development –Systems Development Life Cycle (SDLC) –Prototyping Alternative.
1 - 1 Systems Analysis and Design, Key Ideas Many failed systems were abandoned because analysts tried to build wonderful systems without understanding.
Module 4: Systems Development Chapter 13: Investigation and Analysis.
Chapter 2 – Software Processes Lecture 2 1Chapter 2 Software Processes.
Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2010 Stephen R. Schach
5. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Describe the activities of the requirements discipline  Describe the difference.
The information systems lifecycle Far more boring than you ever dreamed possible!
Public Management Information Systems System Analysis & Design Saturday, June 11, 2016 Hun Myoung Park, Ph.D. Public Management & Policy Analysis Program.
The System Development Life Cycle
Information Systems Development
Information Systems Development
Building Information Systems
Prototyping Lecture # 08.
James A. Senn’s Information Technology, 3rd Edition
Systems Analysis and Design
Information Systems Development
The System Development Life Cycle
Methodologies For Systems Analysis.
CHAPTER 10 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT
Public Management Information Systems System Analysis Thursday, August 01, 2019 Hun Myoung Park, Ph.D. Public Management & Policy Analysis Program Graduate.
Presentation transcript:

Possible incorporation of Prototyping in the Conventional Approach to Systems Development FEASIBILITY STUDY REQUIREMENTS ANALYSIS SYSTEMS ANALYSIS SYSTEMS SPECIFICATION IMPLEMENTATION MAINTENANCE REVIEW economic social operational technical interviewing observations questionnaires record sampling working methods user requirements current system problems prototype design prototype development prototype testing prototype amendment inputs outputs processes files security system meets requirements? new requirements? continue to function? writing progs testing training installation changeover

PROTOTYPING Prototyping is a technique for building a quick and rough version of a desired system or parts of that system Rapid Application Development by James Martin PROTOTYPE An original or model, after which anything is formed The first thing, or being, of its kind A pattern, exemplar, or archetype Websters 20 th Century Dictionary  Get an idea of what the system will offer  Provide feedback on whether the system is what is required The main objectives of using prototypes is: An approximation of a type that exhibits the essential features of the final version of that type Avison & Fitzgerald p 76

PROTOTYPING Prototyping helps to identify misunderstandings between users & software developers this may help detection of missing (not yet specified) user requirements where the functions and detailed design of a system are not yet fully understood and can be used to explore and solidify the functions and design James Martin suggests a prototype is most useful when: For this purpose, it is far more effective that reviewing paper specifications “a prototype is worth ten thousand words”

PROTOTYPING real manipulatable can be adjusted can be modified For this purpose, it is far more effective that reviewing paper specifications It is also fundamentally different from a paper description: a prototype is: users get a feel for what their system will be like. Its flaws are visible and tangible rather than buried in boring text that the prototype must be part of the evolving system In the RAD lifecycle the expressed intention is: i.e. NOT disposed of, but worked on throughout

PROTOTYPING prototyping ought to be used in the development of all interactive systems Martin suggests, that in particular: when a prototype is reviewed seriously by end users, they almost always change something It is worth noting that: Prototyping does much to solve the problem of inadequate communication between the designers and users

PROTOTYPING prototype suggests an analogy with engineering, where prototyping is used extensively There are, however, fundamental differences between the prototyping of software and the prototyping of machines In engineering, a machine prototype usually takes longer to build and is more expensive than the ultimate product a mass-production line may be used the prototype is needed for pre-testing the product IN SOFTWARE THERE IS NO MANUFACTURING PRODUCTION LINE

PROTOTYPING Prototyping is practical only if the prototype can be built quickly and cheaply Therefore, a software prototype is usually an incomplete or simplified version that has the essential functions of the working system but not the scale or performance James Martin asserts that: there are many pitfalls in prototyping to avoid these, it is essential to incorporate prototyping in the development lifecycle where the procedural structures will aid avoidance of those pitfalls

PROTOTYPING JAD sessions JAD sessions can make very good use of prototypes. The discussions become more tangible between developers and users when their interaction is bridged by use of a prototype It can also be used in the Requirements Planning Phase partial prototypes can help in checking the desirability of a system before committing funds

 There is scope for user creativity to improve the system  Users are unsure of exactly what they want  The system changes a basic business operation  An end-user dialogue should be tried out with the users to see if it can be improved  The users do not understand all the impacts of the new system  The functions are subtle, and the users understand them better than the analysts  Screens and reports should be checked with management to see if they can be made more useful or easy to use  The users have difficulty expressing all the system requirements  The prototype may act as a catalyst to elicit alternative ideas  The relative merits of alternative solutions need to be explored  Experimentation may be done to achieve better business practice Prototyping is particularly valuable in the following situations: PROTOTYPING

Prototyping should never be an excuse for casual work in which structured design is abandoned always first build something simple This starts a debate early in the evolution that may flush out misconceptions The initial prototype is successively enhanced With complex systems it is desirable to build the functionality first then polish the human factoring

PROTOTYPING When the prototype is regarded as complete, there may still be much work to do in building the operational system A list of missing features should be made:  Features for recovery from failures  Features for fallback  Security features  Features of auditability  Features for ease of maintenance  Machine efficiency  Facilities for having multiple users  Facilities for high-volume usage with adequate response times

 Larger database facilities  Networking facilities A list of missing features should be made: PROTOTYPING  Operation on a different machine  Documentation A danger of prototyping is that the users, motivated to be excited about the prototype, acquire unfulfillable expectations The advantage is that the prototype can be used to train users so they will be ready when the real system arrives

PROTOTYPING  Users understand and react to prototypes far better than to paper specifications. Often, they fail to understand or miss important points in paper specs  Often it is quicker to build a prototype than to build paper specifications  Prototyping introduces early reality testing into a project. The users can see what is being built for them and critique it  Without, there is a substantial risk of building an inadequate system, wrong features or, at worst, a system the users will reject  It encourages users to contribute creative input into design process  When using or reviewing a prototype, users tend to be unbiased by existing systems Benefits of Prototyping:

PROTOTYPING  Prototyping enables errors and weaknesses to be caught before expensive design and programming are done  Prototypes, or partial prototypes, are of great help in JAD sessions  Prototypes can generate excitement and improve morale of the users and developers  Prototypes are valuable for communicating what is required to programmers  Prototypes provide users with early experience with the system and may be used as training tools  Prototyping can give fast development by having the prototype evolve into the final system Benefits Prototyping:

PROTOTYPING  Quick, casual design may replace well-structured design  The prototype encourages the users to change their minds about requirements. They many continually invent requirements so that the prototype constantly changes and does not converge quickly to an implementable form  The users’ expectations may become too high. The may think they can have the system immediately  There is a temptation to make the prototype the production system, without adequate consideration of security, auditability, fallback, recovery, maintainability, performance, networking or documentation  The user may take the prototype too literally, when the implemented system will be different  The user may be too casual about the prototype and not take the time to identify its flaws Dangers of Prototyping: