Software Engineering Supplementary Lectures

San Sebastian College - Recoletos de Cavite Department of Computer Studies

SOFTWARE ENGINEERING INTRODUCTION As the software cost of computer hardware decreases it means that the current demand for software is increasing tremendously. We cannot meet the demand by increasing the number of software engineers. We must apply the effective software engineering techniques and technology to tackle this problem. Computer is an art as well as science. It is a science as it pertains to the study of computer mechanisms and theorize about how to make them more productive or efficient. It is an art as it designs computer systems or write programs to performs tasks on a particular system. Therefore, SOFTWARE ENGINEERING is about designing and developing high quality software. PURPOSE: To know the methodology for the development of quality, cost effective and scheduled meeting software. The term “software engineering” was first introduced in the late 1960‟s at a conference held to discuss what was then called the “software crisis”. This software crisis resulted directly from the introduction of the third generation of computer hardware where machines are more powerful that requires large software systems that existing methods of software developments were not good enough. Major projects were sometimes late, costly, unreliable, and difficult to maintain and performed poorly. New techniques and methods were needed to control the complexity inherent in large software systems. Other Definitions of Software Engineering the evolution and use of helpful tools and techniques for software developments concerned with building programming products and programming systems products design and development of software from concepts through execution and documentation

CHARACTERISTICS OF HIGH-QUALITY SOFTWARE 1. General Utility – measure how useful a software system is to those who are supposed to use it. 2. Portability – the system can be moved from one computer to another and still function properly. The overall configuration remains the same, but hardware and software is upgraded to newer model. 3. Maintainability – it is easy to make changes as the need requires it. The users and programmers must find the system easy to learn and to use. A system may be very good at performing a function, but users cannot understand how to use it, the system is a failure. 4. Reliable and Efficient – by reliability, we mean that the system produces the correct result to the correct degree of accuracy. In this case, the system has integrity. Furthermore, if the same set of input is submitted to the system many times under the same conditions, the result should match. This is called consistency of function.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Aspects of Software Quality 1. compliance – whether the system does as required 2. modifiability – whether the system can be changed, for repair or improvement, with relative ease 3. reliability – whether an apparently compliant system goes as being so Other 1. 2. 3. considerations: Safety – freedom from damage Security – freedom from illegal duplication Integrity – complete, whole

Software is of high-quality if: 1. It does what the user wants it to do. 2. It uses computer resources correctly and efficiently 3. It is easy for the user to learn and use. 4. The developers can design, code, test and maintain the system with relative ease. THE FUNDAMENTAL PROPERTIES OF SOFTWARE 1. Software is the dynamic behavior of programs when they operate on and interact with the equipment for which they were designed. 2. A program is an intellectual construction expressed in a formal language. 3. Programs comprise algorithms and data definitions 4. Languages for expressing programs may be categorized as ultra-low, low, high, and very high level. 5. Programs are translated as the means of rendering them suitable to activate the hardware. 6. Number-based transformations of program statements or data are far easier than they seem at first sight. 7. Usage of computer may be at very high level; or at lower levels. CLASSIFICATION OF SOFTWARE SYSTEMS 1. Predominant, generic function – where “predominant” may mean “most difficult to achieve” rather than most numerous 2. Systems‟ requirement determines temporal (limited) properties, within the software or concerning its response 3. Software system size 4. Purpose as distinct from specific requirement – for example, prototype 5. Lehman‟s “S, P and E” properties of requirement Classification by Predominant function Categories of application and language design 1. The computational paradigm - involves high order mathematical and logical transformations on aggregates of numerical data, where the accuracy of computation may be important - software systems for applications of this type most often contain little time critically no need for “parallel” or “concurrent” sub-processes within them. - A subclass of this, for speed up computation, is a “process-oriented” application

San Sebastian College - Recoletos de Cavite Department of Computer Studies

2. The data processing paradigm - Involves low order transformations on possibly extremely high volumes of alphanumeric information, represented either as sequential files of data, or non sequential records with a set of logical pointers attached - Software systems for applications of this type are known as “on-line” (low order criticality) or “batch” (none) systems - Seldom incorporates “parallel” or “concurrent” sub-processes - Regarded as a part of “process-oriented” applications 3. The process-oriented paradigm - usually involves low or medium order properties of the first two types – but with high order time criticality of the whole or parts of the system - software applications of this type requires parts of a system to operate in parallel or concurrently - a prevalent type of application of this sort is commonly known as “real-time, embedded systems” 4. The rule-base paradigm - involves properties of all the three proceeding types - high order criticality – computation, data processing and time – critical processes Classification by temporal properties 1. Batch (or “offline”) software systems - for applications, generally in computation or data processing, have no particular response-time requirements attaching to answers to human users, or replies to other parts of a system - “batch” is derive from the use of a scheduler within the virtual computer complex – this arrives at the next job, in a series of such, in sequence; the series is called a “batch” of such jobs - “off-line” term is used to denote a lack of time-criticality for a software system – derive from a practice of generating results on s device attached to the computer (tape or disk), and then using this as input to a free-standing device (typically a printer) to display the output. - Turn-around time – is the duration between submitting the programs to run on a computer and getting the results back – hours or even days - Used in the early days, through nowadays used to run a batch workload as a background task 2. On-line software systems - for applications, generally in computation (e.g. CAD) and data processing (e.g. transaction oriented), in which some system response within the normal human reaction or interest is required - time period is generally held to be between a few seconds and some what less than half a minute - started out in the 70‟s 3. Real-time software systems - for applications, generally process sector or for current research into rule-based systems, in which there is some extremely strict requirements for system response, usually within a duration well below that of human reaction time

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Classification of software by size 1. Small, up to 2,000 source statements - games on PC - embedded systems limited functionality such as the program setting controller on a car radio, washing machine, etc 2. Medium, 2,000 to 100,000 source statements - a very wide range of computing, data processing and process applications, such as for matrix inversion, payroll etc., CAD/CAE 3.Large, 100,000 to 1,000,000 source statements - operating systems for computers, including most “virtual” features - extensive computation and simulation systems and full-scale administrative systems for banking transactions - artificial intelligence and expert systems 4.Very large, over 1,000,000 source statements - large scale command systems, weather forecasting, medical topography, higher order AI and expert systems Classification by Purpose 1. Prototypes Prototype – an original pattern or model effected to increase knowledge Prototype development is the process of buying information Reasons for buying information a. That sufficient is known about the requirements -- requirements‟ prototype b. That sufficient is known about the means of solution – actually how to develop software system to provide the requirements, given that these are sufficiently well known. -- feasibility prototypes In software development prototyping can be one of two things: a. scope of specifications, or their detail b. technical means to bring about a (software) solution The main imperative of prototypes – that of buying information usually at the lowest cost in effort and time – is in opposition to the quality of the artifacts produced. Prototypes should be labeled clearly, and software engineering that involves prototyping must be designated clearly in those part of the process. 2. Projects Projects, in the software sense, are the development undertaken for a single, identifiable end client. - they may be a part of a wider context of development and supply, and most often involve explicit and potentially strict contract terms between client and supplier.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

