VIDYAVAHINI FIRST GRADE COLLEGE

Transcription

1 VIDYAVAHINI FIRST GRADE COLLEGE SOFTWARE ENGINEERING 5 th Sem BCA Vidyavahini First Grade College Near Puttanjaneya Temple, Kuvempunagar, Tumkur [email protected] Website: Contact No:

2 Chapter 1 Introduction to Software Engineering. Introduction:The notion of software engineering was first proposed in 1968 at a conference held to discuss what was called software crisis. Software Engineering is the science and art of building significant software systems, depends on Time Budget Acceptable performance Correct operation. Software : It is the collection of computer programs, rules and associated documents and data. There are two types of software s are there 1) System software: software designed to operate the computer hardware and to provide a platform for running application system software. Eg: O.S, translator s/w(compiler, assembler, interpreter..) 2) Application software: it is set a programs that help to solve particular problem of the user. Eg: Airline Reservation, Railway Reservation, satellite tracking. Software Engineering:[Definition given by IEEE] The application of a systematic, disciplined, quantifiable approach to the development, operation, maintenance of a software by applying engineering techniques. Goals of software Engineering 1) Improve the quality of s/w products. 2) To increase productivity. 3) To get the ability to develop and maintain a software. 4) Job satisfaction to s/w engineers. Characteristic of software 1. Maintainability: It should be possible for the software to meet the changing requirements. Department of BCA Page 2

3 2. Dependability: As a range of characteristic it must include reliability, security and safety. security and safety dependable s/w does not cause any damage in the event of system failure 3. Efficiency: It should not make any wasteful use of system resource such as memory, processing time. 4. Usability: It must be easy to use for customers or user. Easy description how to install and use the system. Software products. These are software systems that are delivered to a customer with documentation which describe how to install and use the system. There are two types of software products available they are 1. Generic Products: These are stand alone systems which are produced to sell in open market to any customer. The requirements and specification are controlled by the developer. Generic s/w is also called commercial-off-the self(cots) s/w. Ex: word processor, Drawing packages. 2. Customized (Bespoke)products: This type of s/w is developed to meet the requirement of a specific user or a group of user. The requirements and specification are controlled by the customer. Ex: Hospital management, Railway reservations Software process: A set of activities and associated result which produce a s/w product. Fundamental activities in all software processes are: (1)Software Specification: Specification process involves defining s/w to be produced and there constraints. Designer must collect all the required specification before starting the development activities. (2)Software Development: It involves team of profession with innovation idea that helps to develop and design the s/w specified by the user. Department of BCA Page 3

4 (3)Software validation: S/w is validated after matching requirement of the customer with the s/w developed. It is the process of checking the s/w (4)Software evolution: S/w is modified to adopt changing customer and market requirement. Characteristics of s/w process 1) Understandability 2) Visibility 3) Supportability 4) Acceptability 5) Reliability 6) Maintainability Software Engineering Challenges: 1. Heterogeneneity challenge: Many of the s/w product will always have heterogeneity, meaning varied requirements such as different types of computers and specifications. The challenge is to develop s/w which can automatically to adjust(flexible) with heterogeneous systems. 2. Delivery challenge: s/w project development is time consuming as it has to be manufactured and must maintain quality. Delivering the s/w to the customer on-time is a real challenge. Department of BCA Page 4

5 3. Trust challenge: Maintaining the trust is very important. Many times s/w is accessed through web. The developer must develop the s/w such that they trust the product. The s/w engineers must develop trustworthy s/w. Components of Software Engineering. 1. Software Development Life Cycle. It identifies various stages and activities associated with development of software. 2. Software quality assurance: It is the process of ensuring users satisfaction through developing a quality product. 3. Software Project Management: It is the application of principles project management to process of software development. 4. Software Management: These are the methods and procedures to be followed for effective software maintenance. 5. CASE: (Computer Aided Software engineering) They are set of automated tools that support the process of software development. Software Development Life cycle[sdlc]. In SDLC each phase of the software development take the input of previous phase result. Department of BCA Page 5

6 1. Requirement Analysis & Specification: Here, we collect functional & non- functional requirements of the proposed system from the customer. Functional requirements describe the system software s processing & input /output needs. Non functional describe about machine in terms of its size & capacity. 2. System & Software Design: In this stage, the designers produce a system architecture i.e. description of hardware & software systems. The software designers design Units/Models/Subroutines. The output of this phase is description of program units written in a formal language which is given to programmer for translation. 3. Coding and Unit testing: The designed module is given to the purpose of coding. In this stage, each unit is coded using a programming language and tested for its proper working. 4. Implementation & Integration of S/W Units: The design is translated to program units. These units are tested individually to ensure that it matches design & its requirement specification. The common errors are typing mistakes, statement omission. Then the units are integrated in a pre-defined way such as topdown or bottom-up to form a system. 5. Software Operation & Maintenance: This phase describes modification to the system developed while operation. Corrective maintenance defines modification as a result of error discover. It includes improvements update to the new version and making the system error free. Types of SDLC Models 1) Water fall model 2) Prototype model 3) Rapid application model 4) Evolutionary model 5) Incremental model 6) Iterative Model 7) Component based software engineering model 8) Spiral model. Water Fall Model It is a software life cycle described by W.W.Royce in 1970 in which the development is supposed to proceed linearly through the phases requirement analysis, design, implementation, testing, integration and maintenance. Department of BCA Page 6

7 The water model is also referred as linear sequential model or classical life cycle model. Requirement definition. All possible requirement of a system to be developed or capture in this phase and also requirement specification document is created which serves as a guideline for the next phases of the model. System and software design: It is highly important to understand the requirements of the user how should end products looks like. System design helps in specifying hardware and system requirements and also defining system architecture. Implementation and unit testing: The system is first developed and the work is divided in to modules or units. Each unit is developed and tested for its functionality this referred as unit testing, it mainly verify whether all the modules are working properly or not. Integration and system testing. The units are integrated in to a complete system during integration phase and tested to check all the modules are co ordinate with each other. Operation and maintenance: This phase is a never ending phase generally problems arises after its practical use only so the maintenance of the system come in to picture directly when it is to used. Hence this phase is referred as Maintenance. Advantages 1) It is very easy to understand 2) Widely used in many development areas Department of BCA Page 7

