Pearson BTEC Level 4 Higher Nationals Certificate in
Pearson BTEC Level 4 Higher Nationals Certificate in Computing (RQF) Unit 9 – Software Development Lifecycles
Learning Outcomes By the end of this unit students will be able to: LO 1 LO 2 LO 3 LO 4 • Describe different software development lifecycles. • Explain the importance of a feasibility study. • Undertake a software development lifecycle. • Discuss the suitability of software behavioural design techniques.
LO 2 – Explain the importance of a feasibility study Essential Content § Importance of feasibility study: o Requirement gathering techniques: e. g. , interviews, observation, investigation o Key drivers: performance and efficiency; legacy systems upgrade; automation; elimination of human error. o Feasibility criteria: issues e. g. legal, social, economic, technical, timescales; organizational constraints. o Components: purpose; structure; intended audience; outcomes. o Requirements: Mos. Cow; Functional; non-functional; user; constraints.
Requirement gathering techniques § Interviews o One-on-One Interviews • One-on-one interviews are the most common technique for gathering requirements, as well as one of the primary sources of requirements. • The analyst should identify stakeholders to be interviewed. • These can be users who interact with the current or new system, management, project financers or anyone else that would be involved in the system. • When preparing an interview is it important to ask open-ended questions, as well as closed-ended questions.
Requirement gathering techniques § Interviews o Group Interviews: • Group interviews are similar to one-on-one interview, except there is more than one person being interviewed. • Group interviews work well when the interviewees are at the same level or position. • More thoughts and discussion can be generated, as someone in the group may state or suggest an idea that may have been overlooked by others. • A major disadvantage can be scheduling the interview. When more than one person are involved, it may be difficult, or become time consuming, in establishing date and time that works well for all parties.
Requirement gathering techniques § Observation • To get a better understanding of a user in their in current work environment, the analyst may observe the user themselves. • User observation is helpful in assisting the analyst by getting a full grasp of how the user interacts with the system. • Every observation must be guided by clearly stated objectives. The analyst should know: – What data is to be collected – How observation will be done – When and where to observe – How the data will be collected – What the data will be used for after analysis
Requirement gathering techniques § Observation o Passive observation • Passive/Invisible observation happens where the analyst has no interaction with the worker while the observation is going on, but takes notes. o Active observation • Active/visible observation, the analyst can interrupt the worker to ask questions during the observation session. In some cases, the observer may participate in the activity as an apprentice.
Requirement gathering techniques § Investigation o Analyzing existing documents • Reviewing the current process and documentation can help the analyst understand the business, or system, and its current situation. • The analyst may find there was missing information in old documents. • They may also find redundancy, in which steps are unnecessarily repeated. • Such documentation (if it exists) could include interface details, user manuals, and software vendor manuals.
Requirement gathering techniques o Questionnaires • Questionnaires can be useful for obtaining limited system requirements details from users / stakeholders, who have a minor input or are geographically remote. • Advantages: – Can send to many hundreds of users at a low cost. – Good for getting input from users who are a long distance away. – Receive written replies which can be easier to work with and analyze, and save time typing. • Disadvantages: – Questionnaires can be slow to create. – You may not get a good response, as filling in questionnaires is often a low priority for many people.
Key drivers Why information systems are important to business / organization: § Performance and efficiency o Businesses can constantly improve their efficiency of their operations in order to achieve higher profitability. o I. S systems make it possibly for managers to use real time data when making a decision to therefore make better decisions and not have to waste time looking for information
Key drivers § Legacy systems upgrade o Overall, there are several outstanding reasons to replace a legacy system: • Cost of maintenance - Maintaining a system may eventually become more expensive than replacing the hardware and software. • Lack of understanding - Maintaining and expanding systems can be difficult because there is a lack of understanding about how they are run.
Key drivers § Legacy systems upgrade o Overall, there are several outstanding reasons to replace a legacy system: • Vulnerabilities - A lack of security patches within older systems may lead to vulnerabilities and this could put the system at risk of being compromised. • Integration - New systems may be difficult to integrate with older technologies as there may not be sufficient demand for the integration technology.
Key drivers § Automation o An automated system is composed of elements designed to perform a set of tasks that have been programmed. Operational and repetitive tasks become less of a burden. • Eliminate the manipulation of paper documents - Can store information in system, no more printing and storing paper documents. Optimize time spent looking for information. • Make better projections - A Business Process Automation (BPA) gives you all the tools needed to monitor data, at all times. • Allow new business opportunities - Allows the ability to configure and support assets in fields you couldn’t even have thought about while using only human resources.
Key drivers § Elimination of human error o Manual data processingpresents the possibility of human error, which can be costly to a businss. o For example, computerized system that incorporate accounting programs can reduce calculation errors.
Feasibility criteria § Legal o Determines whether the proposed system conflicts with legal requirements e. g. a Data Processing system must comply with the local Data Protection Acts. o When an organization has either internal or external legal counsel, such reviews are typically standard. o However, a project may face legal issues after completion if this factor is not considered at this stage
Feasibility criteria § Social o Its part would determine the proposed project will be satisfactory for the people or not. o This assumption would in general examine the probability that the project would have to be accepted by the group of people that are directly affected by the proposed system.
Feasibility criteria § Economic o The bottom line in many projects is economic feasibility. o During the early phases of the project, economic feasibility analysis amounts to little more than judging whether the possible benefits of solving the problem are worthwhile. o As soon as specific requirements and solutions have been identified, the analyst can weigh the costs and benefits of each alternative. This is called a cost-benefit analysis.
Feasibility criteria § Technical o The technical aspect explores 'if the project feasibility is within the limits of current technology and does the technology exist at all, or if it is available within given resource constraints (i. e. , budget, schedule, . . . ). o In the technical feasibility the system analyst look between the requirements of the organization, such as, (I) input device which can enter a large amount of data in the effective time (II) Output devices which can produce output in a bulk in an effective time (III) The choice of processing unit depends upon the type of processing required in the organization.
Feasibility criteria § Timescales o The analyst should determine if the project deadlines are reasonable whether constraints placed on the project schedule can be reasonably met. o Some projects are initiated with specific deadlines. You need to determine whether the deadlines are mandatory or desirable. o It is preferable (unless the deadline is absolutely mandatory) to deliver a properly functioning information system two months late than to deliver an error-prone, useless information system on time. o Missed schedules are bad, but inadequate systems are worse!
Feasibility criteria § Organizational constraints o To check if the system is developed, will it be used? o The study includes people-oriented and social issues: • internal issues, such as manpower problems, labor objections, manager resistance, organizational conflicts and policies; • also external issues, including social acceptability, legal aspects and government regulations. o It takes in consideration whether the current work practices and procedures support a new system and social factors of how the organizational changes will affect the working lives of those affected by the system.
Components § Purpose o Establishes the intended purpose of the information environment. o To define the boundaries of the information systems by identifying the content of interest of the business / organization.
Components § Structure o Structure defines the contours and boundaries of the information in line with the content, functionalities and expectation of the organization specified in the statements of strategy and scope. o It converts an undifferentiated accumulation of resources into a unified and cohesive arrangement of resources organized by a system.
Components § Intended audience o The users who will actively participate in the activities of the information environment.
Requirements § Mos. Cow o What is the Mo. SCo. W Method? • Prioritizing is often challenging. Particularly when it comes the implementation of new ideas and/or technologies. • Everyone in an organization always wants everything to be done right away and that is practically impossible. • There are several tools available to make prioritization easier. The Mo. SCo. W method is one them. • Dai Clegg from the software company Oracle invented Mo. SCo. W Method. The method labels each requirement, making it easier to prioritize.
Requirements § The Mo. SCo. W Method is about setting requirements by order of priority. The most important requirements need to be met first for a greater chance of success. § The Mo. SCo. W Method is an acronym made up of the first letters. The two Os have been added to make the word ‘moscow’ readable, they don’t have any meaning themselves. § The M stands for ‘Must haves‘, S for ‘Should haves‘, C for ‘Could haves‘ and W for ‘Won’t haves‘ or ‘Would haves‘.
Requirements
Requirements § Requirements o It’s a good idea to first specify the requirements before starting the Mo. SCo. W Method. o When determining the requirements, you should take into account what is important to all the stakeholders. Brainstorming with everyone involved will lead to good, qualitative requirements. o The requirements are prioritized to prevent them from becoming to expensive or unrealistic. The main goal is to come up with requirements that add the most value for the company.
Requirements § The project requirements are divided into one of the following categories: o M – Must haves • These are about the minimal requirements that are determined in advance that the end-result has to meet. • Without meeting these requirements, the project fails and the product won’t be use-able. • They are a necessity for a workable product and there is no alternative. The ‘Must haves’ are essential. • MUST is also explained as an acronym that stands for Minimum Use-able Subse. Ts.
Requirements o S – Should haves • These are additional and much desired requirements that have a high priority, but are not essential for a usable end product. • The product will be usable even if these requirements aren’t met. When they are met, they will only add to the value of the product. • Depending on the available time, you can always return to these requirements at a later time.
Requirements o C – Could haves • These requirements can be considered if there’s time left. If not, it’s no problem and will not have a negative effect on the final result. • The ‘Could haves’ have a lower priority than the ‘Should haves’. • This option will only be included if there really is more than enough time to make it work. • This category is also referred to as ‘nice to have’; they’re more a wish than an absolute requirement.
Requirements o W – Won’t haves (and would haves) • These are about wishes for the future that are often impossible to realize or cost a lot of time. • If it’s simply not possible, it’s best not to waste any energy on it. • If it is achievable, then a lot of time (and money) will have to be invested and it’s labeled a ‘Would have’. • ‘Would haves’ are often followed upon at a later stage after the initial project is finished.
Requirements § Deadline o Correctly applying and sticking to the Mo. SCo. W Method will lead to a clear way to lead a project. o Everyone involved with the project will know what needs to be done first, when it has to be finished and why it’s important. o By assigning priorities to requirements, a project becomes more manageable and it’ll be easier to meet the deadline.
Requirements § Functional / Non-Functional o What exactly is the difference between ‘functional’ and ‘non functional’ requirements? o The official definition of ‘a functional requirement’ is that it essentially specifies something the system should do. o Typically, functional requirements will specify a behavior or function, for example: • “Display the name, total size, available space and format of a flash drive connected to the USB port. ”. • Other examples are “add customer” and “print invoice”.
Requirements § Functional / Non-Functional o The difference is that non-functional requirements describe how the system works, while functional requirements describe what the system should do. o One could also think of non-functional requirements as quality attributes for of a system. o Non-functional requirements cover all the remaining requirements which are not covered by the functional requirements. • They specify criteria that judge the operation of a system, rather than specific behaviors, for example: “Modified data in a database should be updated for all users accessing it within 2 seconds. ”
Requirements § User o User requirements, often referred to as user needs, describe what the user does with the system, such as what activities that users must be able to perform. o User requirements are generally documented in a User Requirements Document (URD) using narrative text. o User requirements are generally signed off by the user and used as the primary input for creating system requirements.
Requirements § Constraints o The functional requirements for a new system specify what the proposed system will do. A constraint specifies how the system must operate or how it must be built. o Constraints fall into these broad categories: 1. Constraints on the end product. – Reliability and availability constraints. – Performance constraints. – Environment constraints. 2. Constraints on the development. – Use of application software products. – Use of tools and programming languages.
Requirements § Constraints Examples: o Specifying performance constraints • Online transaction processing: – average and maximum volume per unit time – maximum number of simultaneous users – maximum tolerable response time for each type of transaction or other user action. • Data volume – Maximum number of each type of record (entity) to be stored permanently or temporarily
References § https: //www. umsl. edu/~sauterv/analysis/F 2015/Requirement%20 Gatheri ng%20 Methods. html. htm § https: //businessanalystlearnings. com/ba-techniques/2013/5/16/using-theobservation-technique-for-requirements-elicitation § http: //www. axia-consulting. co. uk/html/requirements_gathering. html § https: //eternalsunshineoftheismind. wordpress. com/2013/03/10/6 -reasons -why-information-systems-are-important-to-business/ § https: //www. arrkgroup. com/thought-leadership/reasons-to-move-awayfrom-legacy-systems/ § http: //blog. cimpl. com/8 -benefits-of-using-automated-systems § http: //www. essay. uk. com/free-essays/information-technology/assessimpact-different-feasibility. php § https: //www. toolshero. com/project-management/moscow-method/ § http: //enfocussolutions. com/business-user-and-system-requirements/
- Slides: 38