A software development for a single, identifiable end client, has the advantage of a clear source of requirements and an equally clear agency for the acceptance, or rejection, of the final artifacts. Whoever is to do the development can interrogate the users‟ or user‟s representatives to adduce their needs, and can later confirm with them that they have been supplied. 3. Products Products are artifacts developed for a plurality of end clients. - may include externally or internally contracted supplies on a real or false fixed price, „project‟ basis, for subsystems. - are mainly undertaken by companies ambitious to sell many units of the product to a defined market sector. Lehman‟s Classification 1. S programs – those derived from a fixed, formal specification - S systems refer to software systems that are formally specifiable and, therefore provable; moreover their specification will be invariant, not only during development but thereafter. - are generally very small in source code statements – 500 to 1,000 - mainly done by hobbyist and people learning how to program 2. P programs – those derived from inexact formulation of a real world problem - P software systems, or programmable ones - means of solution is approximation e.g. linear programming approximation weather forecasting - usually slow rate of change – 5 to 10 years or more - size is from the upper end of „medium‟ to a „very large‟ scale 3. E programs – those whose derivation will be likely to change through their being embedded in a part of the real world. - E or evolvable software – is both specifiable and solvable - specification may be produced by informal process - solution means may or may not involve prototypes - specification is temporary one, an approximation that is valid for sometime and will probably change over some period - software „solution‟ will have to be evolved from time to time PROBLEMS WITH SOFTWARE DEVELOPMENT 1. Changing constraints and requirements Review of system at every step would mean changes in a design and therefore softwareengineering tools must be flexible for this. 2. Phased development systems It involves the phased development approach wherein we must workout some sequence of implementation so that our new system replaces the old one gradually. We often work with the previous phased is in use (a) development (b) production. The development systems is used to design, code and test parts of the new system. When we convince that the new phased is ready

San Sebastian College - Recoletos de Cavite Department of Computer Studies

to replaced the existing system, the new code is combined with the old on the active production system. We usually duplicate many of the development steps. There is a great deal of room for error; the techniques used have not always been able to handle the complexities of the phased developments. 3. Interactions with other systems Developing a system is complex because they require a great deal of coordinates with other systems. It should assure accuracy and completeness of the documentation of interfaces among systems. 4. The nature of computer system The type of computer and data they handled. PARTICIPANTS IN SOFTWARE DEVELOPMENT

CUSTOMER
payments contractual obligation

DEVELOPER
software system needs & requirements conveyed

USER

San Sebastian College - Recoletos de Cavite Department of Computer Studies

PROJECT MANAGEMENT The first layer of software engineering process. It includes activities such as measurements, tracking and control. Measurements and Metrics It helps to understand the technical process that is used to develop a product and the product itself. The process is measured in an effort to improve it. The PRODUCT is measured in an effort to increase its quality. Estimations Estimates of required human effort, chronological project duration and cost must be derived. Risk analysis A series of risk management steps enable us to “attack” risk: 1. identification 2. assessment 3. prioritization 4. management strategies 5. resolution 6. monitoring Risk analysis is actually 4 distinct activities: Identification, Projection, Assessment and Management 1. Risk Identification. It is possible to categorize risk as: a. Project risks – identify potential budgetary, schedule, personnel, resource, customer and requirements problem and their impact on software project. b. Technical risks – identify potential design, implementation, interfacing, verification and maintenance problem. They occur because a problem is harder to solve than we thought it would be c. Business risks: 1. building a software that no one really wants 2. building a product that no longer fits into the overall strategy of the company 3. building a software that sales force doesn‟t understand how to sell 4. losing the support of senior management due to change in focus or a change in people 5. losing budgetary or personnel commitment 2. Risk Projection. Is the attempt to rate each risk in two ways – the likelihood that the risk is real and the consequences of the problems associated with the risk should it occur. 3. Risk Assessment. Further examination of the accuracy of the estimates that were made during risks projection, attempt to prioritize the risks projection, attempt to prioritize the risk that has been uncovered and begin thinking about ways to control and/or avert the risk likely to occur.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