8 3) Identifies the milestones of the software development. 4) There is a clear compartment regarding work and control of the model. 5) It is the model as defined before design and design before code. 6) This model is the easiest to implement in the eyes of the managers. Disadvantages. 1) Difficult and expensive to make changes to document in the middle of the process. 2) Significant administration is required. 3) Software is delivered late in project. 4) Unrealistic to expect to accurate requirements in the starting phase. Where it is applicable? This model is applicable only when all the requirements are well defined and understood. Iterative Enhancement Model The iterative enhancement model is the elements of the linear model with the iterative philosophy of prototype the sun is broken into several models which are implementing develops and delivered to the customers. The basic idea is that the software is developed in an incremental way each increment add some functionalities capabilities to the system until the full system is implemented. At the first step a simple initial model is developed and it is implemented at this contains some of the key aspects of the problem. A project control list is created which contains the analysis of the product in the markets the process is repeated until the projects control list is empty. At the time of implementation a full system is available and the phases used in this model are called as design phase implementation phase and analysis phase. Advantages: It combines the benefits of waterfall model. It allows for early adjustments to the products during development. The correct actions can be taken at the beginning of every phase after the interval. It can result better testing because testing done to the entire system. Department of BCA Page 8

9 Disadvantages: The people working on this project can get struck in a loop. That is finding problem always and go back again implement and design. The user community needs to actively participate through the project Informal request for the improvement after each phase may lead to confusion. Spiral model The spiral modal was proposed by boehm it combines the best features of water fall and prototype model, each loop represents a phase of the s/w development process. The inter most loop is concerned with the system analysis and system feasibility and the next loop with requirement destination. the next loop with system design and so on. Each group is the spiral model is split into 4 sectors 1.objectives setting: Specified objective for that particular phase are defined and identified and detailed plan is drown. 2.Risk assessment and risk deduction: A detailed analysis is carried out to identify them risk in the particular loop and a prototype system developed to solve the risk. 3.Development and validation: A development model for the system is selected and the system as been developed. 4.Planing: The project is reviewed and a decision made whether it is continued with further group or stop. Department of BCA Page 9

10 Advantages. The high amount of risk analysis. Good for large and mission critical projects. Project monitoring is very easy because of transparency in the model. It is suitable for high risk projects where business needs are high. A highly customized product can be developed using this model. Disadvantages. Cost involve is usually high. Doesn t work for smaller project. Required for evaluating & reviewing the project time to time Risk analysis required highly specific experts. Scheduling requirement are very much tough. Risk Management Risk is the potential feature harm that may arise from present action. Risk management is the main job of project managers. It involves anticipation risks that might affect the project schedule or the quality of the software being developed and also minimize the risk before it effect the project. There are several types of risk can occur during a software development. Generic risk - Product Specific risk Project risk Product risk Business risk Professional & Ethical Responsibilities. Software Engineers must behave honest & ethically responsible. Some of the responsibilities are, Confidentiality : Engineers should have respect over there employees, clients and also confidential argument as been signed. Competence: Engineers should not miss represent there level of competency. They should not knowingly accept work which is out of their acceptance. Computer Misuse: Software engineers should not use their technical skills to miss use others computers. Intellectual property Risk : Engineers must be aware of local laws governing the use of local laws governing the use of intellectual properties such as patents, Copyrights,etc. Department of BCA Page 10

11 Chapter-2 SYSTEM ENGINEERING A System is a collection of inter related components that work together to achieve some objective System Engineering It is the activity of specifying, deciding, implementing, validating, installing and maintaining system as a whole. Emergent properties Properties of the system as a whole rather than properties that can be derived from the properties of components of a system. a) The overall weight: This can be computed from individual component property. b) The reliability of the system : This depends on the system components and the relationship between the components. c) The usability of the system: This depends on the system operation and the way in which it is used in the environment. System and their Environment Systems are not independent entities, they exist in an environment and this environment affects the functioning and performance of the system. When a system is part of another system it is called as a sub system. The sub system may decompose hirarically until it is not useful to become the component of other system. Main reason to understand the environment of system 1) The functioning of a system depends on the environment. 2) The functionality of a system can be affected by changes in the system environment in which it can be very difficult to predict. System procurement Acquiring a system for an organization to meet predefined requirement specification. Department of BCA Page 11

12 Customer Principle Contractor Sub Contractor Sub Contractor Sub Contractor The contractor or sub contractor minimizes the task of system procurement. The sub contractor built & design part of the system. The different parts designed by sub contractors are integrated by the principle contractor and then it is delivered to the system customer. Depending on the contract the principle contractor going to select the number of sub contractors. System Engineering Process System Engineering process is the inter disciplinary process that ensures that the customer needs are satisfied throughout system life cycle. The phases of System Engineering process are, Department of BCA Page 12

13 1) Requirement definition 2) System design process 3) Sub System development 4) System integration 5) System installation 6) System evaluation 7) System decommissioning 8) System operation. System requirement (Requirement definition) Its specify what the system should do & essential & desirable system properties. It also involves consultations with system customers & end users. This step concentrates on mainly three properties they are : - a) Abstract functionality requirement: The basic functions that system must provide are defined at this level. b) System properties: These are Non functional emergent system properties such as availability, performance & security. c) Characteristic that might not exhibit: It is to specify what the system should do and not do. System Design: - System design involves five phases in system engineering. a) Requirement Partition Analyze the requirement and organize them into related groups. Department of BCA Page 13

14 b) Identify sub system It can individually collectively meet the requirements, so the activity & requirement partition carried out together. c) Assign requirements to Sub system Assign the requirement to each identified sub system. d) Specify sub system functionality The specific functions provided by each sub system are specified. Relationship between the sub systems also identified in this stage. e) Define Sub System interfaces Define the interfaces that are provided by each sub system. Once these interfaces have been agreed the development of the sub system becomes possible. Sub System Development The sub system development activities involves developing each of the sub system identified during system design. This may enter another system engineering process for the sub system. System Integration System integration involves taking independently developed sub system and putting them together to make up a complete system. Integration can be done in two ways a) Big Bang Method : All the sub systems are putted together at one time. b) Incremental Method: Sub system are integrated one by one. It is a best approach because of two reasons. 1) It usually impossible to schedule the development of all sub system so that they can be finished at a time. 2) It reduces cost of error location. System installation It is the activity of installing the system in the environment where it is intended to operand. Different problems that can occur during system installation are, 1) Environment assumption may be incorrect. 2) Operator training has required. 3) There may be physical installation problems. Department of BCA Page 14

15 4) May be human resist to introducing the new system. System Evolution Large & complex systems having very long life time it is difficult to make evolution during their life time. During their life time some system evolution takes place. Evolution is costly for a reason : 1) Purpose changes have to be analyzed from a technical perspective. 2) Sub system are never independent, changes made to one sub system may effect the performance of another sub system. 3) The system age & their structure become corrupted by change. System Decommissioning It means taking the system out of service after the end of its use full life time for example, hardware components of a system can be reused in another system. Human Factors that affects system environment Process Changes : If the process is changed then training is certainly required by the workers by the new system. Job Changes : As the new faster systems are introduced the workers may have to change the way of work. Organization changes : An organization is dependent on a complex system then the operator of the system have a great deal of political power. Department of BCA Page 15

