Click to add text Systems Analysis, Prototyping and Iteration.

Slides:



Advertisements
Similar presentations
ICT Class System Life Cycle.  Large systems development projects may involve dozens of people working over several months or even years, so they cannot.
Advertisements

©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Systems Analysis, Prototyping and Iteration Systems Analysis.
Chapter 2 – Software Processes
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Chapter 12 Systems Development Three common methods for MIS development: The systems development life cycle (SDLC) Prototyping End-user development Five.
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 Design and Analysis
Software project management (intro ) Project approaches.
Software Processes: Traditional CSCI102 - Systems ITCS905 - Systems MCS Systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Information Systems Development Lecture 2: the idea of the Life Cycle.
Fundamentals of Information Systems, Second Edition
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Problem with Software Requirements are complex The client does not know the functional requirements in advance Requirements may be changing Technology.
Chapter 2- Software Process Lecture 4. Software Engineering We have specified the problem domain – industrial strength software – Besides delivering the.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Software Life Cycle Model
Acquiring Information Systems and Applications
Introduction to Systems Analysis and Design Trisha Cummings.
Commercial Database Applications Testing. Test Plan Testing Strategy Testing Planning Testing Design (covered in other modules) Unit Testing (covered.
1 Building and Maintaining Information Systems. 2 Opening Case: Yahoo! Store Allows small businesses to create their own online store – No programming.
1 CMPT 275 Software Engineering Software life cycle.
Lecture 2 Software Processes CSC301-Winter 2011 Hesam C. Esfahani
Tietojärjestelmien peruskurssi Systeemisuunnittelu ja prototyyppimenetelmä Malin Brännback.
Chapter 2 The process Process, Methods, and Tools
Lecture # 04 & 05 CS314 Introduction To Software Development Software Development Process (SDP) Instructor :Muhammad Janas khan
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
SOFTWARE PROTOTYPING Anil Kumar.Arikepudi.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Software Prototyping l Rapid software development to validate requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Systems Life Cycle A2 Module Heathcote Ch.38.
Topics Covered Phase 1: Preliminary investigation Phase 1: Preliminary investigation Phase 2: Feasibility Study Phase 2: Feasibility Study Phase 3: System.
An Introduction to Software Engineering
Fundamentals of Information Systems, Second Edition 1 Systems Development.
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.
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
Systems Development Life Cycle
Software Prototyping Rapid software development to validate requirements.
Chapter 2 – Software Processes Lecture 1 Chapter 2 Software Processes1.
Software Engineering Lecture # 1.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
© Bennett, McRobb and Farmer 2005
Chapter 2 – Software Processes Lecture 2 1Chapter 2 Software Processes.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Observing the Current System Benefits Can see how the system actually works in practice Can ask people to explain what they are doing – to gain a clear.
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
MANAGEMENT INFORMATION SYSTEM
SOFTWARE DEVELOPMENT Presented By : Emporiumtech This presentation is brought you by
Information Systems Development
Principles of Information Systems Eighth Edition
Software Development Life Cycle Waterfall Model
Fundamentals of Information Systems, Sixth Edition
Fundamentals of Information Systems, Sixth Edition
Gary Hughes, South Oakleigh College
Systems Analysis and Design
Chapter 2 SW Process Models
Life Cycle Models PPT By :Dr. R. Mall.
Software Processes.
Information Systems Development
Chapter 2 Software Processes
Software life cycle models
Software Development Life Cycle:-
CS310 Software Engineering Lecturer Dr.Doaa Sami
MANAGING THE DEVELOPMENT AND PURCHASE OF INFORMATION SYSTEMS
Software Development Life Cycle Models
Presentation transcript:

Click to add text Systems Analysis, Prototyping and Iteration

Systems Analysis

 The design stage should produce a system specification, which should detail all necessary materials and procedures needed to fulfill the specification.  The specification should detail all the necessary clerical procedures, hardware requirements and the inputs, processing and outputs required of the computer software.

After implementation of a system, it will require continual monitoring and probably, occasional modification, when the operational or information requirements of users change. This maintenance task is the responsibility of the systems analyst.

SDM Waterfall Model

Feasibility  The feasibility study determines whether a particular development project should go ahead. If the project is to proceed then a project plan and budget estimate for the other stages of development will be produced. Requirements analysis  The requirements for the new or modified system are gathered at this stage. They should be recorded so that at the end of the project the software can be tested to ensure it fulfills the requirements.

Design specification Design focuses on:  high level design, e.g. what programs are needed, what are their inputs and outputs, what are their interactions with other software or the operating system.  low level design, e.g. how will the program work, what models or algorithms will be used, what libraries are required.  data design, e.g. for input and output, data structures in the software.  The level of detail in the design may be a matter of personal choice or may be specified by particular development procedures. Having a detailed design will make generating the code easier but will make changing things difficult whereas a more broad brush design will leave more work in the implementation phase but allows room for the details to come out as the development progresses. Above all the design should be documented including reasons for making particular choices if a number of options were available. This makes it much easier for new developers to join a project and helps when new features are required.

Coding  In this phase the designs are translated into code. Programming tools such as compilers and quality assurance tools are used to generate good quality source code and the software application. Testing of small self-contained parts (modules) of the overall application may take place depending on the modularity of the code. Testing  The overall system is tested to ensure that it works on the intended platform(s), giving correct results or showing the required behaviour defined in the requirements document. The use of debuggers and profiling tools will be useful at this stage to identify errors in the code and get the best possible performance from the code. Optimum performance is especially important in scientific computing applications.

Maintenance  Once the system is delivered to users it will inevitably need maintenance. There may be bugs caused by unexpected input values (add them to a test suite) or by unexpected (inappropriate) use of the software (tighten up the documentation). In addition users will want more or different functionality and will definitely want it to run faster or address bigger problems! The software development process should be able to accommodate changes at this stage through a well thought out design and any changes should have their own requirements, design, coding and testing stages.

 In the waterfall model, it is possible to rework earlier stages in the light of experience gained at a later stage. Each stage is signed off and the next stage is proceeded with. However the end user is rarely involved in the development stage, even though they may well be involved in signing off. It is therefore critical that the analysts and the programmers understand the end-users’ requirements. This can be quite difficult with the waterfall model.

 The waterfall model has disadvantages, which can be overcome using Prototyping, in which a model of the system is developed in partnership with the end-user. The features are worked out with the end user using a prototype, and the end user can have a considerable input into the development of a project.

Benefits are:  Misunderstandings are detected at early stages  The user will notice any missing functions, incomplete or inconsistent requirements.  Can be built quickly to demonstrate systems  It can be used for training before the system is finished

Benefits are:  Misunderstandings are detected at early stages  The user will notice any missing functions, incomplete or inconsistent requirements.  Can be built quickly to demonstrate systems  It can be used for training before the system is finished

Drawbacks are:  Project management can be uncoordinated or even sloppy.  Meetings with end users can become time consuming.  The final result could be completely different to what was requested in the first place.

Different Methods of Prototypes  Piloting – Test the feasibility of the design proposal  Modelling – building to develop an understanding of the user’s requirements  Throw-away prototyping – Pilot and modelling are throw away types – once they achieve their purpose the real system is built.  Evolutionary prototyping – each prototype built is a step closer to solution.