4. Risk Management and Monitoring. The process of preventing the occurrence of risk by taking the necessary precautionary steps. Scheduling A set of project tasks is identified. Interdependencies among tasks are established. The effort associated with each task is estimated. People and other resources are assigned. A TIMELINE schedule is developed. Tracking and Control The project management tracks each tasks in the schedule. If a task falls behind schedule, the manager may determine the impact of schedule slippage and may issue control measures. Metrics for Software Productivity and Quality Software is measured for many reasons: 1. To indicate the quality of the product. 2. To assess the productivity of the people who produce the product. 3. To assess the benefits derived from new software engineering methods and tools 4. To form a baseline for estimation 5. To help justify request for new tools or additional training Categories of Measurements 1. Direct Measurement – include cost and effort applied. Measure of product includes the following: a. no. of lines of code (LOC) produced b. execution speed c. defects reported over a period of time 2. Indirect measures – as to quality a. functionality b. quality c. complexity d. efficiency e. reliability f. maintainability Productivity metrics focuses on the output of the software engineering process Quality metrics provides an indication of how closely software conforms to implicit and explicit customer requirements Technical metrics focuses on the character of the software rather than the process through which the software was developed

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Size-oriented metrics is the direct measure of software and the process by which it is developed Productivity = KLOC/month-person Quality = defects/ KLOC Cost = $/KLOC Documentation = pages of documents / KLOC Function-oriented metrics focuses on the program functionality or utility Function points – a particularly measurement approach. It is delivered using an empirical relationship based on countable measure of software‟s information domain and assessment of software complexity. Information Domain Values 1. No. of user input – each user that provides distinct application oriented data 2. No. of user output – refers to reports, screens, error messages. Individual data item is not counted. 3. No. of files – each logical master file or separate files. 4. No. of user inquiries – refers to on-line input that results in the generation of some immediate software response in the form of on-line output 5. No. of external interfaces – machines readable interfaces that are used to transmit information to another system Metrics for Software Quality 1. Correctness. The most common measures standard period of time is one year. C = defects / KLOC 2. Maintainability. Is the case with which a program can be corrected if an error is encountered, adapted if its environment changes or enhanced if the customer desires a change in requirement 3. Integrity. This measures the system‟s ability to withstand attacks to its security. 4. Usability. Measure of how user-friendly the system is. The Project Schedule A project schedule describes the software development cycle for a particular project. It enumerate the phases or stages of the project, breaks each into discrete tasks or activities to be done, portrays the interaction the interaction among these pieces of work, and estimates the time that each task or activity will take. Deliverables List all items that the customer expects to see during the developments of the project. These items are called deliverables and can include:  Documents  Demonstrations of subsystems  Demonstrations of accuracy  Demonstrations of reliability, security, speed

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Activities and Milestones Second, we analyze the development and designated certain clearly defined events as milestones. These include that a measurable level of progress has been made. An activity is a part of the project that takes place over a period of time, and a milestone is the completion of an activity. Phases of the Schedule Separate development into a succession of phases. Each phases is composed of steps, each step can be subdivided further, if necessary. Work-breakdown Structure and Activity Graph Work-breakdown structure exhibits the project as a set of discrete piece of work. However, this structure fives no indication of the interdependence of the work units; neither does it show which part of the project can be developed concurrently. A graph is used to depict the dependencies. The nodes of a graph are the milestones of the projects, and the lines linking the node represents the activities involved. This type of graph is called the activity graph. Scheduling Methods The Program Evaluation Review Techniques (PERT) and the Critical Path Method (CPM) are the two project scheduling methods that can be applied to software development Example of Work-breakdown Structure Phase 1 Step 1.1 Step 1.2 Step 1.3 Step 2.1 Step 2.2

Activity 1.3.1 Activity 1.3.2

Phase 2

The Activity Graph Critical Path Analysis. This method determines which activities should be started and finished on the scheduled time, and those activities that can be delayed. In this method, we will compute for 4 values: the earliest start time, earliest finish time, latest start time, latest finish time. Critical path is determined when an activity has no slack time. (ES=LS, EF=LF). Personnel Characteristics In selecting the personnel of a software development team, there are 2 major aspects to be considered: differences in background and differences in work styles.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Differences in background 1. ability to perform the work at hand 2. comfort – preferences or work habits 3. interest in work 4. experience training 5. communication with one another – ability to communicate ideas 6. ability to share – learning to trust and be a team player 7. management skills – know how to delegate work properly Differences in work styles Your approach to work as affected by: the way in which your thoughts are communicated and ideas gathered and the degree to which your emotions affect decision making. 1. Extrovert – people who speak out their through and ideas 2. Introvert – people who ask suggestions before expressing their opinions 3. Intuitive – people who based their opinions/decisions on their feelings about and emotional reaction to problem 4. Rational – they choose a course of action after careful and reasoned consideration of all options Rational Extrovert – assets their ideas and does not let emotions affect decision making. They rely of logic. They rarely ask for information. Rational Introvert – they also avoid emotional decisions. They are information gatherers and does not feel comfortable making decisions until all possible options are explored. Intuitive Introvert – based decisions on emotional reaction and tend to tell others about them rather ask for inputs. They use intuition to be creative and often suggest unusual approaches to a problem Project Team Organization 1. Highly structured. Typical organization where there is one person at the top overseeing these people under him. 2. Loosely structured / Egoless. Holds everyone equally responsible. It is more democratic. SOFTWARE DEVELOPMENT LIFE CYCLE MODELS Life Cycle – a directed graph, normally in box and arrow notation of main activities in software development. - generally used as a management model of the process, conceptually adequate if not simplified.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Early ideas about the software development process: A “stagewise” model, one of the earliest models: 1. 2. 3. 4. 5. 6. 7. Operations plan Operations Specification Coding specification Coding activity Parameter testing Shakedown System evaluation

Guidelines for a non-vacuous life cycle models: 1. They act as shared conceptual model and are limited (but serviceable) - Vocabulary of what is going on, or should be going on, in a software development 2. They greatly facilitate the management of software development - any form of lifecycle is a project management structure Essential features lacking in the early models: 1. Any notion of back-tracking in the event of additional clarification, or discovery of prior omission, or error. 2. Any anticipation of changes to the scope or detail of specification, or need to develop prototypes to find out about them 3. Any concept that, even after completion, the system may have to be evolved. 4. Any idea of a design stage, between specification stages and coding 5. Any requirement for quality control and assurance, or reference to the system‟s documentation Later developments, and the value of criticism: 1. Cascade or waterfall model (circa 1970) The model shows the following: a. limited feedback between contiguous activities b. limited recognition of the need, or occasion, to develop prototypes c. no clear recognition of specification changes, or evolutions of the system after completion d. a clear indication of design as an identifiable activity e. only a very limited view of the quality issues, but a clear statements on documentation 2. An evolved “waterfall” model (circa 1975-80): Major criticisms: a. iteration is restricted to contiguous stages, in real life we often back-track more than one b. developing prototypes may be intended, but it is not mentioned as a means of achieving complete specifications or adequate designs.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

c. The model omits the most important of all software engineering properties – that the process does not necessarily terminate, but will probably back track from the bottom activity to the top in order to accommodate major changes, post hoc, to the original required system scope d. The use of terminology in the model contradicts the definition that are attached to it (e.g. of “verification” and “validation”). For instance:  It is difficult to see how we can answer the question “Are we building the right system?” at one step – what is being validated? (there is no specification prior to that step);  The same comment for “validating” the so called “software plans and requirements”;  There is very interesting shift in terminology at step 3 - the model now speaks (correctly) of verifying the design process;  The terminology becomes very arbitrary around “coding” and “integration” – in fact, given its author‟s own definitions, the product cannot be verified, only the process can;  This last point is borne out by the use of “revalidation” at the last step 3. A basic life cycle model of software development (circa 1980-85) This model has been adapted slightly to incorporate developing prototypes more clearly. It has been extensively used for software development and its management, and for orientation and education courses in the subject of software engineering. It has invariably carried with it the following caveats: a. It is somewhat ideal depiction of what is frequently a more iterative procedure, and one where parts of a software development may be done asynchronously with each other. b. It is a model for management control purposes, and for use as a paradigm in software engineering education, as a basis for a software development, the model should be viewed as a point of departure for guidelines and not standards. 4. An alternative model for the software life cycle (circa 1986-87) Criticisms and objections: a. quality assurance should not start as low down the life cycle (in any scheme) as the “structural software design” step, and it should continue into the post delivery stage. b. Feasibility evaluations are missing, as the stages where it may be necessary to do prototype developments for other purposes. c. No indication of the best points to do estimating are given d. No change control mechanisms seem required e. No iteration or back tracking of any sort seems possible