16 System Reliability Reliability is a complex concept. It is consider at the level of system rather than individual components. Computer based system has three dimension those are consider for the system reliability. Hardware Reliability: What is the probability of a hardware component. Software Reliability: How likely is that a software component will produced an incorrect output. Operator Reliability: How likely is it the operator make an error. System Architecture The system requirement and design activity may be modeled as a set of components and relationship between these components. The following diagram represents the architecture of ship control system. Department of BCA Page 16

17 There are several major sub system which are them self sub divided in to functional components. Functional components provide a single function. Functional components of ship control are, Sensor components : It collects information from system environment about nautical miles covered, tides and waves of the environment. Actuator Components: performance of ship. It causes some change in system environment to suit the Computation Components: It performs the computation by accepting the input, process the input and gives the required output. Communication Component: Establishes communications contact between one ship to another ship. Co ordination component: members of the ship. Establishes communications between employees or crew Interface component: It transfers the information from one component to other the components of the ship control system. Department of BCA Page 17

18 CHAPTER-3 SOFTWARE REQUIREMENT SPECIFICATION A system is a collection of elements that are organized to perform a task using some method. They involve elements such as hardware, software, people, procedures & processes. A system analyst defines these elements of system initially. System Analysis Objectives: Before preparing SRS (Software requirement specification) system should be analyzed for following tasks; a) To identify customer needs. b) Feasibility of system c) To perform technical & economic analysis d) Establish cost. The main aim is to identify customer needs, which lead to success of software system. Feasibility Study: This is a study about time & money is enough or not. This involves cost-benefit analysis of the system. Technical feasibility indicates that what technology to be used for development & tools needed. Requirements Engineering: This phase believes A problem well specified is half-solved. Requirement engineering is a disciplined application of proven, principals, methods, tools &notations to describe a proposed system s intended behavior & its associated constraints. This includes following activities: 1) Identification & documentation of user needs. 2) Creation of a document describing external behavior & its associated constraints. 3) Analysis & validation of document to ensure completeness. Department of BCA Page 18

19 The primary output of this stage is requirement specification, which describes both hardware & software. If it describes only software then it is Software requirement Specification. The document must be understandable by: users, customers, designers & testers. The document includes. 1) Inputs & Outputs. 2) Functional requirements. 3) Non-functional requirements-performance. Reasons for Poor-Requirement Engineering: 1) Requirements will change. 2) Difficult to cover. 3) Communication barrier between developers & users. 4) Lake of confidence by developers. 5) Use of in-appropriate methods. 6) Insufficient training. Software Requirement Specification (SRS) SRS is a means of translating ideas in the minds of clients into a formally specified set of requirements. SRS document is a communication medium between customer & the supplier. The document is initially not to be edited. This phase includes following activities; a) Problem/Requirement Specification b) Requirement Specification. The first step is to understand the problem, goals, & constraints. Second step is the specification of needs that is identified in first step. This phase terminates with validated requirement specification document. Why SRS is required? This may be used in competitive tendering of the company or writing to their own. Used to capture user requirements & highlight any inconsistencies, conflicting requirements. Department of BCA Page 19

20 The client doesn t know about software or software development & the developers don t understand client s problem & application area. Hence there is a communication gap between client & developers. Thus, SRS act as a bridge between this communication gaps. needs. A good SRS should satisfy all parties. SRS also helps clients to understand their What is contained in SRS? / Components of SRS The SRS document should contain a list of requirements that has to be agreed by both client & developers. 7) Acceptance testing requirements 1) Functional requirements 8) Documentation requirements 2) Performance requirements 9) Quality requirements 3) Interface requirements 10) Safety requirements 4) Operational requirements 11) Reliability & Maintainability requirements 5) Resource requirements 6) Verification requirements 1) Functional Requirements: This is a subset of overall system requirements. This consider trade-offs (hardware & software) & also describes how the system operates under normal conditions & response to software failures OR invalid inputs to system. 2) Performance Requirements: This can be stated in measurable value i.e., rate, frequency, speeds & levels. This can be extracted from system specifications. 3) Interface Requirements: This can be specified separately for hardware & software. These requirements specify any interface standard that is requested. These should be carefully documented. 4) Operational Requirements: This gives the in the field view of the system. The specified details are, a) How system will operate & communicate? b) What are the operator syntax/notations? c) How many operators & their qualification required? Department of BCA Page 20

21 d) What help is provided by system. e) How error messages should be displayed? f) What is screen layout look? 5) Resource Requirements: Specify utilization of hardware, Such as amount, percentage & memory usage. This is very important when extending hardware. The software resources include using specific, certified, standard compilers & databases. 6) Verification Requirements: This specifies how customer accepts after completion of project. This specifies how functional & performance requirements to be measured. This also states, whether tests are to be staged or only under completion of the project and also whether a representative of client s company should present or not. 7) Acceptance Testing: This provides details of tests to be performed for customer acceptance in document. 8) Documentation Requirements: This specifies what documents are to be supplied to client, either through the project OR at the end of the project. The document & other relevant documentation 9) Quality Requirements: This specifies whether product should meet international or local standards. The quality factors are: Correctness, reliability, efficiency, integrity, usability, maintainability, flexibility, portability, reusability 10) Safety Requirements: This specifies safety steps to be taken for protection of human, equipments & data. i.e., protecting from moving parts, electrical circuitry & other physical dangers 11) Reusability Requirements: This states that software must perform function under stated conditions, for a given period of time. Department of BCA Page 21

22 12) Maintainability Requirements: This is maintenance of software in the site it is used, for hardware & software changes in the system. Characteristics of Good SRS: The SRS must be clear, concise, consistent, traceable & unambiguous. Complete: The SRS should include all types of requirements to be specified. Consistent: There should not be any conflict, there may be following confliction. Multiple descriptors: Two or more words referring to the same object. Opposing physical requirements: Description of real world objects clash, i.e., one requirement states warning indicates orange & another states red. Opposing functional requirements: This is a conflict in functions. Traceable: Tracing the references, which help in modifications have made to requirement to bring out to its current state. This is an aid in modification in future documents by stating references. Unambiguous: This means Not having two or more possible meanings. This means each requirement can have only one interpretation. One way of removing the ambiguity is to use requirement specification language. This is beneficial when detecting ambiguity using lexical syntactic analyzers. The disadvantage is time needed for learning and understanding of the system to be built. Verifiable: The software requirement specification must be verifiable, that it contains all of the requirements of the user. Verifiable requirements are that the software product must use a cost effective method. Non-verifiable requirements are system should have good-interface and work well under most conditions. How requirement are specified? The two factors needed for requirement specification are: 1. Notation used to describe requirement 2. How the notations is to be presented to the reader of SRS document Department of BCA Page 22

