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 vvfgc.bca@gmail.com 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