OTHER SDLC MODELS

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Software Requirements Requirements is a feature of the system or a description of something the system is capable of doing in order to fulfill the system‟s purpose. The purpose of requirements is to determine the nature of the customer‟s problem not on the solution of implementation. Requirements Engineering Process Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing needs, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating specifications, and managing the requirements as they are transformed into an operational system. The requirements engineering process can be described in the following steps: 1. 2. 3. 4. 5. 6. Requirements Elicitation Requirements Analysis system modeling Software Requirements Specification Requirements Validation Requirements Management

Requirements Elicitation It certainly seems simple enough – ask the customer, the users, and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis. The number of problems that help us understand why requirements elicitation is difficult  Problems of scope. The bo Analysis Methodology 1. Requirement determination/definition – this is primarily a fact-finding activity. This is the gathering of information about the current and replacement systems. The factfinding techniques are used to learn about the:  Current system (if one exist)  The organization which the new or replacement system will support  Uses requirements or expectations for the replacement system 2. Requirements structuring/specification –this activity creates a thorough and clear description of current business operations and new operations and new information processing services. The requirement structuring techniques produce diagrams and descriptions (models) that can be analyzed to how deficiencies, inefficiencies, missing elements, and illogical components of the current business operation and information systems. Along with user requirements, they are used to determine the strategy for the replacement system. The results of requirements determines task can be structured according to a 3 essential views of the current and replacement information systems:  Process – the sequence of data movement of data movement and handling operations within the system

San Sebastian College - Recoletos de Cavite Department of Computer Studies

 

Logic and timing – rules by which data are transformed and manipulated and an indication of that triggers data transformation Data – the inherent structure of data independent of how or when it is processed

3. Alternative generation and selection –this process results in a choice among alternative strategies for subsequent system design To find best strategy, analyst will first generate several competing alternative strategies. When alternatives have been identified and documented, the systems development team must present its best choice to the management for the purpose of gaining approval for further development. Once the best system design strategy has been identified and recommended, the analysis phase end. Two Sets of Requirements Requirement definition document –complete listing of everything the customer expect the proposed system to do. It represents an understanding between the customer and developer of what the customer needs or wants. Although it tells the user of what to expect, it is not in technical terms that can be used easily by the system designer. Requirements Specification document – it is the technical counterparts of the requirement definition document. It restates the requirement definition in technical terms appropriate for the development of a system design. There must be a direct correspondence between each requirement of the definition document and specification document. It is here that configuration management methods used throughout the life cycle begin. It is a set of procedures that track:  The requirement that define a system  The design modules that are generated from the requirements  The program code that implements the design  The test that verify the functionality of the system  The documents that describe the system Design Tools  ERD  Decision Tables  Decision Trees  Event Tables  State Transition Diagram  HIPO Chart  IPO Chart  Data Dictionary  H-Diagram  Data flow diagrams

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Software Design

5

As Process The creative process of system design is the transformation of the problem into a solution. As a product The resulting product is a description of the solution One thing about the system design we can use the requirements specification to define the problem. Then we declare something to be a solution to the problem if it satisfies all the requirements in the specification. In many cases, the number of possible solution limitless. The nature of the solution may change as the solution is described or even as it is implemented. System design is really a two-part process. First we produce a system specification that tells the customer exactly what the system will do. It sometimes called a conceptual design, we present the system builders with a technical design that allows them to build the actual hardware and software. 1. 2. 3. 4. 5. 6. 7. 8. Steps in Design Process Partition the analysis model into subsystems Identify concurrency that is dedicated by the problem Allocate subsystems to processors and tasks Choose a basis strategy for implementation data management Identify global resources and the control mechanisms required to access them Design an appropriate control mechanisms for the system Consider how boundary conditions should be handled Review and consider trade offs

Overall Goal of System Design 1. The system should be modular, that is, the system should be organize hierarchically into several smaller units. 2. Each module should control the functions of a reasonable number of subordinate modules at the next hierarchical level. 3. Modules should be relatively independent to each other in that no module‟s function should rely on the internal workings of other module; therefore, the amount of communication between modules can be kept to a minimum. 4. Each module should be a reasonable size 5. To the greatest extent possible, each module should perform one and only one function. 6. The code with each module should be as generic as possible so that each module can be used as often as possible within a system. Guidelines of Good Design 1. Factoring Factor of decompose, a system into smaller and smaller parts 2. Span of Control

San Sebastian College - Recoletos de Cavite Department of Computer Studies

In general, no superordinate module should control more than seven subordinate modules. 3. Coupling Minimize the extent to which modules are dependent on each other and, by so doing, minimize the amount on communication between modules. 4. Reasonable Size In general, modules should be limited to between 50 and 100 lines of codes. The more reasonable the size, the easier the module is to read. 5. Cohesion To the greatest extent possible, all instructions within a module should pertain to the same function. 6. Shared Use Especially at the lower levels of a system design, subordinate module should be called by multiple superordinate modules. Two Forms of Design Conceptual Design It concentrates on the function of the system. It tells the customer what the system will do. Characteristics of a Good Conceptual Design 1. It is written in the customer‟s design 2. No technical jargon 3. Describes the function of the system 4. Is dependent of implementation 5. Denotes from requirements documents Technical Design Explains the system to those software and hardware experts who will implement it. It describes the hardware configuration, the software needs, the communications interfaces, the input and output of the system, the network architecture, and anything else that translate the requirements into a solution to the customer‟s problem form the system will take. The following items that include in the technical design 1. The system architecture: a description of the major hardware components and other functions 2. The system software architecture: the hierarchy and function of the software components 3. The data: the data structures and the data flow

San Sebastian College - Recoletos de Cavite Department of Computer Studies