23 Notations These are the terms used for specifying the requirements. This is used since the customer does not understand the technical language. Hence the requirement expert must know the ability of knowledge of customer to understand modeling. Modeling techniques include Z schema, DFD, ER diagram, state transition diagram, and flow charts. Benefits of Good SRS 1. Establish basis for agreement between client and supplier. 2. Reduces development cost 3. Helps in removal of inconsistencies, omissions and misunderstandings. 4. Helps in validation of final product. Department of BCA Page 23

24 Chapter-4 SOFTWARE COST ESTIMATION Estimation of cost of the software products is an important task. There are many factors which influence on cost of a software products development and maintenance. The primary cost factors are: a) Programmer ability & familiarity of application area b) Complexity of product c) Size of the product & available time d) Required level of reliability e) Level of technology used f) Familiarity & availability of technology. 1) PROGRAMMER ABILITY: In 1968, Harold sack man conducted an experiment on colleges, to determine influence of batch & time shared access on programmer s productivity. Twelve well experienced programmers were given with two programming problems to solve. They have resulted that differences in individual performance among programmers were much greater than batch. On small projects (5 people) individual difference in ability is significant, but for the large project that is not significant, cost is less when project involves best programmers. 2) PRODUCT COMPLEXITY: There are 3 categories of S/W products. 1. Application programs: Database processing or scientific programs Usually application programs are developed using programming language compiler such as C or PASCAL. 2. Utility programs: Compilers, linkers, loaders Utility programs interacts with operating software management provides user processing environment. 3. System programs: DBMS, operating systems, real-time system. System Programs interacts directly with hardware, Department of BCA Page 24

25 Brooks states that writing utility programs is 3 times difficult than to write application programs. System programs are 3 times difficult to write as utility programs. Then complexity is Application (1): utility (3): system programs (9) Boehm, use three levels of complexity & gives equations to find programmer month s (pm) effort. In terms of thousands of delivered instructions (KDSI). Application programs: Utility programs: System programs: pm=2.4*(kdsi)**1.05 pm=3.0*(kdsi)**1.12 pm=3.6*(kdsi)**1.20 As the effort is more, cost will be high. 3) PRODUCT SIZE: As the product size increases the cost will be higher. The rate of increase in effort grows at an exponential slightly less than one, but most use exponent ranges from 1.05 to ) REQUIRED LEVEL OF RELIABILITY: Reliability defined as the program performs a required function under stated conditions to stated period of time. Reliability is expressed in terms of accuracy, robustness, complete & consistent of source code. The level of reliability should be established at planning phase, by considering cost of S/W failures. 5) LEVEL OF TECHNOLOGY: This is the programming language, hardware & software tools used in project development. Use of high level languages instead of middle level languages increases the programmer productivity. The latest/ modern programming languages such as java includes enhanced features such as data abstraction, debugging, separate compilation, interrupt handling & exception handling. Department of BCA Page 25

26 The hardware also influence on programmer productivity, since programmer s familiarity, stability & knowledge of access with that hardware. If new machine is found, programmer has to learn it as part of development process. Use of modern practices & tools in development reduces the effort. COST ESTIMATION TECHNIQUES: 1. Empirical Estimation Technique: This technique based on making cost estimation by educated guess using project parameters & past experience. 2. Expert Judgement: This technique is widely used. An expert makes an educated guess after analyzing the problem thoroughly. Then estimates the different components of the system & combine to make over-all estimate. But the expert must have experience of that project. This approach believes on individual as the team may have personal biases, political considerations & influence of seniors. 3. Delphi Cost Estimation: In this estimation is done by a group of experts & a coordinator, firstly, coordinator provides SRS document & form for recording cost estimation to each estimator return the form filled to coordinator anonymously. Then coordinator displays summary of response of estimators. The process is iterated by several rounds & there is no discussion between estimators throughout the process. 4) Work Breakdown Structure (WBS): This provides notations for representing major tasks to be carried out to solve a problem. The major activities are divided to form a tree. Where, each node is broken down into small components as children of the node. The following fig represents WBS of management information system (MIS) application. Department of BCA Page 26

27 MIS Application Requirements Design Coding Test Document Specification Database Graphical Database Graphical Part Interface part Part Interface part part 5) Activity Networks: WBS representing interdependencies of various tasks, where as activity network shows both interdependencies & also estimated duration. Rectangular nodes represent tasks & duration shown alongside of each task. WBS & activity networks are used for cost estimation. 6) Heuristics Techniques: This technique uses mathematical expressions to mode the project parameters. The heuristic estimation models divided into 3 classes, Static single variable Static multivariable Dynamic multivariable model. Static single variable model provides mean to estimate different characteristics of a problem using previously estimated characteristic of S/W product such as product size. This takes form, Resource = c 1 x e d1 E previously estimated characteristic of S/W. Resource to be predicted, i.e, effort, duration, staff size, etc Department of BCA Page 27

28 c1, d1 Constants derived by past experience. The example is COCOMO model. COCOMO MODEL Constructive cost Estimation model was proposed by Boehm. He postulates three classes of products: 1) Organic products Application programs (Data processing & scientific) 2) Semi- detached Utility programs ( Compilers, Linkers) 3) Embedded System programs Boehm introduces three forms of COCOMO: 1) Basic COCOMO: Computes development effort & cost, given program size in estimated lines of code. 2) Intermediate COCOMO: Computes effort as function of program size & various cost drivers that relates to product, hardware, personnel, & project attributes 3) Advanced COCOMO: This model incorporates all intermediate model characteristics with an assessment of cost driver s impact on each step of Software engineering process. COCOMO can be applied to 3 modes of the projects a) Organic mode: these are simple, small projects developed by small teams with good experience. b) Semi-Detached: these are medium sized projects (in size and complexity) developed by the team with mixed experience. This project doesn t meet the rigid requirements of the project. c) Embedded project: these projects should be developed within set of tight constraints. Ex: Flight control software. Basic COCOMO Equation E= a b x (KLOC) exp(b b ) [Effort of person months] D=c b x (E) exp(d b ) [development time in months] Department of BCA Page 28

29 Where E - Effort applied in person months D - Development time KLOC- estimated no of lines of code a b, c b co-efficients b b, d b components are in table. From E & D, we can compute no of peoples required for project N, by equation, N = N / D [People] Software project a b b b C b d b Organic Semi-detached Embedded Intermediate COCOMO This is an extended model with a set of cost drivers. The equation is E= a i (LOC) exp(b i ) x EAF EAF effort adjustment Factor (range ) E- Effort applied in person months a i, b i co-efficients in following table. Software project a i b i Organic Semi-detached Embedded Department of BCA Page 29

