Scribd
Upload
13 views56 pages

Notes IV

The document outlines a comprehensive course on Software Engineering, detailing key topics such as software development processes, requirements engineering, software design, project management, risk management, and maintenance. It emphasizes the importance of systematic approaches in software development and introduces various life cycle models including the Waterfall, Iterative Waterfall, Prototyping, and Spiral models. The document also highlights the characteristics of good software and the need for effective software engineering practices to manage complexity and ensure quality.

Uploaded by

Selemani Msigala
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
13 views56 pages

Notes IV

The document outlines a comprehensive course on Software Engineering, detailing key topics such as software development processes, requirements engineering, software design, project management, risk management, and maintenance. It emphasizes the importance of systematic approaches in software development and introduces various life cycle models including the Waterfall, Iterative Waterfall, Prototyping, and Spiral models. The document also highlights the characteristics of good software and the need for effective software engineering practices to manage complexity and ensure quality.

Uploaded by

Selemani Msigala
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
©) studocu Software Engineering Notes COURSE CODE: DIT 0301 COURSE TITLE: SOFTWARE ENGINEERING COURSE OUTLINi 1, Introduction: Basic Definitions: Soliware Engineering, System Engineering, Software Process, Software Process Model, Software Engineering Methods, Information Systems Manufacturing Techniques. 2. Software Development Process Trends: Process And Meta Processes, Process Models, Waterfall, Incremental, Spiral, Evolutionary Development, Component Based Software Engineering. 3. Software Requirements: Functional And Non Functional Requirements, User Requirements, System Requirements, Interface Specifications, Sofiware Requirement Document 4, Requirement Engineering: Feasibility Study, Requirements Blicitation And Analysis, Requirements Validation And Requirement Management 5. Software Design — SW Construction, Design Concepts, Modularity, CASE Tools, Aspects of Object Oriented Programming 6. CAT 1 7. Software Project Management: Management Activities: Proposal Writing, Project Plaming And Scheduling, Project Cost, Project Monitoring And Reviews, Personnel Selection And Evahiation, Report Writing And Presentations. Project Planning: Project Plan , Project Scheduling, Software Configuration, Software Quality Assurance, SQA Plan, Process And Product Quality, Standards And Procedures, Quality Planning And Quality Control 8. Risk Management: Steps In Risk Management; Risk Identification, Risk Analysis, Risk Prevention; Limitations; Risk Planing; Eliminating Risk Occurrence, Ignoring Risk, Risk Contingency; Risk Monitoring: Types Of Risks; Known, Unknown, And Unforeseen 9. Software Maintenance: Types Of Maintenance, Factors Affecting Maintenance 10. Computer Security: Data Security, Network Security, Techniques: Password, Biometrics, Firewalls, Physical Plant Protection, Key Cards, Cryptography, Encryption, Digital Certificates, Policy 11, Professional Issues In IT: Copyright, Trademark, Legal Issues, Patent Assessment CATS -30% ASSIGNMENTS - 10% FINAL EXAM - 60% REFERENCE Main Text Sommerville Ian, Software Engineering 7th Ed. Pearson Education Ltd. Others I. Roger S. Pressman, Software Engineering: A Practioner’s Approach, 6th Ed. McGraw-Hill. 2005: 2. Edward Yourdon, Decline, Fall of the American Programmer, Prentice Hall, Inc. 1993. 3. unk: hitp//[Link]-engicom ‘wedormersonnsen Ey studocu Downloaded by Selemani Msigala (selemanimsigala@[Link]) INTRODUCTION TO SOFTWARE ENGINEERING Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (EEE Computer Society) Software engineering is the process of solving customers’ problems by the systematic development and evolution of large-high quality software systems within cost, time, and other constraints (Lethbridge) Software engineering can be described in terms of Analysis - breaking apart a problem into pieces Synthesis - constructing a solution from available or new components, ‘Methods & tools - that enable software projects to be built predictably within. proscribed schedules & budgets, meeting the customer's requirements of functionality & reliability. Software engineering is concerned with the theories, methods and tools which are needed to develop high quality, complex software in a cost effective way on a predictable schedule. Software engineering: The disciplined application of engineering, scientific, and mathematical principles, methods, and tools to the economical production of quality software. Software is abstract and intangible. It is not constrained by materials, governed by physical laws or by manufacturing processes. There are no physical limitations on the potential of software. — A software product consists of developed programs and all associated documentation and configuration data needed to make the programs operate correctly. Software process: The set of activities, methods, and practices that are used in the production and evolution of software. Software process model: One specific embodiment of Software process architecture Software engineering process: The total set of software engineering activities needed to transform a user's requirements into software Software process architecture: A framework within which project-specific software processes are defined. The Nature of Software Software is flexible - Software is an executable specification of a computation / application Software is expressive - All computable fimctions may be expressed in software. Complex event driven systems may be expressed in software. Software is huge - An operating system may consist of millions of ines of code, Software is complex - Software has litle regularity or recognizable components found in other ‘complex systems and there are exponentially many paths through the code and changes in one att of the code may have unintended consequences in other equally remote sections of the code. Software is cheap - Manufacturing cost is zero, development cost is everything. Thus, the first copy is the engineering prototype, the production prototype and the finished product. Software is never finished - The changing requirements and ease of modification permits the maintenance phase to dominate a software product's life cycle, ic., the maintenance phase consists of on going design and implementation cycles. Software is easily modified - It is natural to use an iterative development process combining requirements elicitation with design and implementation and use the emerging implementation to uncover errors in design and in the requirements. Downloaded by Selemani Msigala (selemanimsigala@[Link]) Software is communication - Communication with a machine but also communication between the client, the software architect, the software engineer, and the coder. Software must be readable in order to be evolvable. NEED OF SOFTWARE ENGINEERING ‘The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working. ‘© Large software - It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process ‘+ Scalability. If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one. © Cost- As hardware industry has shown its skills and huge manufacturing has lower down the price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted. ‘+ Dynamic Nature- The always growing and adapting nature of software hugely depends upon the environment in which the user works. If the nature of software is always changing, new enhancements need (o be done in the existing one. This is where software engineering plays a good role. ‘© Quality Management- Better process of software development provides better and quality software product. CHARACTERESTICS OF GOOD SOFTWARE A software product can be judged by what it offers and how well it can be used. This software must satisfy on the following grounds: i Operational: This tells us how well software works in operations. It can be measured on: Budget, Usability, Efficiency, Correctness, Functionality, Dependability, Security and Safety ii, ‘Transitional: This aspect is important when the software is moved from one platform to another: Portability, Interoperability, Reusability and Adaptability iii, Maintenance: This aspect briefs about how well a software has the capabilities. to maintain itself in the ever-changing environment: Moduliity, Maintainability, Flexibility and Scalability In short, Software engineering is a branch of computer science, which uses well-defined engineering concepts required to produce efficient, durable, scalable, in-budget and on-time software products SOFTWARE DEVELOPMENT LIFE CYCLE LIFE CYCLE MODEL A software life cycle model (also called process mode) is a descriptive and diagrammatic representation of the software life cycle. A lie cycle model represents all the activities required to make a software product transit through its life cycle phases ‘wedowmersonnsen Ey studocu Downloaded by Selomani Msigala (selomanimsigala@[Link]) Different software life cycle models ‘Many life cycle models have been proposed so far. Each of them has some advantages as well as some disadvantages. A few important and commonly used life cycle models are as follows: i Chssical Waterfall Model ii, Iterative Waterfall Model iii, Prototyping Model iv. Evolutionary Model Spiral Model 1. CLASSICAL WATERFALL MODEL ‘The classical waterfall model is intuitively the most obvious way to develop software, It is not a practical model in the sense that it cannot be used in actual software development projects. Thus, this model can be considered to be a theoretical way of developing software. But all otber life cycle models are essentially derived fiom the classical waterfall model. Classical waterfall model divides the life cycle into the folowing phases: |Classical Waterfall Model Testing Feasibility study - The main aim of feasibility study is to determine whether it woukl be financially and technically feasible to develop the product. ‘Requirements analysis and specification: - The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely > Requirements gathering and analysis: The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that incompleteness and inconsistencies are removed Requirements specification: The requirements analysis activity is begun by collecting all relevant data regarding the product (o be developed from the users of the product and from the customer through interviews and discussions. v After all ambiguities, inconsistencies, and incompleteness have been resolved and all the requirements properly understood, the requirements specification activity can start. During this activity, the user requirements are systematically organized into a Software Downloaded by Soloman’ Msigala (selomanims'gala@[Link]) Requirements Specification (SRS) document. The important components of this document are functional requirements, the nonfunctional requirements, and the goals of implementation. Design: - The goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. ‘Two distinctly different approaches are available: the traditional design approach and the object-oriented design approach + Traditional design approach -Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried ‘out where the detailed structure of the problem is examined. This is followed by astructued design activity. During structured design, the results of structured analysis are transformed into the software design ‘© Object-oriented design approach -In this technique, various objects that occur in the problem domain and the sohiion domain are first identified, and the different relationships that exist among these objects are identified. The object structure is farther refined to obtain the detailed design. Coding and unit testing:-The purpose of the coding phase (sometimes called the implementation phase) of software development is to translate the software design into source code. Each component of the design is implemented as a program module. ‘The end-product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested to determine the correct working of all the individual modules. Integration and systemtesting: -Integration of different modules is undertaken once they have been coded and unit tested. Integration is normally carried out incrementally over a number of steps. During each integration step, the partially integrated system is tested and a set of previously planned modules are added to it. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements hhid out in the SRS document, System testing usually consists of three different kinds of testing activities ‘© a—testing: Itis the system testing performed by the development team. ‘© B-testing: It is the system testing performed by a friendly set of customers. ‘+ Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. System testing is normally carried out in a planned manner according to the system test plan document. The system test plan identifies all testing-related activities that must be performed, specifies the schedule of testing, and allocates resources. It also lists all the test cases and the expected outputs for each test case Maintenance: -Maintenance of atypical software product requires much more than the effort necessary to develop the product itself, Maintenance involves performing any one or more of the following three kinds of activities i Comecting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving the implementation of the system, and enhancing the functionalities of the system according to the customer's requirements. This is called perfective maintenance. ‘wedowmersonnsvn Ey studocu Downloaded by Selemani Msigala (selemanimsigala@[Link]) iii, Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with anew operating system. This is called adaptive maintenance Shortcomings of the classical waterfall model 1. The rigid. sequential flow of the model is rarely encountered in real life. Iteration can occur causing the sequence of steps to become nmddled. 2. Itis often difficult for the customer to provide a detailed specification of what is required carly in the process. Yet this model requires a definite specification as a necessary building block for subsequent steps. 3. Much time can pass before any operational elements of the system are available for customer evaluation, If a major error in implementation is made, it may not be uncovered until much later. 2. ITERATIVE WATERFALL MODEL To overcome the major shortcomings of the classical waterfall model, we come up with the iterative waterfall model. Implementation ane Unit Testing Here, we provide feedback paths for error correction as & when detected later in a phase. The advantage of this model is that there is a working model of the system at a very early stage of development which makes it easier to find functional or design flaws. ‘The disadvantage with this SDLC model is that it is applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules. 3. PROTOTYPING Prototyping moves the developer and customer toward a “quick” implementation. 1. Prototyping begins with requirements gathering 2. Meetings between developer and customer are conducted to determine overall system objectives and functional and performance requirements 3. The developer then applies a set of tools to develop a quick design and build a working model (the 'prototype") of some element(s) of the system. Downloaded by Soloman’ Msigala (selomanimsigala@[Link]) 4. The customer or user "test drives” the prototype, evaluating its function and recommending changes to better meet customer needs. 5. Tteration occurs as this process is repeated, and an acceptable model is derived. The developer then moves to "productize” the prototype by applying many of the steps described for the classic life cycle. In object oriented programming a library of reusable objects (data structures and associated procedures) the software engineer can rapidly create prototypes and production programs. The benefits of prototyping are: 1. A working model is provided to the customer/user early in the process, enabling early assessment and bolstering confidence, 2. The developer gains experience and insight by building the model, thereby resuking ina more solid implementation of "the real thing” 3. The prototype serves to clarify otherwise vague requirements, reducing ambiguity and improving communication between developer and user. But prototyping also has a set of inherent problems: 1. The user sees what appears to be a fully working system (in actuality, it is a partially working mode) and believes that the prototype (a model) can be easily transformed into a production system. This is rarely the case. 2. The developer often makes technical compromises to build a “quick and dirty’ model Sometimes these compromises are propagated into the production system, resulting in implementation and maintenance problems. 3. Prototyping is applicable only to a limited class of problems. In general, a prototype is valuable when heavy human-machine interaction occurs, when complex output is to be produced or when new or untested algorithms are to be applied. 4. NARY MODEL Itis ako called successive versions model ot incremental model. At frst, a simple working model is built. Subsequently it undergoes functional improvements & we keep on adding new functions til the desired system is built. Applications: ‘© Large projects where you can easily find modules for incremental implementation. Often used when the customer wants to start using the core features rather than waiting for the full software. ‘+ Also used in object oriented software development because the system can be easily portioned into units in terms of objects. Advantages: ‘© User gets a chance to experiment partially developed system © Reduce the error because the core modules get tested thoroughly. Disadvantages: ‘© Itis dificult to divide the problem into several versions that would be acceptable to the customer which can be incrementally implemented & delivered. ‘wedowmersonnsen Ey studocu Downloaded by Slomani Msigala (selemanimsigala@[Link]) 5. SPIRAL MODEL The term “spiral” is used to describe the process that is followed as the development of the system takes place. With cach iteration around the spiral (beginning at the center and working outward), progressively more complete versions of the system are built. Risk assessment is inchuded as a step in the development process as a means of evaluating each version of the system to determine whether or not development should continue. If the customer decides that any identified risks are too great, the project may be haked. The Spiral Model is made up of the following steps: Project Objectives - Similar to the system conception phase of the Waterfall Model Objectives are determined, possible obstacles are identified and alernative approaches are weighed Risk Assessment - Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to clarify needs. Engineering & Production - Detailed requirements are determined and the software Pioce is developed. Planning and Management - The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer. Problems/Challenges associated with the Spiral Model © Due to the relative newness of the Spiral Model, it is difficult to assess its strengths and weaknesses However, the risk assessment component of the Spiral Model provides both developers and customers with a measuring tool that earlier Process Models do not have © The measurement of risk is a feature that occurs everyday in real-life situations, but unfortunately) not as often in the system development industry. ‘© The practical nature of this tool helps to make the Spiral Model a more realistic Process ‘model than some of its predecessors. Next Phase Product Planning Development| Downloaded by Selemani Msigala (selemanimsigala@[Link]) REQUIREMENTS ANALYSIS AND SPECIFICATION REQUIREMENTS ENGINEERING This is the process of eliciting, analysing and recording requirements for software systems. Its goal is to create and maintain a system requirement document. The process involves assessing whether the system is useful to business, discovering requirements, converting them into some standard form and checking that the requirements actually define the system. The requirements engineering process ‘These are the activities that are involved in requirements engincering. They inchide: 1. Requirements elicitation In requirements engineering, requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as requirements gathering/requirements discovery. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices involves fact finding techniques such as interviews, questionnaires, user observatiowethnography, Documentary review e..e 2. Requirements Analysis and Negotiation ‘The purpose of this activity is to transform technical requirements into formal requirements by ensuring that they express the needs of the customer. Analysis is an iterative activity. The process steps will likely be repeated several times in consukation with the customers. The goal of analysis is to locate places where requirements are unclear, incomplete, ambiguous or contradictory. It groups related requirements and organizes them into coherent chisters. The requirements are then prioritized and any conflicts that arise are resolved. 3. Requirements Validation Concemed with demonstrating that the requirements define the system that the customer really wants. Requirements errors are very costly and so validation is very important, Fixing arequirements error after delivery may cost up to 100 times the cost of fixing an implementation error. The requirements are checked against the following factors: Validity — Does the system provide the functions which best support the customers needs? Consistency — Are there any requirements conflicts? Completeness — Are all functions required by the customer inchuded? Regular reviews should be held during the whole process both the technical staff and the customer should be involved in the reviews. Good communication between the technical staff and the customer can resolve problems at an early stage. Before changing requitements, check for traceability (origin) and adaptability (impact on other requirements) of the requirements. 4, Requirements Management The process of managing changing requirements during the requirements engineering process. Requirements may change because: * Technology may change © User needs may change © Changing business processes etc 5. Requirements Documentation Requirements need to be documented and a standard format is used. Requirements should state what the system should do and the design should describe how it does this, nscemersanisen @ studocu Downloaded by Selemani Msigala (selemanimsigala@[Link]) N.B: Leam more about the IEEE standard for documentation especially requirement documents, Challenges in getting requirements Stakeholders don’t know what they really want Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change. FACT FINDING The formal process of using techniques such as interviews and questionnaires (o collect facts about systems, requirements and preferences. When are fact finding techniques used? There are many occasions for fact finding during the system development process. However, fact finding is particularly crucial to the carly stages of the life cycle including system planning, system definition and requirements collection and analysis stages. It is during these early stages that the developer leams about the terminology, problems, opportunities, constraints, requirements and priorities of the enterprise and the users of the system. Interviews This is the most commonly used and normally most useful, fact-finding technique Interviews are a fact finding technique whereby the systems analysts collect information from individuals (and/or groups) through face-to-face interaction, There can be several objectives to using interviewing, such as finding out facts, verifying facts, clarifying facts, generating enthusiasm, getting end-user involved, identifying requirements and gathering ideas and opinions. However, using the interviewing technique requires good communication skills for dealing effectively with people who have different values, Priorities, opinions, motivations and personalities. As with other fact finding techniques, interviewing is not always the best method for all situations. There are two types of interviews: i Unstructured interviews: Conducted with only a general objective in mind and with few, if any, specific questions. The interviewer counts on the interviewee to provide a framework and direction to the interview. This type of interview frequently loses focus and, for this reason, it often does not work well for systems analysis and design. i, Structured interviews: ‘The interviewer has a specific set of questions to ask the interviewee. Depending on the interviewee’s responses, the interviewer will direct additional questions to obtain clarification ot expansion. Some of the questions may be planned and others spontaneous. Open-ended questions allow the interviewee to respond in any way he/she seems appropriate ‘An example of an open-ended question is: ‘Why are you dissatisfied with the report on client registration?” Closed-ended questions restrict answers to either specific choices or short, ditect answers. An example of a closed-ended question might be: “Are you receiving the report on client registration on time?’ or ‘Does the report on client registration contain accurate information?’ Both questions only require a “Yes" or ‘No’ response. Downloaded by Solemani Msigala (selemanimsigala@[Link]) To ensure a successful interview inchdes selecting appropriate individuals, preparing extensively for the interview and conducting the interview in an efficient and effective manner. Advantages Interviews give the analyst an opportunity to motivate the interviewee to respond fieely and openly to questions. Interviews allow the systems analyst to probe for more feedback from the interviewee. Interviews give the analyst an opportunity to observe the interviewee’s nonverbal communication. A good analyst may be able to obtain information by observing the interviewee’s body movements and facial expressions as well as by listening to verbal replies to questions, Interviews permit the systems analyst to adapt or reword questions for each individ ual Disadvantages Interviewing is a very time-consuming, and therefore costly, fact-finding approach. Success of interviews is highly dependent on the systems analyst's human relations skilb. Interviewing may be impractical due to the location of interviews. Success can be dependent on the willingness of the interviewees to participate in interviews. Observation ‘Observation is one of the most effective fact-finding techniques for understanding a system. With this technique, it is possible to either participate in, or watch, a person perform activities to learn about the system. This technique is particularly useful when the validity of data collected through other methods is in question or when the complexity of certain aspects of the system prevents a clear expansion by the end users. AAs with the other fact-finding techniques, successful observation requires preparation. To ensure that the observation is successful, it is important to know as mich about the individuals and the activity to be observed as possible. For example, ‘When are the low, normal and peak periods for the activity being observed?’ and ‘Will the individuals be ‘upset by having someone watch and record their actions?” Advantages Data gathered by observation can be highly reliable. Sometimes observations are conducted to check the validity of data obtained directly from individuals ‘The systems analyst is able to see exactly what is being done. Complex tasks are sometimes difficult to clearly explain in words. Through observation, the systems analyst can identify tasks that have been missed or inaccurately described by other fact-finding techniques. Also, the analyst can obtain data describing the physical environment of the task (e.g. physical layout, traffic lighting, noise level) Observation is relatively inexpensive compared with other fact-finding techniques. Other techniques usually require substantially more employee release time and copying expenses. Observation allows the systems analyst to do work measurements. Disadvantages Because people usually feel uncomfortable when being watch, they may unwittingly perform differently whesobeing absesved. studocu Downloaded by Soloman’ Msigala (selomanims'gala@[Link]) The work being observed may not involve the level of difficulty or volume normally experienced during that time period. Some systems activities may take place at odd times causing a scheduling inconvenience for the systems analyst. ‘The tasks being observed are subject t various types of interruption. Some tasks may not always be performed in the manner in which they are observed by the systems analyst, For example, the systems analyst might have observed how a company filled several customer orders. However, the procedures observed may have been those steps used to fil a number of regular customer orders. If any of those orders had been special orders (e.g. an order for goods not normally kept in stock), the systems analyst would have observed a different set of procedures being executed. If people have been performing tasks in a manner that violates standard operating procedures, they may temporarily perform their jobs correctly while you are observing them. In other words, people may let you see what they you want you to see. Questionnaires Questionnaires are special-purpose documents that allow facts to be gathered from a large number of people while maintaining some control over their responses. When dealing with a large audience, no other fact-finding technique can tabulate the same facts as efficiently. There are two types of questions that cam be asked in a questionnaire, namely free- format and fixed-format. Free-format questions offer greater freedom in providing answers. A question is asked and the respondent records the answer in the space provided after the question. Examples of fiee-format questions are: ‘What reports do you currently receive and how are they used?” and ‘Are there any problems with these reports?” If'so, please explain. The problems with free-format questions are that the respondent's answers may prove difficult to tabulate and, in some, may not match the questions asked. Fixed-format questions require responses from individuals. Given any question, the respondent must choose from the available answers. This means the results mich easier to tabulate, On the other hand, the respondent cannot provide additional information. An example of a fixed-format question is: “The current format of the report on property rentals is ideal and should not be changed?” The respondent may be given the option to answer ‘Yes’ or ‘No’ to this question or be given the option to answer from a range of responses inchding ‘Strongly Agree’, ‘Agree’, ‘No Opinion’, ‘Disagree’, and “Strongly Disagree’. Advantages Most questionnaires can be answered quickly. People can complete and retum questionnaires at their convenience. Questionnaires provide a relatively inexpensive means for gathering data from a large number of individuals. Questionnaires allow individuals to maintain anonymity. Therefore, individuals are more likely to provide the real facts, rather than telling you what they think their boss would want them to, Responses can be tabulated and analyzed quickly. Disadvantages The number of respondents is often low. There’s no guarantee that an individual will answer or expand on all the questions. Downloaded by Soloman’ Msigala (selomanims'gala@[Link]) 1) 1) 2) 1) 2) 3) 5) Questionnaires tend to be inflexible. There’s no opportunity for the systems analyst to obtain voluntary information from individuals or to reword questions that may have been misinterpreted. It is not possible for the systems analyst to observe and analyze the respondent’s body language. ‘There is no immediate opportunity to clarify a vague or incomplete answer to any question. Good questionnaires are difficult to prepare. Documentary Review Itinvolves perusing through literature to gain a better understanding of the existing system The documents to be reviewed will incide: job descriptions, procedure manuals, management reports, and sales report [Link]. When to Use Documentary Review When a system analyst wants to have a quick overview of a system When the information requited cannot be obtained using other techniques. Merits It is comparatively cheaper. It is a faster means of information gathering especially if the documents are few. Demerits It may be time consuming and requires alot of patience. The relevant information maybe missing The success depends on the experience and skills of the system analyst ‘Most of the information available may be outdated. The information available may not suit well with the requirements of the system proposed. Sampling This is a process of systematically selecting representative elements of a population when these elements are examined closely; it is assumed that the analysis will reveal useful information about the population as a whole. In the language of sampling: -apopulation is the entire collection of people or things you are interested in; -acensus is a measurement of all the units in the population; -apopulation parameter is a number that resus from measuring all the units in the population; -asampling frame is the specific data from which the sample is drawn, e.g., a telephone book; -aunit of analysis is the type of object of interest, e.g., arsons, fire departments, firefighters; -asample is a subset of some of the units in the population; -astatistic is a number that results from measuring all the units in the sample; -statistics derived from samples are used to estimate population parameters, For example, to find out the average age of all motor vehicles in the state in 1997: Population=all motor vehicles in the state in 1997 Sampling frame=all motor vehicles registered with the DMV on July 1, 1997 Design=probability sampling Unit of analysis=motor vehicle Sample=300 motor ybitlesnents slab on § studocu Downloaded by Soloman’ Msigala (selomanims'gala@[Link]) Data gathered=the age of each of the 300 motor vehicles selected in the sample Statistic=the average age of the 300 motor vehicles in the sample Parameter=the estimate of the average age of all motor vehicks in the state-1997 ‘Types of Samples: Non-probability (non-random) samples: ‘These samples focus on vohmnteets, easily available units, or those that just happen to be present when the research is done. Non-probability samples are useful for quick and cheap studies, for case studies, for qualitative research, for pilot studies, and for developing hypotheses for future research a. Convenience sample: Also called an “accidental” sample or "man-in-the- street" samples. The researcher selects units that are convenient, close at hand, easy to reach, etc. b. Purposive sample: The researcher selects the units with some purpose in mind, for example, students who live in dorms on campus, or experts on urban development. ¢. Quota sample: The researcher constructs quotas for different types of units, For example, to interview a fixed number of shoppers at a mall, half of whom are male and half of whom are female. Other samples that are usually constructed with non-probability methods incude library research, participant observation, marketing research, consulting with experts, and ‘comparing organizations, nations, or governments Probability-based (random) samples: a. Simple random sample: Each unit in the population is identified, and each unit has an equal chance of being in the sample. The selection of each unit is independent of the selection of every other unit. Selection of one unit does not affect the chances of any other unit b. Systematic random sampling: Each unit in the population is identified, and each ‘unit has an equal chance of being in the sample. ¢. Stratified random sampling: Each unit in the population is identified, and each unit has a known, non-zero chance of being in the sample. This is used when the researcher knows that the population has sub-groups (strata) that are of interest. 4, Cluster sampling: cluster sampling views the units in a population as not only being members of the total population but as members also of naturally-occurring in clusters within the population, For example, city residents are also residents of neighborhoods, blocks, and housing structures. When to Use Sampling 1) When the target population is too large. 2) When the population has similar characteristics Merits 1) Itis cheaper considering the target population, 2) It speeds up the data gathering process. 3) Itis effective since one obtains accurate information, which is assumed to be representative Demerits 1) One requires statistical knowledge to use the method. 2) The sample taken may not be representative of the entire population and may overlook certain critical issues. Downloaded by Soloman’ Msigala (selomanimsigala@[Link]) iti, iv. Research and survey/site visit This involves thorough research of the applications and problems of the old system. The analyst must review trade joumals, periodicals and books containing relevant information He can also attend professional meetings, seminars and visiting others companies which have similar systems. Existing computerized system The user requirement of anew computerized system can ako be collected from the existing computer system. The way work is done is analyzed and improvement suggested. The ateas looked at are: File structures Transaction volumes Screen design User satisfaction Causes of system crash [Link]. Software Requirements Specification (SRS) document ‘The important parts of SRS document ate: i Functional requirements of the system: The functional requirements part discusses the functionalities required fiom the system. The system is considered to perform a set of high-level fictions, Each function of the system can be considered as a transformation of a set of input data to the corresponding set of output data. The user can get some meaningful piece of work done using a high-level function. Non-functional requirements of the system: Nonfimctional requirements deal with the characteristics of the system which cannot be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, etc. Goals of implementation: The goals of implementation part documents some general suggestions regarding development. These suggestions guide trade-off among design goals. The goals of implementation section might document issues such as revisions to the system functionalities that may be required in the future, new devices to be supported in the future, reusability issues, etc. Properties of a good SRS document ‘The important propertics of a good SRS document are the following: a Concise. The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities. Structured. It should be well-structured. A well-structured document is easy to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the customer requirements. Often, the customer requirements evolve over a period of time. Therefore, in order to make the modifications to the SRS document easy, itis important to make the document well-structured. Black-box view. It should only specify what the system should do and refrain from stating how to do these. This means that the SRS document shoukl specify the external behavior of the system and not discuss the implementation issues. The SRS document should view the system to be developed as black box, and should specify the externally visible behavior of the system. For this reas the SRS document is also called the black-box specificatitvn derBeesgyistentzble on studocu Downloaded by Soloman’ Msigala (selomanimsigala@[Link]) 4. Conceptual integrit . Itshould show conceptual integrity so that the reader can easily understand it Response to undesired events. It should characterize acceptable responses to undesired events, These are called system response to exceptional conditions Verifiable. All requirements of the system as documented in the SRS document should be verifiable. ‘This means that it should be possible to determine whether or not requirements have been met in an implementation. Problems without a SRS document ‘The important problems that an organization would face if it does not develop a SRS document are as follows: a, Without developing the SRS document, the system would not be implemented according to customer needs. b. Software developers would not know whether what they are developing is what exactly requited by the customer ¢. Without SRS document, it will be very much difficult for the maintenance engineers to understand the functionality of the system. 4. Ttwill be very much difficult for user document writers to write the users’ manuals properly without understanding the SRS document Problems with an unstructured specification It would be very much difficult to understand that document. It would be very much difficul to modify that document Conceptual integrity in that document would not be shown. The SRS document might be unambiguous and inconsistent. FEASIBILITY STUDY Depending on the results of the initial investigations, the survey is expanded to a more detailed feasibility study. A feasibility study is an activity undertaken to determine the possibility or probability of either improving the existing system or developing a totally new system. A feasibility study is a test of system proposal according to its workability, impact on the organization, ability to meet user needs, and effectively use resources. It focuses on three major questions: What are the user’s demonstrable needs and how does a candidate system meet them? ‘What resources are available for given candidate systems? Is the problem worth solving? ‘What are the likely impacts of the candidate system on the organization? How well does it ft within the organization's master computerization. plan? The objective of feasibility study is not to solve the problem but to acquire a sense of its scope. During the study, the problem definition is crystallized and aspects of the problem to be included in the system are determined. Consequently, costs and benefits are estimated with greater accuracy at this stage. The result of this feasibility study is a formal proposal. This is simply a report —a formal document detailing the nature and scope of the proposed solution, The proposal summarizes what is known and what is going to be done. The report is the medium by which you tell the management what the problem is, what you have found its causes to be and what you have to offer in the way of recommendations. It consists of Statement of the problem — a carefully worded statement of the problem that led to analysis. Summary of findings and recommendations — alist of major findings and recommendations of the study. Clearly describe the subject and scope. List the areas Downloaded by Selomani Msigala (selemanimsigala@[Link]) ii) i iv) included and exchided. It is ideal for the user who requires quick access to the resuks of the analysis of the system under study. Conclusions are stated, followed by a lst of the study recommendations and a justification for them. Details of findings ~an outline of the methods and procedures undertaken by the existing system, followed by coverage of the objectives and procedures of the candidate system. Tnchided are also discussions of the output reports, fle structures and costs and benefits of the candidate system. Recommendations and conclusions — specific recommendations regarding the candidate system, including personnel assignments, costs, project schedules and target dates. ‘fier the report is reviewed by the management, it becomes a formal agreement that paves the way for actual design and implementation. This is a crucial decision point in the life cycle. Many projects die here, whereas the more promising ones continue through implementation, Changes in the proposal are made in writing, depending on the complexity, size and cost of the project. It is important to verify changes before committing the project to design. Types of Feasibility Studies i Technical Feasibility: Technical feasibility assesses whether the current technical resources are sufficient for the new system. ii, Economic Feasibility: Economic feasibility determines whether the time and money are available (o develop the system. Inchides the purchase of, New equipment, Hardware and Software iii, Operational Feasibility: Operational feasibility determines if the human resources are available to operate the system once it has been installed. Users that do not want anew system may prevent it from becoming operationally feasible. iv. Social Feasibility: Determines the impact of the system to the people who will work with the system This may include work schedule, separation of offices, retraining, redeployment and even laying off workers. Awelkdone feasibility study enables the firm to avoid six common mistakes often made in project work. These are: Lack of top management support — top management has to understand and support subordinate managers in their effort to improve the firm's operations. Feasibility studies also get subordinate managers directly involved in exploring and designing the systems they will have to live with in the future. Such involvement results in increased conscientiousness, which in tum enables top management to have more confidence in subordinates’ plans, The result will be top management support for such plans. Failure to clearly specify problems and objectives — the feasibility study can be directed toward defining the problems and objectives involved in a project, after management has given the group some understanding of what they would like to accomplish. Over optimism —a feasibility study can be conducted in an objective realistic manner to prevent overoptimistic forecasts. The study should be conservative in its estimates of improved operations; reduced costs, and so on, to ensure that all the firm's future surprises with a new system are happy ones. Estimation errors —it is easy to underestimate the time and money involved in the following areas: a) Impact on the company’s structure b) Employee’s resistance to change ©) Diticuly ofmamining neon Ey studocu Downloaded by Selomani Msigala (selomanimsigala@[Link]) ) System development and implementation ¢) Computer program debugging and running v) The crash project — many managers do not realize the magnitude of work involved in developing new systems, Crash projects usually involve changing too quickly. A feasibility study might determine that a present system with all its inadequacies is superior to a crash project - assuming of course that the feasibility study itself is not run as a crash project vi) The hardware approach — firms have been known to get a computer first and then decide ‘on how to use it A feasibility study can identify, in advance, the uses to which the computer will be put and can identify the best computers for the job before any ineversible commitments are made. SOFTWARE DESIGN Software design is a process to transform user requirements into some stitable form, which helps the programmer in software coding and implementation. Software Design Levels Software design yields three levels of results a. Architectural Design - The architectural design is the highest abstract version of the system, It identifies the software as a system with many components interacting with each other. At this Ievel, the designers get the idea of proposed solution domain. b. Highdevel Design- The high-level design breaks the ‘single entity-multiple component’ concept of architectural design into less-abstracted view of sub-systems and modules and depicts their interaction with each other. High-level design focuses on how the system along with all of its components can be implemented in forms of modules. It recognizes modular structure of each sub-system and their relation and interaction among each other. c. Detailed Design- Detailed design deals with the implementation part of what is seen as a system and its sub-systems in the previous two designs. It is more detailed towards modules and their implementations. It defines logical structure of each module and their interfaces to communicate with other modules Modularization Modularization is a technique to divide a software system into multiple discrete and independent modules, which are expected to be capable of carrying out task(s) independently. ‘These modules may work as basic constructs for the entire software. Designers tend to design modules such that they can be executed and/or compiled separately and independently. Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving strategy this is because there are many other benefits attached with the modular design of software, Advantage of modularization: ‘© Smaller components are easier to maintain Program can be divided based on functional aspects Desired level of abstraction can be brought in the program Components with high cohesion can be re-used again. Concurrent execution can be made possible Desired from security aspect Downloaded by Selemani Msigala (selemanimsigala@[Link]) Concurrency In software design, concurrency is implemented by splitting the software into multiple independent units of execution, like modules and executing them in parallel. In other words, concurrency provides capability to the software to execute more than one part of code in parallel (o each other. This necessary for the programmers and designers (o recognize those modules, which can be made parallel execution Coupling and Cohesion ‘When a software program is modularized, its tasks are divided into several modules based on some characteristics. ‘There are measures by which the quality of a design of modules and their interaction among them can be measured. These measures are called coupling and cohesion. Cohesion Cobesion is a measure that defines the degree of intra-dependability within elements of a module. The greater the cohesion, the better is the program design. ‘There are seven types of cohesion, namely — ii, Co-ineidental cohesion - It is unpknned and random cohesion, which might be the result of breaking the program into smaller modules for the sake of modularization, Because it is unplanned, it may serve confision to the programmers and is generally not-accepted. iv. Logical cohesion - When logically categorized elements are put together into a module, it is called logical cohesion, vy. Temporal Cohesion - When cments of module are organized such that they ate processed at a similar point in time, itis called temporal cohesion. vi Procedural cohesion - When elements of module are grouped together, which are executed sequentially in order to perform a task, it is called procedural cohesion. vii Communicational cohesion - When elements of module are grouped logether, which are executed sequentially and work on same data (information), it is called communicational cohesion. vii, Sequential cohesion - When elements of module are grouped because the ‘output of one element serves as input to another and so on, it is called sequential cohesion. ix Fumetional cohesion -It is considered to be the highest degree of cohesion, and it is highly expected. Elements of module in functional cohesion are grouped because they all contribute to a single well-defined function, It can also be reused. Coupling Coupling is a measure that defines the level of inter-dependability among modules of a program. It tells at what level the modules interfere and interact with each other. The lower the coupling, the better the program. There are five levels of coupling, namely - i, Content coupling - When a module can directly access or modify or refer to the content of another module, it is called content level coupling ii, Common coupling- When multiple modules have read and write access to some global data, itis called common or global coupling. iv. Control coupling- Two modules are called control-coupled if one of them decides the function of the other module or changes its flow of execution, vy. Stamp coupling- When mutipkggodules share common data structure and work on tiflérentepartst ot is Coy SEUAOCUn:. Downloaded by Selomani Msigala (selemanimsigala@[Link]) vi Data coupling- Data coupling is when two modules interact with each other by means of passing data (as parameter). If a module passes data structure as parameter, then the receiving module should use all its components Software design strategies ‘There are multiple variants of software design; i, Structured Design Structured design is a conceptualization of problem into several well-organized elements of solition, Itis basically concemed with the solution design. Benefit of structured design is, it gives better understanding of how the problem is being solved. Structured design also makes it simpler for designer to concentrate on the problem more accurately. Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken into several small problems and each small problem is individually solved until the whole problem is solved. ‘These modules are arranged in hierarchy. They communicate with each other. A good structured design always follows some rules for communication among multiple modules, namely - Cohesion - grouping of all functionally related elements. Coupling - communication between different modules. A good structured design has igh cohesion and low coupling arrangements, Function Oriented Design In function-oriented design, the system is comprised of many smaller sub-systems known as functions. These functions are capable of performing significant task in the system. The system is considered as top view of all functions, Function oriented design inherits some properties of structured design where divide and conquer methodology is used. ‘This design mechanism divides the whole system into smaller functions, which provides means of abstraction by concealing the information and their operation. These functional modules can share information among themselves by means of information passing and using information available globally. Design Process ‘© The whole system is seen as how data flows in the system by means of data flow diagram. DFD depicts how functions change the data and state of entire system. The entire system is logically broken down into smaller units known as functions on the basis of their operation in the system. ‘+ Each fiction is then described at large. fii, Object Oriented Design Object oriented design works around the entities and their characteristics instead of finctions involved jin the software system. ‘This design strategy focuses on entities and is cl ‘The whole concept of software solution revolves around the engaged entities Let us see the important concepts of Object Oriented Design: * Objects - All entities involved in the solution design are known as objects. For example, person, banks, company and customers are treated as objects. Every Downloaded by Slomani Msigala (selomanimsigala@[Link]) entity has some attributes associated to it and has some methods to perform on the attributes. * Classes -A class is a generalized description of an object. An object is an instance of a class. Class defines all the attributes, which an object can have and methods, which defines the fimctionality of the object. In the sohition design, attributes are stored as variables and functionalities. are defined by means of methods or procedures. + Encapsulation -In OOD, the attributes (data variables) and methods (operation on the data) are bundled together is called encapsulation. Encapsulation not only bundles important information of an object together, but also restricts access of the data and methods fiom the outside world. This is called information hiding. * Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or sub-classes can import, implement and re-use allowed variables and methods from their immediate super classes. This property of OOD is known as inheritance. This makes it easier to define specific class and to create generalized classes from specific ones. + Polymorphism - OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned same name. This is called polymorphism, which allows a single interface performing tasks for different types. Depending upon how the function is invoked, respective portion of the code gets executed. DesignProcess ‘© Assolution design is created from requirement or previous used system and/or system sequence diagram ‘© Objects are identified and grouped into classes on behalf of similarity in attribute characteristics. Chass hierarchy and relation among them are defined. Application framework is defined. Software Design Approaches ‘There are two generic approaches for software designing: i, Top down Design ‘Top-down design takes the whole software system as one entity and then decomposes it to achieve more than one sub-system or component based on some characteristics. Each sub-system or component is then treated as a system and decomposed further. This process keeps on running until the lowest level of system in the top-down hierarchy is achieved Top-down design starts with a generalized model of system and keeps on defining the more specific part of it, When all components are composed the whole system comes into existence. Top-down design is more suitable when the software sohition needs to be designed from scratch and specific details are unknown, ii, Bottom-up Design ‘The bottom up design model starts with most specific and basic components. It proceeds with composing higher level of components by using basic or lower level components. It keeps creating higher level components until the desired system is not evolved as one single component. With each higher level, the amount of abstraction is increased, Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the basic primitives can be used in the newer system. ‘wedowmersonnsen Ey studocu Downloaded by Selomani Msigala (selomanimsigala@[Link]) Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is used. Software Analysis & Design Tools Software analysis and design includes all activities, which help the transformation of requirement specification into implementation, Requirement specifications specify all fanctional and non-functional expectations from the software. These requirement specifications come in the shape of human readable and understandable documents, to which a computer has nothing to do. 1. Data Flow Diagram Data flow diagram is a graphical representation of data flow in an information system. It is capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not ‘mention anything about how data flows through the system, Types of DED Data Flow Diagrams are either Logical or Physical. a Logical DFD - This type of DFD concentrates on the system process and flow of data in the system For example in a Banking software system, how data is moved between different entities ». Physical DED - This type of DFD shows how the data flow is actually implemented in the system. It is more specific and close to the implementation. DED Components DED can represent Source, destination, storage and flow of data using the following set of ‘components — External Entity Process Output —— Data Flow Data Store ‘+ Entities - Entities are source and destination of information data. Entities are represented by rectangles with their respective names. ‘© Process - Activities and action taken on the data are represented by Circle or Round- edged rectangles. ‘© Data Storage - There are two vatiants of data storage - it can either be represented as a rectangle with absence of both smaller sides or as an open-sided rectangle with only one side missing. ‘+ Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the base of arrow as its source towards head of the arrow as destination. Downloaded by Selemani Msigala (selemanimsigala@[Link]) Context Diagram: It represents the context in which the system is to exist, ie. the external entities who would interact with the system and the specific data items they would be supplying the system and the data items they would be receiving from the system Shortcomings of a DFD model i DFDs leave ample scope to be imprecise - In the DFD model, the function performed by a bubble is judged from its label ii Control aspects are not defined by a DFD- For instance; the order in which inputs are consumed and outputs are produced by a bubble is not specified. A DFD model does not specify the order in which the different bubbles are executed. Representation of such aspects is very important for modeling real-time systems. iii, The method of carrying out decomposition to arrive at the successive levels and the ukimate level to which decomposition is cartied out ate highly subjective and depend on the choice and judgment of the analyst. Due to this reason, even for the same problem, several alternative DFD representations are possible. Further, many times it is not possible to say which DFD representation is superior or preferable to another one, iv. The data flow diagramming technique does not provide any specific guidance as to how exactly to decompose a given fimction into its sub-fmctions and we have to use subjective judgment to cay out decomposition, Reasons why large programs fail or are not completed on schedule? Due to inability to make realistic program design schedules and meet them. Reasons inclide:- ‘© Underestimation of time to gather requirements and define system functions ‘Underestimation of time to produce a workable (cost and time) program design. Underestimation of time (o test individual prograns. Underestimation of time to integrate complete program into the system and complete acceptance tests. Underestimation of time and effort needed to correct and retest program changes. Failure to provide time for restructuring program due to changes in requirements, ‘© Failure to keep documentation up-to-date. Underestimation of system time required to perform complex functions. ‘Underestimation of program and data memory requitements. Tendency to set end date for job completion and then to try to meet the schedule by attempting to bring more manpower to the job by splitting job into program design blocks in advance of having defined the overall system plan well enough to define the individual program blocks and their appropriate interfaces CODING Coding- The objective of the coding phase is to transform the design of a system into code in a high level language and then to unit test this code. The programmers adhere to standard and well defined style of coding which they call their coding standard. The main advantages of adhering toa standard style of coding are as follows © Accoding standard gives uniform appearances to the code written by different engineers ‘© It facilitates. code of understanding. ‘© Promotes good programming practices. programming language showkLuveotuosolo wl locu \@[Link]) For implementing our design into a code, we * ‘ [Link] high level language. A Downloaded by Selemani Msigala (slemanimsig Characteristics of a Programming Language Readability: A good high-level language will allow programs to be written in some ways that resemble a quite-English description of the underlying algorithms. If care is taken, the coding may be done in a way that is essentially self-documenting. Portability: High-level languages, being essentially machine independent, should be able to develop portable software. Generality: Most high-level languages allow the writing of a wide variety of programs, thus relieving the programmer of the need to become expert in many diverse languages. Brevity: Language should have the ability to implement the algorithm with Jess amount of code. Programs expressed in high-level languages are often considerably shorter than their low-level equivalents. Error checking: Being human, a programmer is likely to make many mistakes in the development of a computer program. Many high-level languages enforce a great deal of error checking both at compile-time and at run-time. Cost: The ultimate cost of a programming language is a fimction of many of its characteristics. Familiar notation: A language should have familiar notation, so it can be understood by most of the programmers. Quick translation: It should admit quick translation Efficiency: It should permit the generation of efficient object code. ‘Modularity: Itis desirable that programs can be developed in the language as a collection of separately compiled modules, with appropriate mechanisms for ensuring self-consistency between these modules Widely available: Language should be widely available and it should be possible to provide translators for all the major machines. and for all the major operating systems. TESTING Definition 2 Testing involves actual execution of program code using representative test data sets to exercise the program and outputs are examined to detect any deviation from the expected output Definition 1 Testing is classified as dynamic verification and validation activities Reviews can be applied to: Requirement specifications High level system designs Detailed designs Program code User documentation Operation of delivered system Objectives of Testing To demonstrate the operation of the software. To detect errors in the software and therefore: Obtain a level of confidence, Produce measure of quality. Downloaded by Selemani Msigala (selemanimsigala@[Link]) ‘THE TESTING PROCESS ‘Systems in this case are tested, as a single unit therefore testing should proceed in stages, where testing is caied out incrementally in conjunction with system implementation. ‘The most widely used testing process consists of 5 stages: (a) Unit testing (b) Module testing (©) Sub-system testing (@ System testing (©) Acceptance (alpha) testing. (A) UNIT TESTING Unit testing is where individual components are tested independently to ensure they operate correctly. (B) MODULE TESTING A module is a collection of dependent components e.g. an object class, an abstract data type or collection of procedures and functions. Module testing is where related components (modules) are tested without other system modules. (©) SUB-SYSTEM TESTING ‘Sub-systems are integrated to make up a system. Sub-system testing aims at finding errors of unanticipated interactions between sub-systems and system components, Sub-system testing also aims at validating that the system meets the functional and non-functional components. (D) ACCEPTANCE TESTING (ALPHA TESTING) ‘Acceptance testing is also known as alpha testing or last testing In this case the system is tested with real data (from client) and not simulated test data. Acceptance testing: > Reveals errors and omissions in systems requirements definition, > Test whether the system meets the users’ needs or if the system performance is acceptable. Acceptance testing is carried out till users /clients agree it’s an acceptable implementation of the system NB 1:Beta testing Beta testing approach is used for software to be marketed, It involves delivering it to a mmber of potential customers who agree to use it and report problems to the developers. Afr this feedback, it is modified and released again for another beta testing or general use, NB 2: ‘The five steps of testing are based on incremental system integration i. (Unit testing — module testing — sub-system testing - system testing- acceptance testing). But object otiented development is different and kevels have cleat/ distinct > Operations and data forms objects —uits > Object integrated forms class (equivalent to) —modules ‘Therefore css testing is chister testing MODES OF TESTING 1. Black Box Functional Testing This is based on specification alone, without reference to implementation detail. 2. White Box Or StructurakniGabessnches tingabie on studocu Downloaded by Selemani Msigala (selomanimsigala@[Link]) © ra ra G This is based on inspection of code structure (implementation details, low level design) Black Box Functional Testing Techniques The test cases are derived from specification of the module /system /sub-system under test ‘The actual and expected results are compared. ‘Techniques Equivalence partitioning Boundary value analysis. juivalence _partitionin; Equivalence partitioning involves breaking down the input data into sets regarded as “equivalent” It relies on an assumption of “uniform behavior within ranges of input values that are not significantly different in terms of the specification, Eg. -A program must handle from 1 to 10,000 records. -Ifit can handle 40 records and 9,000 records chances are that it will work with 5,000 records. -Therefore chances of detecting fault (if present) are equally good if any test case fom 1- 10,000 is selected. new line add 1 to Character count Else Add 1to line Count ‘While not end of file Print character and line count ~ Test cases are created to guarantee that every statement is executed at least once, Basis of test cases: 123678 1235678 1234672 1235672 ‘TEST PLANNING Test planing is setting out standards for the testing process rather than describing product tests Test plans allow developers get an overall picturg, of the system tests as well as ensure required hardware, softwartociesaumcesisaRoaval studocutean Downloaded by Soloman’ Msigala (selomanims'gala@[Link])

You might also like