SYSTEM DESIGN (What is the solution?) INTRODUCTION The customer‟s need forces us to think of system design in two ways: as a process and as a product. The creative process of system design is the transformation of the problem into a solution. The resulting product is the description of the solution: this is called SYSTEM DESIGN TWO FORMS OF DESIGN 1. Conceptual Design It is a documentation of the system design written for the customer. It is also called SYSTEM SPECIFICATION. It may consist of screen displays and overall explanation of what the system will do. 2. Technical Design This is a documentation of the system design that describes the form that will take. It is written in a way that the technical people (hardware and software experts) may understand. It will include information such as: hardware configuration, software need, network architecture, communication interfaces, input-output of the system. DESIGN MODULE A module is a functional entity with a well-defined set of inputs and outputs. It is viewed as a component of the whole system. A design is then a determination of the modules and inter-modular interfaces that satisfy a specified set of requirements. Overall Goal of System Design 1. The system should be modular, that is, the system should be organize hierarchically into several smaller units. 2.Each module should control the functions of a reasonable number of subordinate modules at the next hierarchical level. 3. Modules should be relatively independent to each other in that no module‟s function should rely on the internal workings of other module; therefore, the amount of communication between modules can be kept to a minimum. 4. Each module should be a reasonable size 5. To the greatest extent possible, each module should perform one and only one function. 6. The code with each module should be as generic as possible so that each module can be used as often as possible within a system. APPROACHES TO SYSTEM DESIGN 1. Decomposition A design approach that begins with a high-level of the system and dividing it into modules. Then decompose a module into a even more detailed set of modules. 2. Composition A design that begins with defining the data objects and investigating the actions performed on the data type. Then building a system by constructing a se of tools to manipulate them. Thus, we compose modules to handle the data type. 3. Hybrid. A combination of decomposition and composition approaches.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Guidelines of Good Design 1. Factoring Factor of decompose, a system into smaller and smaller parts 2.Span of Control In general, no superordinate module should control more than seven subordinate modules. 3. Coupling Minimize the extent to which modules are dependent on each other and, by so doing, minimize the amount on communication between modules. 4. Reasonable Size In general, modules should be limited to between 50 and 100 lines of codes. The more reasonable the size, the easier the module is to read. 5. Cohesion To the greatest extent possible, all instructions within a module should pertain to the same function. 6. Shared Use Especially at the lower levels of a system design, subordinate module should be called by multiple superordinate modules. MODULARITY A characteristics of good system design. High level modules gives us the opportunity to view the problem as a whole and hide details that may distract us. COUPLING Is the measure of how much modules depend on each other. Modules are Highly coupled when there is a great dependency between modules. Loosely coupled modules have some dependencies. While Uncoupled modules have no interdependencies. Coupling Depends On: 1. The reference made from one module to another. 2. The amount of data passed from one module to another. 3. The amount of control one module has over the other. 4. The degree of complexity in the interface between one module and another. COHESION It refers to the internal glue with which a module is constructed. The more cohesive the module is, the more related are the internal parts of the module to each other and to the functionality of the module. Degrees of Cohesion 1. COINCIDENTAL. When parts of a module are completely unrelated to each other. 2. LOGICAL. When several logically related functions are placed in the same module. 3. TEMPORAL. Functions of a module are related only because of the timing in a module (when there is branching out to another module). 4. PROCEDURAL. When functions are grouped together in a module so that it can be performed in a certain order.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

5. COMMUNICATIONAL. When functions operate on or produce the same data set. 6. SEQUENTIAL. When the output from one part of a module is input to the next part. 7. FUNCTIONAL. When each part of the module is vital to the overall function of the module. FAN-IN AND FAN-OUT FAN-IN is the number of modules controlling a particular module. While a FAN-OUT is the number of modules controlled by a particular module. It is ideal to design system whose modules have a high fan-in and low fan-out. CHARACTERISTICS OF A GOOD SYSTEM DESIGN 1. Low coupling of modules 2. High cohesive modules 3. Minimal number of modules with high fan-out 4. Scope of effect of a module is limited to its scope of control SYSTEM DESIGN TECHNIQUES AND TOOLS 1. Data Flow Diagrams 2. Data Abstraction 3. Structure Charts 4. Prototyping 5. Application Generators DESIGN REVIEWS

Preliminary Design Review

A type of system design review, when the conceptual design is presented to the customers and user by the design team for approval. The content of the conceptual design will be discussed and validated.

Critical Design Review

A review where the technical design is presented to a group of technical people by designers. The purpose of which is to scrutinize the content of the technical design documentation. The design review process focuses on the detection of errors, rather than on their correction. Those who participate are investigating the integrity of the system design, and not of the designers. DESIGN DOCUMENTATION CONSISTS OF: 1. Outline of the critical issues and trade-offs that were considered in generating the design. 2. Description of the components of the system. 3. Overall organization and structure of the system.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

PROGRAM DESIGN (What are the mechanisms that best implement the solution?) Program design is the definition of modules and inter-modular interfaces so that each module of the design corresponds to a new set of modules containing program specification. The program specification for a module are instructions to a programmer that describes the input, output, and processing to be performed by the module. DESIGN TOOLS 1. Flow Diagrams. A graphical representation of the definition, analysis and solution of a problem that shows the data flow though the input/output devices to meet the program requirements. Types of Flowcharts 1. System Flowchart. This graph portrays the interaction among data hardware and personnel. 2. Program Flowchart. Describes graphically in detail the logical operations and steps within a program and the sequence in which these steps are to be executed for the transformation of data produce the needed output. 2. Pseudo Code. Describes the program in English-like shorthand. 1. Structured English. By constraining the way in which English can be used, the resulting program descriptions have a careful, precise structure. For these reasons, this kind of pseudo code is known as Structured English. 2. Nassi-Schneiderman Chart or Chapin Chart. A chart that represents each operation with a block. In turn each block can contain one or more blocks. Thus, nesting is automatically built into the design. Using the Nassi-Schneiderman Chart makes it impossible to transfer control out of a subprocess prematurely. It allows us to see the scope of a process or a variable. 3. PDL (Program Design Language). A marriage of English and IF and DO programming language constructs. 4. Automated Design Tools. These automated tools are referred to as Computer Aided Software Engineering or CASE. It integrates graphics and text by allowing data flow diagrams and the data dictionary to be created simultaneously. Automation may enable us to perceive things more clearly or quickly, but it cannot do the entire job for us. Although tools help us generate it, the resulting design is only one of the perhaps many solutions to the given problem; the heart of any solution must come from the combined expertise of the people addressing the problem. DESIGN QUALITY Structured Design 1. It is composed of modules that are highly cohesive. 2.There is a low degree of coupling among modules. 3.Each module has a single entry point and a single exit. Error Prevention and Correction A structured design help us to avoid errors, since it encourages us to consider all cases, reduces complexity where it can, and makes tracking and eventual elimination of error easier.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Error Detection