30 Table of cost drivers COST DRIVER DESCRIPTION RELY DATA CPLX TIME STOR VIRT TURN ACAP AEXP PCAP VEXP LEXP MODP TOOL SCED Required software reliability Database size Product complexity Execution time constraints Virtual machine volatility degree to which the computer operating system change Computer turn around time Analyst capability Application experience Programmer capability Virtual machine (i.e operating system) experience Programming language experience Use of modern programming practices Use of software tools Required development schedule. Staffing level estimation: Modern studied different staffing patterns of different R & D projects and uses Raleigh curve for staffing estimation. This is the simplest way to determine numbers of software engineers is to divide effort estimation. This is an important since all phases of development doesn t require 2 E=K/t d x t x exp[-t 2 /2t 2 d ] Department of BCA Page 30

31 Effort Software Engineering constant number of engineers. If a constant number of engineers used may cause some phases will be over staffed and some under staffed. He derived an equation Where E- effort required at time t. This is also an indication of no of engineers at particular time. K Area under curve. td- Time at which curve attains max, value. E=K/t d 2 x t x exp[-t 2 /2t d 2 ] T d =Design Time T d Time Putnam Estimation Model: Putnam studied staffing problem of software projects and says that Raleigh. Modern curve can be used to relate the number of delivered lines of code to effort and development time. Putnam estimation model is a dynamic multivariable model. The derives an equation. L= C k K 1/3 t 4/3 a Where, K - effort extended td Time to develop software Ck State of technology constant. The typical values are ck=2, poor development i.e no methodology, poor documentation and review, etc., Department of BCA Page 31

32 CHAPTER-5 SOFTWARE DESIGN This is the step of moving form problem domain towards solution domain. Input to this stage is the SRS (Software Requirement Specification) document and output of this stage is architecture design of system to be build. Design is the stage in software development, which produces a model or a representation of a system, which is used to build the system. The design specification must be language independent and used in implementation and testing. Design objectives: The major goal of this stage is to provide a best possible design, within limitations by requirements, by social and physical environment constraints. The criteria used to evaluate design are 1. Verifiability a) Completeness b) Consistency c) Efficiency 2. Traceability a) Simplicity / understandability Software design: Design is a blueprint or a plan of the solution system, representing components, subsystems and their interactions. Two levels of design: 1. Top level design / conceptual design or system design : This level focuses on identifying different modules to be developed their specifications, connections and interactions between them 2. Logic or detailed design: This is the internal design of models to satisfy specifications of modules. The design may be function oriented. Department of BCA Page 32

33 Major design activities are: 1. Architectural design: identifying subsystems and their relationships which makeup the system and documented. 2. Abstract specification: Each subsystem must be abstract and its services to be provided. 3. Component design: Designing services and interfaces of different components 4. Data structure design: Designing detail specification of data structure to be used in system. 5. Algorithm design: Designing algorithm used to service to be provided in the system. Architectural design: The steps involved are: a) system structuring: The system structure is decomposed into major subsystems and each subsystem is an independent software product b) Control modeling: The control relationship between different parts of system is designed. c) Modular decomposition: Decomposition of each subsystem into modules and their interconnections. There is no single design model that fits all the requirements. An architectural model is a block diagram of the system and provides overview of the system. There are three standard models that are used popularly are: 1. Repository model 2. A client-server model 3. Abstract machine model Design Concepts The design concepts are used to reduce the complexity of design process and also reduce the errors that are introduced in the design stage. Partitioning: Partitioning process focuses on defining a large problem into number of smaller tasks. That is termed as Fine grained decomposition of a problem. Department of BCA Page 33

34 A good partitioning divides problem into smaller pieces, both computation and data associated with the problem is called domain decomposition. The functional decomposition is an approach of first decomposing computation and then data. Abstraction: Abstraction is a tool, that designer has to consider a component at an abstract level without worrying the implementation details of the component. Abstraction describes external behavior of system without bothering its internal details. Abstraction is the most important, since at this stage the component doesn t exist. There are two abstract mechanisms are: 1) Functional abstraction: In this a model is specified with its function it performs. For ex: searching of an element is specified as searching 2) Data abstraction: This is a process of binding data together with the operations that can be performed on it. This technique is helpful in preventing misuse of data from external objects. This is the basis for object oriented design. Information hiding: In this approach, each module in the system hides the internal details of its processing activities and modules communicate only through well defined interfaces. The information hiding includes: a. Data abstraction b. Control abstraction ( format of control blocks, queues, stacks) c. Character codes d. Machine dependents details Structure: The general fro of system structure is network. The design represents network as directed graph, consists of nodes and arcs. Nodes representing processing element that transform data and arcs represents link between nodes. Department of BCA Page 34

35 Module level concepts: A module is a logically separable part of program which is discrete unit. In a programming language, a module is a function or a procedure. A module should support well defined abstractions, solvable and modifiable separately. The criteria used for modularization are: a. Coupling b. Cohesion Coupling: Coupling is the strength of interconnections between modules or a measure of interdependence among modules. If two modules are closely connected means they are highly coupled. Loosely coupled modules are having weak interconnections, where modules have no inter connections are having no coupling. Coupling increases as the complexity of interface between modules increases. Coupling is an abstract concept and it cannot be measured or formulated. Coupling can be minimized by reducing number of interface per module & complexity of interface. Two components can be dependent on: a) Reference made between components. I.e. model A invokes module B, that means B depends on A. b) Amount of data passed between modules, just like passing a block (array) of data from module A to module B. c) Amount of control that a component has on another. d) The degree of complexity in interface between components. In practical, it is impossible to build components with no coupling. But if coupling is high, then other components are affected at the time of modification of a component. Hence, a low coupling helps to minimize number of components needing revision. The types of coupling are: 1) No coupling: The modules are not having interconnections. 2) Data coupling: In this coupling, only data will be passed from one module to another. Department of BCA Page 35

36 3) Stamp Coupling: in this, data structure will be passed from one component to another. 4) Control Coupling: in this a component passed a parameter to control the activity of another. 5) Common Coupling: in this many modules access from a common data store (global data). In this, it is difficult to determine which component is responsible for change in data. 6) Content Coupling: One component is completely dependent on another. That is a component uses data or control information maintained within another module. Components in object-oriented design has low coupling since each object contains functions which defines actions performed by it or on it. Thus, low coupling is an advantage of object-oriented design. Cohesion: Cohesion of a module represents how tightly bound the internal elements of the module to one another. This is an intra-module concept There are different levels of cohesion, they are 1) Co-incidental Cohesion: This is a condition, where there is no meaningful relationship among the elements of the module. 2) Logical Cohesion: In this, there is some logical relationship between elements of the module. 3) Temporal Cohesion: The elements in a module are executed together. These exit in modules performing initialization, clean-up,& termination. 4) Procedural Cohesion: A procedurally cohesive module contains elements that belongs to same procedural limit 5) Communicational Cohesion: In this level, module has elements that are related by a reference to the same input or output data. This level module is performing more than one function. 6) Sequential Cohesion: The elements are together in one module, where output of one forms an input to another. 7) Functional cohesion: This is the strongest cohesion, in which all elements of a module are related for performing a single function. Functions like compute square are functionally cohesive. Department of BCA Page 36

