Acquiring software A company or organisation has three basic ways of acquiring (getting) software Buy it from some external source Buy it and customise.
Published byModified over 3 years ago
Presentation on theme: "Acquiring software A company or organisation has three basic ways of acquiring (getting) software Buy it from some external source Buy it and customise."— Presentation transcript:
1 Acquiring softwareA company or organisation has three basic ways of acquiring (getting) softwareBuy it from some external sourceBuy it and customise (modify) itDevelop it themselves (in-house or out)Some of these three methods are more appropriate for different organisations and for different types of software
2 Systems Software Systems Software includes software like Operating Systems,File Management Systems and DatabasesCommunications and Networking SoftwareThese are usuallyvery complex systemspurchased from large software developersPurchasing may include licensing arrangements
3 Information Systems and Applications There are many generic IS applications for particular domains / industriese.g. banking, insurance, airline reservations etc.When an organisation perceives a need for an ISe.g. starting a new company, migrating from a paper based systemor perceives a need for an improved ISe.g. the current system is too slow, incompatiblethe organisation may choose to buy a generic application or build a custom application
4 Buying “Off The Shelf” software installed in a matter of weeks or monthspossibly modified - further maintenance and developmenttested several times, so it gives more refinements & better de-bugging and documentationa professional team of programmers, designers, technical writersgood documentationknown price of purchase or licensegenerally a better and more economical choice
5 Build (develop) your own software The organisation may decide to develop their own custom-built IS because generic applicationsare not available ordo not provide all of the required featuresare not compatible with other existing systemsCost saving is not usually a reason because building your own is hugely expensiveBuilding a custom IS can be done either:by external consultants orin house, by your own IS/IT staffend users
6 Knowing what you needIn either case, the company must know exactly what the IS is required to doThe company may carry out a feasibility study to determine if the proposed IS will providesignificant benefitswithout unacceptable risksat an acceptable costThe feasibility study would indicate which approach - buy or build - is better
7 System RequirementsWhether the organisation decides to purchase or develop a system, the organisation now carries out a detailed analysis to find outthe functions that the IS must perform,the speed at which it must perform,the hardware it will run on andthe other systems with which it will be compatible
8 Functional and Non-functional Requirements Individual IS have both functional and non-functional requirementsNon-functional requirements are NOT “soft”A particular IS may need to be highly secure, very fast, highly reliable - these are not functions the IS performs, so they are non-functional requirements.These requirements may affect the way searches are carried out, the way data is arranged in databases and so on. The way non-functional requirements are met are often highly technical
9 The interface and user centred IS A special class of non-functional requirements may relate to the user interfaceThe interface may be required to be: easy to learn, easy to use, provide adequate support for users.These are NOT trivial nor universal requirements. They can have a significant impact on the way certain functions are implemented or on the overall cost and development time for the IS
10 Buying and the RFTIf the company decides to buy an IS they may send out a Request for Tenders (RFT or RFP)An RFT provides software houses with all the requirements for the proposed ISSoftware houses submit “tenders” which try to convince the buyer to choose their softwareThe buyer must evaluate these tenders impartially or there may be legal implications. If a suitable IS is found, the organisation signs contracts to buy.
11 Buying Commercial Off The Shelf software (COTS) InitiationNeedsCall forTendersEvaluation & selectionContract negotiation
12 Building and the SDLC Building an IS is a huge job, often involving dozens or hundreds of stafflasting moths or yearscosting hundreds of thousand or millionsBecause of this, most organisations follow a pattern called the Software Development Lifecycle (SDLC) to try to streamline the process and ensure success.There are a number of variations on the SDLC
13 Typical SDLC Feasibility study - may already have been done Plan all the steps and gather resourcesAnalysis find out exactly what is neededDesign work out how to build itDevelopment - produce the computer “code” (4GLs)Testing make sure it worksValidation make sure it does what is requiredImplementation - get the IS into the organisationGet ready to start again
14 SDLC and methodologies SDLC is a framework - it tells us about broad steps and how to move from one to anotherThis may not be sufficient guidance for a large project, so some companies buy and use detailed sets of instructions, called methodologiesMethodologies are expensive and require both training and commitment e.g. SSADM
15 Feedback Plan Analysis Design Development Testing Implementation & Documentation
16 Step 1. Feasibility study The goal of this phase is to determine the problem and is sometimes called the preliminary Investigation or system survey.
17 Tools of Feasibility study Pres. C. StenosThe systems analyst will develop an organizational chart to identify all relevant stakeholders.VP A. MappVP Z. HewnMarketingI. SimonPurchaseR. SouthSales O. PinePay. J. RiaIT.V. Gear
18 Defining the Problem involves Nature of the problemThe systems analyst and the users/clients must agree on the nature of the “problem”.Scope of the problemDetermining the scope of the problem sets limitations on how extensive the proposed system will be, the eventual budget and project schedulesObjectives of the projectDetermining what the users/clients think the system should be able to do
19 Step 1b Authorisation & Planning Following the feasibility study, someone in authority must authorise the project - the project sponsorA project manager will be appointed to oversee the planning, resourcing and progress of the project
20 PlanningProject planning means identifying all the tasks (and sub-tasks) that need to be done. The amount of time for each of these tasks is estimated.A Gantt chart is good for organising the tasks, their start/finish dates and the resources they needEstimation of times is risky so PERT uses 3 estimates to get the most accurate overall planCritical Path Method (CPM) identifies all the tasks which might delay the project so they can be watched more closely
21 Step 2 Systems AnalysisSystems analysis is the process of studying an existing system to determine how it works and how it meets client and user needs.Clients contract to have the systems analysis done.Users are people who will have contact with the system (employees and customers).
22 User InvolvementTo overcome reluctance to change, involve the people in the client organization in the development process.
23 An analyst must be good at: coordinating schedules and system-related tasks with a number of people.communicating -The analyst may need to make oral presentations and write reports for clients, users, and others involved with the system.Other desirable qualities of a systems analyst are:an analytical mindself-disciplineself-directionThe ability to work without tangible results
24 FlowchartsA flowchart is a pictorial representation of a step-by-step solution to a problem.
25 Flowchart BasicsA flowchart consists of arrows to represent direction the program takes and boxes and symbols to represent actions.
26 Flowchart Symbols Process Start/Stop Connector Input/Output Flow directionDecision
27 Flowchart Symbols Start Deposit Show message Get amount No Valid ? Yes Add balance & amt22Show new balance