Passive Error Detection refers to the detection of an error during a system‟s execution.
However, rather than waiting for an error to appear, the system can be checked periodically for symptoms of an error; this form of detection is known as Active Error Detection.

Defensive Designing You must also design defensively by checking for errors that may be committed or overlooked by others. In order to ensure that data are in the proper range and have the correct attributes. Error Correction Error correction is the system‟s compensation for the presence of an error. Error correction does not usually correct the cause of the error; rather it fixes only the damage done by the error. While error tolerance is the isolation damage caused by an error. Unconditional Branching Unconditional branching are not necessary in a program design since such branches can be rewritten in other ways. The more structured the program is the more desirable.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

PROGRAM IMPLEMENTATION (How is the solution constructed?) PROGRAMMING STANDARDS AND PROCEDURES Need for Standards and Procedures Standards and procedures are needed as aids not only to programmers but also to others who may have test or modify the code produced. Others must be able to understand easily what you have written and why. Standard and procedure can help you to organize your thoughts and avoid mistakes. Some of the procedures involve methods of documenting your code so that it is clear and easy to follow. Such documentation allows you to leave and return to your work without losing track of what you have been doing. Standardized documentation also helps to locate errors in making changes because it clarifies which section of your program perform which function. Once your code is complete, others are likely to use it in a variety of ways. Even after the system is up and running, changes may be needed, either because of an error or because the customer wants to change the way the system performs its functions. You may not be part of the maintenance or test team, so it is essential that you organize, format, and document your code to make it easy for others to understand what it does and how it works. Matching Design with Implementation The most critical standard is the need for a direct correspondence between the program design modules and the program code modules. The entire system design and program process is a little value if the modularity of the design is not carried forward into the code. A direct correspondence between design and code is essential. Testing, maintenance and configurations management would be almost impossible without the links established through software engineering principles. PROGRAMMING GUIDELINES Programming involves a great deal of creativity. Remember that the program design is a guide to the function or purpose of each module. No matter what language is chosen, each program module involves three major components: logic control structures, algorithm, and data structures. 1.Control Constructs Using Fundamental Constructs. Ideally, the program design is written using only these constructs. You should maintain the use of these structures in the program code that you write. Use of control mechanism makes the program easy to read and follow, helps to minimize uncontrolled branching and even helps to organize thought while writing the program. Top-down flow. Readers of a program should not jump wildly through the code, marking sections to which to return and wondering whether they have followed the right path. Thus it is best to arrange your code, as much as it is practical, so that is can be read from top to bottom.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

Use of Submodules. Modularization introduces many positive characteristics in a software system. The advantages of modularity continue to help us as we write code now and support it later. By building a program from modular building blocks, we can hide some implementation details of various levels so that the entire system is easier to understand, test and maintain. Similarly, a program module may be enhanced by the use of functions, macros, procedures or subroutines that perform some of the elemental functions with the details hidden from view. 2.Algorithms. Program design often specifies a class of algorithms of even a particular algorithm to be used in coding a module. You must consider the algorithm in light of the implementation language and hardware and write your code accordingly. 3. Data Structures. In writing the program you should think about how to format and store the data involved so that data management and manipulation are straightforward. a. keep the program simple b. use the structure of data to determine the structure of the program c. localize input and output in separate modules. By coding an input module in a general way, you can use the module for any input needed by the system. Other system wide functions to be performed on the input (such as reformatting or type checking) can be coded in the general module. GENERAL GUIDELINES 1. Use Psuedo code. Psuedo code can be used to adapt the design to your chosen language. By adapting constructs and data representations without becoming involved immediately in the specifics of each command, you can experiment and decide which implementation is not desirable. In this way, codes can be rearranged and reconstructed with a minimum of rewriting. 2. Revising and Rewriting rather than Patching. Sometimes, a programmer likes to adapt the problem at hand to a module from another system of project. If the program was written in a completely general way, this approach can be useful. However, if the existing module is so specialized that extensive changes are required it is best to start from scratch. DOCUMENTATION Program Documentation is a set of written description that accompanies a program in order to explain to a reader what is the program for and how it works. There are two kinds of documentation namely: internal documentation and external documentation. Internal documentation can be described as written materials contained within the program, while all other documentation is called external documentation. Internal Documentation a. Header Comment Block. You must include the following information in the header commend block. b. What your program is? c. Who wrote the program? d. Where the program fits in the general system design? e. When the program was written and revised? f. Why the program exists?

San Sebastian College - Recoletos de Cavite Department of Computer Studies

g. How your program uses its data structures, algorithms and control? h. Other Program Comments. Additional comments enlighten readers as they move through your program. If the organization of the code reflects a well-structured design. If the statements are formatted clearly, and if the labels, variables and data names are descriptive and easy to distinguish, then the necessary number of additional comments is small. i. Meaningful Variable Names and Statement Labels. Choose names for your variables and statements that reflect use or meaning. j. Formatting to enhance understanding. The format of your comments can help a reader understand what the code is doing and how. Indentation and spacing of statements can reflect basic control structures. External Documentation External documentation is intended to be read by those who may never look at the actual code. In external documentation you have a chance to explain things more broadly than might be reasonable within your program‟s comments. a. Describing the Problem. This section sets the stage for describing what options were considered for solutions and why a particular solution was chosen. b. Describing the Algorithm. Each algorithm used by the program is discussed in detail in a narrative form. All formulae are included, and boundary or special conditions are discussed. c. Describing the Data. In the external documentation, users or programmers can see the data flow through the system of a program module level.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