37 All models in a design must be good when it functionally cohesive and low coupling, the number of modules obtained by the portioning must be minimized. Because large number complexity and lead to a bad design Design Notations The representations schemes used in design are called as Design notations. Notations used to specify the external characteristics structure and processing details of the system, the design notations used are 1. Pseudo code 2. Structured English 3. Data flow diagram 4. Structural charts Pseudo code: pseudo code is like flow charts. They describe system characteristics using short. Concise, English language phrases that are structured as keyword like if then-else, while, for, do etc. Pseudo code can replace flow charts and reduce the amount of external documentation Structured English: This is used to provide a step by step specification for an algorithm. This uses common English words.this is used to specify cookbook recipes. DATA FLOW DIAGRAMS DFD is a tool used by system analysts to show the flow of data in an information system. The different symbols or components for representation are 1. Process: Process transforms a data flow by either changing its structure or by generating new information from it. A process must have at least one data flow into it and one data flow out of it. A process in DFD having contains a process id, location of process and process title Process Id Location of Process Title of the process Department of BCA Page 37

38 2. Data flows: A data flows can be represented by an arrow depicts data flowing form one process to another. The arrow head shows directions of flow and with a label as identification. Data Flow Name 3. Data stores: A data store is a computer file, a manual record or a pile of documents. It is a collection of related information a telephone book, patient records student records. ID Data Store Name Each data store is having a unique id that is a letter followed by a number and data store name. 4. Sources and sinks (terminations or external entities) External entities are which provide or reactive information form to the system. Source name Sink name A sink is a one which receives information form the information to the system. An external entities are people, place, a manager a sales department 5. DFD leveling: DFD s allows analyst or user to look a system at different levels of details. DFD leveling is a practice where a DFD depend on its details into set of DFD s. The DFD depend on its detail representation called as level 2 diagrams. If necessary it is possible to design level 3 and level 4 etc for more detailed representation. Context diagrams (level 0 DFD): A level O DFD is known as context diagram representing high level details of the system. Context diagram comprises a process box for entire system, with external entities and data flows between them. Department of BCA Page 38

39 A current physical DFD Is a s DFD showing data and operation within current existing system. Guidelines to draw context diagram: a. Read case study from start to end, until you get a fair idea about system and its processes. b. Make a list of external entities. c. Identify data flows from system and to the s/m Level 1 DFD: More detailed representation is shows in level 1 DFD. Level 1 DFD contains data flows, data stores, process and external entities. The data flows are connected to and from the actual process which create reactive or change them. Processes are identified by number as 1,2,3,4 & so on. Guidelines to draw level 1 DFD: a. Make a sentence of function in system and identify verb as a process in the system b. Make a list of all potential process c. Group potential process to from 3 to 10 process A DFD must contain minimum of 3 and maximum of 10 process d. Identify data flows e. Identify list of data stores Advantages of DFD: 1. Easy to understand and validate correctness 2. Since DFD is a pictorial representation, it can be understood quickly than textural narration 3. DFD shows an abstract specification of system. It only shows what system will do? Rather than how it can be done? Structured Charts: This is used in functional oriented design. The structure of a program is made up of modules and their interconnections. A structured chart is a graphical representation of structure of a problem. In this module is represented by a box, with its name. The flow of Department of BCA Page 39

40 data parameters are represented by arrows. The parameters can be shown as data by unfilled circle of the arrow. The invoking (calling) function is called superiordinates and called function is called subordinate Main a, n Sum Read nums Sort Add - n x, y x, y Swap() There may be situations, where designer wish to communicate procedural information explicitly like loops and decisions, there are represented as follows A A B C D B C D Iteration Decision Design techniques Several techniques have been developed for software design include 1. Step wise refinement 2. levels of abstraction 3. Structured design 4. Integrated Top-down development Department of BCA Page 40

41 5. Jackson method The design techniques are called as Design methodologies Design methodology is based on top-down bottom up approach used in design. In Top-down approach a system is decomposed into subsystems and importance is given to specific tasks. In top down approach lowest level ( elementary) modules are specified first, the primary advantages of this strategy is more attention is towards customers needs, users interfaces. In bottom up strategy designer identifiers a set of primitive objectives, actions and relationships that provides basis for problem solution, high level concepts ate then formulated in terms of primitives The success of bottom up design depends on identifying the proper set of primitives ideas. 1. Stepwise refinement: This is a top-down technique for decomposing a system from high level specifications into more elementary levels. This is also called as stepwise program development and successive refinement. This is originally descried by WIRTH (WIR71). This technique involves following activities: 1. Decomposing design decisions to elementary levels 2. Isolated design aspects that are not truly interdependent 3. Demonstrating each step as an explosion of previous step. 4. postponing design decisions In each step postponing design decisions as long as possible provides designer to build consistent design. The input to this technique is software requirement specification and external deign. The problem is decomposed into few major processing steps and process is repeated until each part of system contains sufficient detail can be executed in programming language straightly. This technique uses structured charts and pseudo code for representation, pseudo code is consists as refinement proceed. This technique makes problem into small, manageable pieces with sufficient amount of detail, which can be learned at a particular time is minimized. Hence designer makes proper time to proper concerns of the problem.the success of this technique is purely depend upon understanding of the problem and ability of design Department of BCA Page 41

42 2. Levels of Abstraction : Described by dijkstra as for bottom up approach of design, he considers an operating system design of layers (levels). Each level of abstraction includes group of functions some functions are externally visible i.e. invoked by function on higher levels of abstraction, some fins are internal which can be invoked only by functions of the same level. Internal functions are hidden to other levels. The functions of higher level cannot be used by functions at lower level. Thus function usage makes levels of abstraction. Each level performs set of services to functions at next higher level. each level uses certain resources such as Input / output devices, data structures, which are not permitted to access by other level. Levels of abstraction in T.H.E operating system Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 processor allocation, clock and interrupt handling Memory segment controller Console Message interpreter I/O Buffering User programs Operator 3. Structured design Methodology: This methodology though that overall activities is to identify the input and output and the primary transformation by the software system. The primary attention is given on the transformation process function. The goal of SDM is to reduce coupling between models and enhance in different models. The documentation tool used is structured charts. The following are the major steps are: 1. Restate problem as DFD 2. identify input and output Department of BCA Page 42

