Presentation on theme: "Information technology solutions development Fundamentals of Information Technology Session 3."— Presentation transcript:
Information technology solutions development Fundamentals of Information Technology Session 3
The systems development lifecycle IT systems development can be viewed as a linear (waterfall) process from analysis through to maintenance However, this model of development is really simplification and an idealisation of the development process used mainly for descriptive purposes In reality, development tends to be iterative and/or incremental, using a prototyping rather than a linear approach
The systems development lifecycle – Prototyping Prototyping is the process of quickly putting together a working model in order to test a design, and get early user feedback Successive prototypes are created in a process of iterative and incremental development until a satisfactory and robust product emerges This means that problems or deficiencies in design can be corrected early in the development process and requirements can be refined and/or added as development proceeds
The systems development lifecycle – Prototyping
The systems development lifecycle Each stage of the development process includes a set of related sub-processes and activities
Systems analysis – feasibility The possible benefits and achievability of proposed IT solutions are normally expressed in a feasibility study A feasibility study examines the business, technical and case for building a new system Business case –By how much will the proposed product reduce costs? –By how much will the product increase profit? –How will it enhance competitive advantage? Technical case –Does the organisation have in-house expertise, or will it have to procure bought-in development resources, or outsource? Organisational –What training needs will there be? –What is the potential for stakeholder resistance? –What are the legal ramifications?
Systems analysis – requirements specification Systems analysis can best be viewed as a statement of a problem (not the solution) that constitutes a need for organisational change Systems analysis generally involves a series of distinct activities 1.An analysis of the strengths and weaknesses of the current system, culminating in a statement detailing where the system can be improved 2.Development of a requirements specification for the new system showing the –functional requirements (What a new system should do), –data requirements (What data load a new system needs to be able to manage) –non-functional requirements (The level to which a new system is expected to perform) 3.Definition of constraints (e.g. economic, technical, organisational factors limiting the development of the system)
Systems analysis – requirements specification Functional requirements detail the required behaviours of a system (e.g. what the user can do with the system) They are discovered through dialogue with end-users, stakeholders and information experts within an organisation in workshops, interviews or questionnaires Individual requirements are generally specified using the following format: X should/shall/must do Y. –The system should allow the administrator to set up user accounts –The system shall prompt users to change their passwords every six weeks –The system must provide clear feedback that a password has been successfully changed
Systems analysis – requirements specification Data requirements determine: –The kind of data a system will hold (e.g. customer accounts, orders, products, etc.) –The quantity of data that a system will have to store –The system should hold records of all orders placed within the past ten years –The system must be able to provide storage for the personal details of up to 1 million customers
Systems analysis – requirements specification Non-functional requirements detail requirements related to system performance and evolution. They will specify factors such as: –Usability –Accessibility –Security –Extensibility/Scalability –Performance (e.g. response time) –The system shall allow for 200 concurrent users with no loss of performance –The system must provide interfaces that are accessible regardless of ability or disability
Systems analysis – constraints Constraints specify parameters in which the system should be built and operate These parameters can be: legal, technical, economic, social, etc. –The system must be operational within eighteen months –The system should satisfy all requirements under copyright law –The system must be built for less than £200,000
System design System design provides the solution to the problem specified in the systems analysis stages of development It involves three distinct activities
System design – process design Process design focuses on modelling the path of data and transition as it moves through the system Multiple techniques are available for process modelling, such as: –Flowcharts –SSADM (Structured System Analysis and Design Method) –UML (Unified modelling language) http://www.uml.org/
System design – data design Data design specifies the data objects (entities) that will be stored in the system It also specifies the relationships between the data types
System design – data design And the attributes that the data types have
System design – interface design Interface design involves designing the part of the system the end-user will interact with It involves designing dialogues (user instructions), menus, toolbars, etc. Interface design is done using storyboards or wireframes.
System design – interface design Example storyboards
Implementation System Implementation takes the design specifications from the design phase and turns them into concrete products Implementation should follow a strict process from the development of the software, through testing, to release
Implementation The final stage of implementation is release Release of new IT systems can follow several scenarios Each scenario entails varying degrees of risk. However, some entail more risk than others.
FIT Session 3 – Activities Now do –Activity 3 – IT solutions development