PROGRAM TESTING CAUSES OF DEFECTIVE SOFTWARE 1. Many software deals with large numbers of states and with complex formulae, activities, and algorithms. 2. We use the tools at our disposal to implement a customer‟s conception of a system when the customer is sometimes uncertain of what is needed. 3. The size of the project and the number of people involved can add complexity. SOFTWARE ERRORS Types of Errors 1. Algorithmic Errors. Is one in which the system or module does not produce the proper output to incorrect sequence of instructions or process. Syntax errors. It occurs when the proper language constructs are not followed. 2. Computation and Precision Errors. It occurs when the implementation of a formula is wrong or does not compute the result to the required degree of accuracy. 3. Documentation Errors. When the documentation describes the program‟s function but does not match what the program is doing. 4. Stress or Overload Errors. It occurs when the data structures are filled past their specified capacity. 5. Capacity or Boundary Errors. When the performance of a system becomes unacceptable as the activity on the system reaches its specified limit. 6. Timing or Coordination Errors. Occurs when the code coordinating these events is inadequate. 7. Throughput or Performance Errors. It occurs when the system does not perform at the speed prescribed by the requirement. 8. Recovery Errors. It can occur when an error is encountered and the system does not behave as the designer‟s desire or as the customer requires. 9. Hardware and System Software Errors. Can arise when the documentation for the supplied hardware and software does not match their actual operating conditions and procedures. 10. Standards and Procedure Errors. By not following the prescribed standards, one programmer may make it difficult for another to understand the programming logic or to find the data descriptions needed to solve the problem. PURPOSE OF TESTING The purpose of program testing is to discover errors. We test the program in order to demonstrate the existence of errors. Debugging or error correction is the process of determining what causes the error and of making changes to the system so that the error will no longer exists. STAGES OF TESTING 1. Module or Unit Testing. Testing of each program module as a single program which is isolated from the other programs in the system. 2. Integration Testing. Is the process of verifying that the components of a system work together as described in the program design and system design specifications. 3. Function testing. Evaluates the system to determine if the functions described by the requirements specification are actually performed by the integrated system.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

4. Performance Testing. The system is compared against the hardware and software requirements. If the test is performed in the customer‟s actual working environment, a successful test yields a validated system. 5. Acceptance Testing. In which the system is checked against the customer‟s requirements description. 6. Installation Testing. The accepted system is further tested after installation to check if it will still functions as it should.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

UNIT TESTING AND INTEGRATION TESTING (Are enhancement needed?) PROGRAM REVIEWS It is similar to program design review. A team composed of a programmer, and three or four other technical experts studies the program. TYPES OF PROGRAM REVIEWS Program Walkthrough. The programmer presents his code and the accompanying documentation to the review team, and the team comments on the correctness of the program. Program Inspection. Similar to a program walkthrough but in a more formal presentation. The review team checks the program against a prepared list of concerns. PROVING PROGRAMS CORRECT The next step in program testing is o subject the program to scrutiny in amore structured way. We want to establish somehow that the program is correct. A program is correct if it implements the functions specified in the program design and interfaces properly with other modules. TYPES OF PROVING PROGRAMS CORRECT 1. Formal Logic Proof Technique. This method displays the logic of a program as a series of assertions, that is, a series of statements each of which either true or false. 2. Symbolic Execution. This technique involves simulated execution of the test program using symbols instead of data variables. 3. Automated Theorem proving. Using expert system software to prove the correctness of your program modules. TESTING PROGRAM 1. Statement Testing. Every statement is executed at least once. 2. Branch Testing. For every decision point in the program, each branch is chosen at least once. 3. Path Testing. Every distinct path through the program is executed at least once. INTEGRATION TESTING Integration testing is the systematic technique for constructing the program structures while at the same time conducting tests to uncover errors associated with interface. BOTTOM-UP APPROACH Bottom-up Testing. When this method is used, each module at the lowest level of the system hierarchy is tested individually. Then the next modules to be tested are those who call the previously tested modules. TOP-DOWN APPROACH Top-down is the reversed of bottom-up. The top level, usually the one controlling all modules, is tested by itself. Then all modules called by the tested module(s) are combined and tested as a larger unit.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

MODIFIED TOP-DOWN APPROACH It is similar to top-down approach, but here all modules are first tested individually before the merger takes place. SANDWICH TESTING A combination of top-down and bottom-up approach. The lower level modules are tested using the bottom-up approach while the upper levels are tested using top-down approach. BIG BANG TESTING When all modules are tested in isolation from others, then mixes them all together as the final system. The testing of modules and their integration can include static analysis and dynamic analysis. 1. Static Analysis. Where programs are evaluated before they are executed. It is performed when the program is not actually executing. 1. Code Analyzer – evaluates the test modules from proper syntax. 2. Structure checkers –checks the structural flaws of the hierarchy of modules. 3. Data analyzer – reviews the data structures, data declarations, and module interfaces and then notes improper linkage between modules, conflicting data definitions and illegal data usage. 4. Sequence checkers – input and output modules may be submitted to a sequence checker to determine if the events are coded in proper sequence. 2. Dynamic Analysis. Performance of the program is monitored during its actual execution. THE TEST LIFE CYCLE 1. Establishing the test objectives 2. Designing the test cases 3. Writing the test cases 4. Executing the test cases 5. Evaluating the test results TEST PLAN. It takes into account the objectives of the testing process and incorporates any scheduling mandated by the type of testing strategy used. PURPOSE OF TEST PLAN. The test plan describes the way in which we will demonstrate to our customer that the software works correctly. The test plan is a guide to the entire testing activity. ESTIMATING SOFTWARE QUALITY 1. Software Availability – is the probability that a program is performing successfully according to specifications at a given point in time. 2. Software Maintainability – is the probability that a software error can be fixed right away. 3. Software Reliability – is the probability that the program is successful for a given period of time.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

SYSTEM TESTING (Can customer use the solution?) SYSTEM TESTING verifies that a system solves the problem as defined by the requirements definition. To verify that the software developed satisfies both our customers and ourselves. STEPS IN SYSTEM TESTING Function Test Sometimes referred to a “thread testing”, checks that the integrated system performs its functional requirements as specified in the requirements document. Performance Test It compares the integrated modules with the nonfunctional system requirements. These requirements include security, accuracy, speed, and reliability; they constrain the way in which the system functions are performed. A validated system is the result of a performance test in the customer‟s actual working environment; if the testing is done in a simulated environment; the performance test results in a verified system. Acceptance Test Acceptance Test checks the system‟s characteristics to assure that they are in compliance with the defined requirements, if the system is not yet installed in the user‟s environment. Installation Test Is done simply to allow users to exercise the system functions and document additional errors. Regression Testing – is a test applied to a new version of the system to verify that it will performs the same functions in the same manner as an older version. The Issue of Control – Any change proposed to any part of the system is approved first by the configuration management team. The change is entered in all appropriate documentation and the test team notifies all who may be affected. PERFORMANCE TESTING Test Case Coverage 1. Stress test – evaluate the system when stressed to its limits over a short period of time. 2. Volume test – address the handling of large amounts of data in the system. 3. Configuration test – analyze the various software and hardware configurations specified in the requirements 4. Compatibility test – are needed when a system interfaces with other systems. 5. Regression test – required when a system will replace an existing system 6. Security test – insure that the security requirements are met 7. Timing test – evaluate the requirements dealing with time to respond to a user and time to perform a function. 8. Environment test – look at the system‟s ability to perform at the installation site. 9. Quality test – evaluate the reliability, maintainability, and availability of the system.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