43 3. first level factoring 4. factoring of input, output and transform branches 1. Restate problem as DFD: A DFD is constructed as first step of SDM in this major transformation are shown in picture. 2. Identify most abstract and output: The software system transformation cannot be applied on actual physical input to produce desired output. Instead input is first converted into a form which can be transformed to desired output easily. In the similarly manner, transformation modules produce, output that to be converted that to desired physical output. The goal of the second step is to separate transformation in DFD, which convert input or output to desired from the one that perform actual transformation. Thus identify most abstract input or output, which are removed from physical input or output in the system. 3. First level factoring: Identifying the central transformation and most abstract input and output data is done in second step then identify main modules to invoke its subordinates. Then most specified finally central transform a subordinate module to main one is specified, which are transformation modules, whose function is to accept data from main module and return appropriate data back to main module, 4. Factoring input output and transforms branches: First level factoring is high level structure where subordinate module has to do more than it look, hence in this stage, in more detail the input output and central transformation is described. This step is nothing but more detailed representation of factoring. Object oriented design This design identifies objectives in a system, which s are packed with information and relationships and interactions between objectives. The advantages of OOD is modifiability, reusability and avoidance of misuse Components of OOD: Department of BCA Page 43

44 1. class and objects from basic building blocks 2. Encapsulation of data with its implementation prevents external misuse of data. 3. Class defines set of objects share common projects and operations. Data declaration limits its access to others ( such as public or private) 4. interfaces defines how a part of an object can s be accessed 5. method of a class defines operations that can be performed on object 6. Message passing is used between objects to invoke service of an object, The invoking object (server) sends message to object (called client) to invoke its service. Department of BCA Page 44

45 CHAPTER-6 CODING This is the phase where you can see actual development of software product. Coding is the phase where design is translated into some programming language instructions. The goal of this phase is to reduce the work of tester and maintainer. The programs constructed must be easy to write, read and understand. The criteria s used to judge a program as good are 1. readability 2. Program size 3. execution time 4. Required memory The primary goals of coding are understandability and modifiability. Structured coding technique This technique is told as go-to less programming. The program has a static structure I as well as dynamic. Static structure is the structure of the text of program. Which is a liner organization of statements of program are executed during execution. if the statements are linear then it is helpful in verification. The program must have single exit and single entry. Data encapsulation: This involves the process of packaging of data structures and its access routines in a single module. The data structure can only be accessed by access routines. Routines are not known about the details of data structure. Thus forms an abstract data type (objectives) an abstract data type is a user defined template that can be used to create numerous instances of encapsulated data objects. Data abstract describes design principle of both data encapsulation and abstract data type. Recursion: Recursion means process of calling itself as small problems of it. Recursion program are easy to understand and lowering complexity. Hence recursion serves clarify and efficiency, if it is used appropriately. Department of BCA Page 45

46 Coding Style The coding style enhances the readability maintainability and understandability of the program significantly. Thorough knowledge of syntax of programming language is to be used in writing a good program some guidance to write a good program are given below 1.Names: The module and variable names used must be appropriate to its function that it performs the length names usage is not a good practice. The names should be short, precise and closely reflect their activity. The appropriate names helps in the referencing 2.Control constructs: Single entry and single exit control statement must be used fewer standard constructs must be used is desirable rather than using a verify of control constructs, more control constructs may decrease program understandability. 3.Gotos: Gotos in the program must be used in a disciplined manner. In COBOL, FORTRAN Gotos usage is common.an alternative can be used (loop) rather than Gotos. 4. Information hiding: Information hiding must be done where it is possible to the data only access functions has to be made. 5. User defined types: Modern languages allows to define types, that should be used wherever possible when working with dates, you can defined types 6. Nesting: Control constructs can be nested, but the nesting should not be deep, which decease understandability of program. Hence deep nesting must be avoided, which leads to different to understand 7. Module size: less size models (less than 5 statements) will be unnecessary, since compiler has to perform more actions when accessing a module and a large size module will be less functionally cohesive. 8. Module interface: A module having complex interface must be examined. Simple interface must be used. The parameters should not be more than 5, since there may be difficulty in understanding 9. Program Layout: The program must be organized and presented well to increase readability. proper indentation, blank spaces and program automated tools it is a good practice to make clear layout of program 10. Side effects: A module function should not modify other module data or function; the global data should be handled carefully by the modules. if a module has side effects it should be documented, Department of BCA Page 46

47 Internal documentation: Internal documentation i.e. some statements about particular data or function written in the program should be used to make better understandability. Comments are statement used for this purpose in the program, which are not executed but held within the program Comments of module as called prologue of the module. Verification: This is the process of detecting errors introduced during coding. The goal is to show the consistency of the code with the design. The verification methods are in two categories: 1) Static Method: In this method, program is not executed or compiled. This is a conceptual execution & manual. This involves verification, code reading, code reviews, walk, though & symbolic execution, this is an economical method. 2) Dynamic Method: In this method, actual program is executed with some test data & outputs are tested for presence of errors. The overall program will not be tested for errors. Code Reading: This is a process of careful reading the program by programmer to detect any errors/ inconsistencies between design specification & implementation. This also checks for abstraction of a module with design specification. This is a process starting from inner-most structure towards abstract; specification of a module code reading is useful, economical & can detect errors which are not detected at testing. Static Analysis: Analysis of program by analyzing program text is called static analysis. Some tools are used mechanically to detect errors. The program is not executed, but program test is an input to the tools. The aim of this analysis is to detect errors, potential errors (logical errors) or generate information about structure of program for better documentation & understanding the program. Department of BCA Page 47

48 Static analysis is very cost-effective. & determine violation of standard programming standards. This process can reduce the effort of testing. This also finds data flow anomalies, which is not detected by compiler. Data flow anomalies are caused by carelessness in typing, error in coding. An example for data flow anomalies is a variable is assigned a value but not used in program later. Other examples are unreachable code, unused variables & unreferenced labels. These are not technical errors but may cause inefficient programs. Code reviews: Code review is done after code writing is completed, compile & passed out of static analysis to detect errors. The review is team includes programmer, designer & tester. The aim of review is to detect errors that fail to implement design. This may be due to usage of different module, interface that is not specified in the design. The code defects are classified into two categories: 1. Logic and control errors : Such as infinite lops unreachable code, missing or unreferenced labels and improper use of nesting 2. Data operations and computations errors: Includes defects in computations, incorrect access of array components, improper initialization and misuse of variables Department of BCA Page 48

49 CHAPTER-7 Testing and Maintenance The software testing involves verification and validation techniques. Verification & validation techniques The verification and validation techniques are used to access and improve quality of products this also checks for quality attributes such as correctness, completeness, reliability, usefulness, efficiency, standards and over all cost effectiveness. Two types of verification 1. life-cycle verification : This process determines degree to which products at a given of cycle fulfill specification the prior phases 2. Formal verification: This is a rigorous mathematical demonstration that source code conforms to its specifications. Validation is the process of evaluation of software at the end of development process to determine compliance with requirements Boehm phrases to differentiate verification and validation as Verification : Are we building products right? Validation : are we building right product? Verification and validation assess work products to its conformance of specifications, specifications include requirement specification, design documentation implementation language standards, project standards, organizational standards user expectations and notations used in product specifications. Requirements are examined for conformance of user needs, environmental constraints and notations. Design documentation is examined with respect to requirements and notational conventions. Supporting documents such as users manual, test plan must be examined for correctness, completeness. Department of BCA Page 49

50 The errors may be caused are 1. Requirement errors: This may be caused by incorrect specification of user needs or incomplete specification. 2. Design errors: these are caused due to failure to translate requirement to correct, complete design this cannot be find out until source code is tested, this is most costlier to correct errors. 3. Implementation errors: Errors caused during translating design to code. This can be unreferenced data, incorrect input / output, in control flow logic in module interfaces. The quality of work products can be assessed and improved by using systematic quality assurance procedures by walkthroughs and inspections. The techniques used are: 1. Software quality assurance procedures 2. walkthroughs and s inspections 3. unit testing 4. integration testing Software quality assurance (SQA): SQA is a planned and systematic pattern of action taken to ensure quality in software SQA involves reviewing and auditing the software products and activities to verify compliance with procedures and standards. SQA group works also s during early stages in planning establishing standards and procedures, hence participation of SQA team helps them to verify needs and ensure the quality. The team reviews and audits throughout the life cycle and provide visibility of adherence of plans, standards and procedures to management. Goals: Adherence of product and activities to established plans standards and requirements are verified Affected groups and individuals are informed of software quality assurance activities and results Non-compliance issues that cannot be resolved are addressed to senior management Department of BCA Page 50

51 Activities Performed 1. SQA plan is prepared according to document procedure at project planning 2. Activities performed as per plan a. Responsibilities and authorities of SQA group b. Staff, tools and facilities requirements of SQA group c. Schedule and fund of SQA group activities d. SQA group participation in planning, standards e. its and reviews performed by SQA group f. procedures to be used for documentation g. Documentation to be produced by SQA group 3. Participation of group in preparation and review of plan standards and procedures 4. verification of compliance of product by reviewing evaluation of deliverable product before delivery Corrections are verified Deviations are identified, documented 5. Reporting the results of activities to software engineering group Walking through and Inspections: Walkthrough and inspections are used to systematically examine the products through the cycle, the requirements, design specifications, test plans source code, and principles of operation users manual and maintenance procedure are examined. A walk through is not a project review, but an in depth examinations of work product by individuals who are experts and give opinions. Inspection comprises a team of trained inspectors work from check list of item to be examined and perform inspections of work products. Walk through session held in open environment the goal of walk through is to discover and document problem areas. Problems are not resolved by reviewee following sessions. A review may work with one or more reviews to resolves the problem. Memos and meetings are issued to reviews for information of actions taken. But solving the problem is the responsibility of reviews. Department of BCA Page 51

52 Guidelines for successful walkthroughs: 1. Every work is to be reviewed on scheduled basis 2. Emphasis on detecting errors, but resolving problem is not to be in walkthrough session 3. walkthrough must take detailed discussion of minor and major problem ] 4. Walkthrough session must be limited to 2 hours Inspection team consists of 1-4 members who are trained to their tasks, Inspectors pick items from check list for inspection and each participant of team has a definite role to play According to Fagan an inspection team consists of four persons, moderator, designer, implementer and tester. Inspected items are completeness of design with respect to requirements, correctness of inter faces controls, data, referencing computational expressions. Input / Output statements and memory usage The interesting fact is error found is given to correct by programmer who made and with this feedback they eliminate similar errors from their subsequent works this improves quality and productivity Fagan says a moderator in team is rather than review, directs effort and gives detailed error feed back to the individual programmers Software Testing: Testing is the process of executing the program to find errors in the code. Objective of testing is to find errors (incorrectness) and testing is successful when an error is detected and error may be at design or programmers work. Testing should not be a separate phase, but it should be through all phase of cycle Unit testing: Unit testing is the analysis of individual units to check whether they meet requirement specification or not. A unit can be a module which is a subtask of the program. A unit tested using inputs structural testing is also called white box or Glass box testing. Department of BCA Page 52

53 The programming faults are identified using static and dynamic analysis. Structure faults are found out by dynamic analysis. Debugging: Debugging is the process of isolating and correcting causes of known errors. Debugging methods include induction, deduction and backtracking. Backtracking involves moving back from where error is observed, to the actual error caused point. Traditional debugging techniques are diagnostic output statements, snap-shot dumps, selective traces on data values and control flow and instruction breakpoints. Integration testing: Integration or subsystem testing is concerned with verifying design and requirements. Units are integrated by a pre-defined strategy such as bottom-up or top-down strategy. The growing system and interfaces are checked for compatibility. i.e., function parameters tested for order and type. System and acceptance testing: System and acceptance testing concerns with the execution of test cases to evaluate whole system with respect to requirements of user. An acceptance testing is the process of executing test cases agreed with customers as adequate representation of user requirements. This is called as Black Box Testing. Functional testing: Functional testing is a black-box technique to verify functions are written correctly and perform required operation. Software Maintenance Maintenance costs more than the budget of overall development process. Somerville states that maintenance costs in between 1 and 4 times of development costs.software maintenance is the process of changing a system after it has been delivered to client and is in use. Department of BCA Page 53

54 The process begins with problem report or a modification request by users. Thus, software maintenance can be defined as Process of changing of a system to maintain its ability to survive. Three types (categories) of software maintenance are: 1. Corrective maintenance: This process is concerned with fixing reported errors in the software. Where coding errors are cheaper to correct and design errors are expensive as new programs to be written. Requirement errors are most expensive since system has to be redesigned from the beginning. 2. Adaptive maintenance: This concern with the process of changing software to new environment such as different hardware platform or operating system. 3. Perfective maintenance: This process involves implementing new features on customer demands. Maintenance can be long phase may be up to life time of the product. Maintenance is successful, if all the documents of development process (design and coding) exist, because it is difficult to: Trace changes in code in various version Read someone else s code Change code without knowledge of design. Hence, maintenance is costlier than developing a new product. Department of BCA Page 54