10. Recovery test – address response to the presence of errors or to the loss of data, devices or power. 11. Maintenance test – address the need from diagnostic tools and procedures to help in finding the source of errors. 12. Documentation test – insure that we have written the required documents. 13. Human function test – investigate requirements dealing with the user interface to the system. ACCEPTANCE TESTING 1. Benchmark test, the customer prepares a set of test cases that represent typical conditions under which the system will operate when actually installed. The customer submits the test cases and evaluates the system‟s performance for each. 2. Pilot test, installs the system on an experimental basis. Users exercise the system as if it had been permanently installed. 3. Parallel test, when the new system operates in parallel with the previous version.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

SYSTEM DELIVERY (Is the problem solved?) There are two types of people who use a system: users and operators. The users exercises the main system function to solve the problem described by the requirements definition document. The operations perform the supplementary function of the system. They are sometimes called computer operators if the operator‟s functions include powering up, configuring the devices or performing other tasks that relate to the equipment rather than to the system operation. TYPES OF TRAINING 1. User Training Training for users is based primarily on major system functions and the user‟s need for access to them. They need not be aware of the system‟s internal documentation. 2. Operator Training Training focus of operator training is familiarity with the system‟s support functions. Training addressed how the system works, rather than what the system does. Operators are trained on two levels: how to bring up and run the new system and how to support users. 3. Special Training Needs Users and operators are usually trained in a concentrated and complete course in system user. The complete training course is offered during system delivery to those who will use the system. But sometimes, they may have a need for a review on how to perform certain functions or some user prefers to study certain tasks involved in their work. Specialized training courses can be design for those who have special needs. TRAINING AIDS 1. Documents. The formal documentation that accompanies every system and supports training. The documents all the information needed to be use the system properly and efficiently. 2. Icons and Online Help. A system can be designed so that its interface with the user makes system functions clear and easy to learn. The user can scan for additional information about a function‟s purpose or use without having to take the time to search through paper documents. 3. Demonstrations and Classes. They are usually organized as a series of presentation, so that each class in the series learns one function or aspect of the system. 4. Expert Users. They are users and operators who have trained in advance and act as model for the class. They participate in demonstrations to show to the users and operations in training that it is easy to learn and use the system. DOCUMENTATION 1. User‟s Manuals. Is a reference guide or tutorial for a system users and operators. 2. Operator Manuals. The operator‟s guide explains hardware and software configurations, methods for granting and denying access to user, procedures for adding or removing peripherals from the system, and techniques for duplicating or backing up files and documents. 3. General System Guide. Similar to the system design document: It describes a solution to a problem in terms the customer can understand. 4. Tutorial and Automated System Overview. Some users prefer to be guided through actual system functions, rather than to read a written descriptions of how the system

San Sebastian College - Recoletos de Cavite Department of Computer Studies

functions. An interactive program that teaches the user and operators on how use the system may be developed. Error Message Reference Guide. Is a complete list of error messages and explanation on why they occur and possible solutions.

San Sebastian College - Recoletos de Cavite Department of Computer Studies

SYSTEM MAINTENANCE (Is the implementation working as designed?) TYPES OF SYSTEM S – SYSTEM. These system are well designed and implemented systems. Such system is static and does not accommodate a change in the problem that generated it. P – SYSTEM. These are systems based on a practical abstraction rather than on a completely defined specifications. Changes may occur periodically. E - SYSTEM. The third class of systems incorporates the changing nature of the real world itself. It changes as the world changes. The solution is based on the model of the abstract processed involved. MAINTENANCE ACTIVITIES 1. Analyzing requirements 2. Evaluating system and program design 3. Writing or rewriting code 4. Testing changes 5. Updating documentation CORRECTIVE MAINTENANCE To control the day to day functions of the system, the maintenance team responds to problems resulting from errors in the system. Addressing these problems are known as corrective maintenance. ADAPTIVE MAINTENANCE Sometimes a change in one part of the system requires changes to other parts of the system. The implementation of these secondary changes is known as adaptive maintenance. PERFECTIVE MAINTENANCE Changes in the environment can result in changes in the system, this is known as perfective maintenance. PREVENTIVE MAINTENANCE It is performed on the system in an effort to prevent an error or malfunction from occurring. THE PROBLEMS OF MAINTENANCE LIMITED UNDERSTANDING. There is a limit to the rate at which a person can study documentation and extract material relevant to the problem being solved. MANAGEMENT PRIORITIES. Maintenance and enhancement activities were viewed by management as being more important than the development of new applications. TECHNICAL PROBLEMS. If the logic of the design is not obvious. It whether the design can handle the changes required. may not be clear

San Sebastian College - Recoletos de Cavite Department of Computer Studies

TESTING DIFFICULTIES. Testing can be a problem when finding time is difficult. In addition to time availability problems, there may be not be good or appropriate test data available for testing the changes made. PROBLEMS OF MORALE. There is a low morale de to the second-class status accorded the maintenance team. Programmers may think that it takes more skill to design and develop the system that to keep it running. THE COST OF MAINTENANCE. The problem of maintaining the system contributes to the high cost of maintenance. TECHNIQUES IN IMPROVING MAINTENANCE CONFIGURATION MANAGEMENT. Is the management and control of all kinds of changes made to a system so that the state of every component is always known. CONFIGURATION CONTROL BOARD OR CHANGE CONTROL BOARD. Consists of customer representatives and members of the configuration management learn. MAINTENANCE GRAPHS AND METRICS. Impact analysis is the evaluation of the many risks associated with the change, including estimates of the effect on resources, effort and schedule. AUTOMATED MAINTENANCE TOOLS. Tracking the status of all modules is a formidable job. Fortunately there are several automated tools that can helping performing both the configuration management and maintenance activities.