Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1

Transcription

1 Failure Rate Darshan Institute of Engineering & Technology for Diploma Studies Rajkot Unit-1 SOFTWARE (What is Software? Explain characteristics of Software. OR How the software product is differing than hardware product? OR Explain: Software doesn t wear out, but it does deteriorate. ) Software is a set of programs, which is designed to perform a well defined function. Software can be difficult to describe because it is virtual, or not physical like computer hardware. Instead, software consists of lines of code written by computer programmers. CHARACTERISTICS OF WELL ENGINEERED SOFTWARE If software satisfies all the beloved characteristics then it is said to be good software or the software is well engineered. Software is engineered, not manufactured like hardware Software development is same as hardware manufacturing but it is fundamentally different activity. In hardware manufacturing it introduce quality problem but it can easily corrected in software development. Once a product is manufactured it is not possible or not easy to correct it, change it, enhance it, remove error from it without temper product or it is costly. But software can easily. So the approach of construction of product is different. In case of hardware product numbers of copies generate a cost due to raw material and other manufacturing processing expenses but in case of software it is not the issue. You can create number of copies of software. Software does not wear out First we understand the characteristic of hardware. Hardware can damaged after running time. As time passes hardware component suffer from effects of dust, vibration, misuse, temperature and many other environmental effects. So the failure rate rises. This is the wear out of hardware. Born Phase Usefull Life Phase Wear out Phase Time Figure 1 Figure 2 1 Dept: CE FSD ( ) Piyush Bhut

2 Rajkot Unit-1 The "bathtub curve" shown in Figure 1 depicts failure rate of hardware as a function of time. Hardware suffers high failure rate early in its life. There are three phases in hardware life. In first phase failure rate is much more. But after testing and fixing bugs failure rate will come down and may stabilize after certain time. Second phase is useful life phase of hardware component where failure rate is approximately low and constant. And after few years it comes in last stage where failure rate is high and product will wear out. But software is not highly affected by environmental effects which cause hardware to wear out. The failure rate graph for software component is "Idealized curve" shown in Figure 2. Undiscovered errors will cause high failure rates early in the life of a program. However, these are corrected and the curve becomes flat as shown. The "actual curve" is shown in Figure 2. During its life, software will undergo change or maintenance. As changes are made, some new defects will be introduced, causing the failure rate curve to spike. When hardware component wears out, it is just replaced by spare parts. There is no spare part to replace in software component. It requires further changes in existing product or component. So it is more complex than hardware. Software gives component-based construction, it gives reusability of components Now a day s industry is moving towards component based construction. Efforts have been made to design standard components that may be used in new project. Software reusability has introduced another area which is known as component based software engineering. A software component should be designed and implemented so that it can be reused in many different programs. Once different components are created and tested separately, at final product each component separately not needed to be checked or tested. Integration of components and final product should be tested. Graphical User Interfaces are built using reusable components that enables the creation of graphics window and animated menus. Software is flexible for custom built A program can be developed to do anything. Sometimes, this characteristic may be the best and may help us to accommodate any kind of change. However, most of the times, this "almost anything" characteristic has made software development difficult to plan, monitor and control. This unpredictability is the beginning of software crisis. SOFTWARE MYTHS Software myths propagate false beliefs and confusion in the minds of management, users and developers. 2 Dept: CE FSD ( ) Piyush Bhut

3 Rajkot Unit-1 Management Myths Manager is responsible to maintain a software budget, time constraints, improved quality, and many other considerations. Common management myths are listed in Table. Myths We already have book that s full of standards and procedures for building software. If the project is behind schedule, increasing the number of programmers can reduce the time gap. If the project is outsourced to a third party, the management can relax and let that party develop software for them. Reality Standards are incomplete and outdated. Developers are unaware of standards. Developers rarely follow standards. New workers take longer to learn about the project as compared to those already working on the project. So further delays the project. If organization does not understand how to manage and control software project internally. It will invariably suffer when it outsources the software projects. User Myths Common user myths are listed in Table. Myths Brief requirement stated in the initial process is enough to start development; detailed requirements can be added at the later stages. Software is easy to change because software is flexible. Reality Starting development with incomplete and ambiguous requirements lead to software failure. Adding requirements at a later stage often requires repeating the entire development process. Changes at later stage may require redesigning and extra resources. Developer Myths Some of the common developer myths are listed in Table. Myths Once the program is written, the job has been done. Software quality can be measure only after the program is executed. The only product that is delivered after the completion of a project is the working program(s). Unnecessary documentation slows down the project. Reality 60% to 80% of all the efforts are expended after the software is delivered to the user. Using formal technical review quality of software measured during any phase of development process. Successful project includes not only the working program but also the documentation to guide the users for using the software. Proper documentation enhances quality which results in reducing the amount of rework. 3 Dept: CE FSD ( ) Piyush Bhut

4 Rajkot Unit-1 SOFTWARE ENGINEERING (What is software engineering? Explain Software Engineering as a Layered Technology. OR What is software engineering? Explain the need of Software Engineering.) Software engineering is a branch in computer science that deals with developing applications. It covers the technical part of building software systems through designing, implementing, and modifying software. It also covers software management issues, such as directing programming teams, scheduling, and budgeting. Software engineering may be defined as the systematic design and development of software products and the management of the software process. NEED OF SOFTWARE ENGINEERING Software engineering is methodology provides the framework that guides engineers to developing the software. This framework defines different phases of software development such as requirements analysis, designing, testing, implementation, maintenance etc. The hard part of building software is the specification, designing and testing, not the representation and implementation. Software engineering describes how the software is designed, what types of their requirements and what types of different phases are needed to complete the software product. The main goal of software engineering is to provide models and processes that produce welldocumented, maintainable software. Using process model we can determine in advance how much time, cost and efforts are required to produce the final complete product. Main important point of any software development process is the life cycle on which flow of process is based. This is called software development life cycle (SDLC). SDLC includes requirement phase, design phase, implementation phase, testing phase, installation phase, maintenance phase. Different process models are used in different condition and situations. To get the advantages of any specific process model, particular process model should be followed during development of any software product. This process model specifies a general process, usually a set of stages in which a project should be divided, the order in which the stages should be executed. Overall, the actual purpose of these software life cycle models is to provide a conceptual scheme for managing the development of software systems. Such a scheme could therefore serve as a basis for planning, organizing, staffing, coordinating, budgeting and directing software development activities. SOFTWARE ENGINEERING: A LAYERED TECHNOLOGY Software engineering is a layered technology. Software engineering includes process, methods and tools that enable complex computer system to be built in a timely manner with quality. To build any software product engineer should use and aware of these four layers: Quality, Process, Methods and Tools. 4 Dept: CE FSD ( ) Piyush Bhut

5 Rajkot Unit-1 Quality Process Method The main focus of software engineering is to develop quality product. Quality of product refers to the characteristics that engineer specify for the product. In software development, quality of product refers to the output meets the functions and features specified in the requirement model. The foundation layer is process layer. It is the heart of the software engineering approach. Software process is a set of activities together if ordered and performed properly the desired result would be produced. It defines framework activity. Main objective of this layer is to deliver software in time. The layer after process is method. It describes how to build the software product. Method includes different tasks such as user communication, requirement analysis, design modeling, coding, testing and maintenance. Method gives the exact way to build the software. Method is a way to execute processes in proper manner. Tools Software engineering tools provide automated and semi-automated support to method and process. Any information created by one tool can be used by another, when tools are integrated. Computer aided software engineering (CASE) combines software, hardware, and software engineering database (a repository containing important information about analysis, design, program construction and testing) to create a software engineering environment. SOFTWARE PROCESS Software process means methods of developing software. A software process is a set of activities, together with ordering among them, such that if the activities are performed properly, the desired result is produced. 5 Dept: CE FSD ( ) Piyush Bhut

6 Rajkot Unit-1 Generic View of Software Engineering (Explain three phases of generic view of a software engineering.) The work associated with software engineering can be categorized into three generic phases. Definition Phase The definition phase focuses on what. During definition, the software engineer identify what information is to be processed, what function and performance are desired, what system behavior can be expected, what interfaces are to be established, what design constraints exist, and what validation criteria are required to define a successful system. Development Phase The development phase focuses on how. During development a software engineer define how data are to be structured, how function is to be implemented, how interfaces are to be characterized, how the design will be translated into a programming language, and how testing will be performed. Support Phase The support phase focuses on change associated with error correction. Four types of change are associated with support phase: Correction: Corrective maintenance changes the software to correct defects. Adaptation: Adaptive maintenance results in modification to the software to accommodate changes to its external environment. Enhancement/Perfection: Perfective maintenance extends the software beyond its original functional requirements. Prevention: Computer software deteriorates due to change, and because of this, preventive maintenance, often called software reengineering and must be conducted to enable the software to serve the needs of its end users. 6 Dept: CE FSD ( ) Piyush Bhut

7 Rajkot Unit-1 GENERIC FRAMEWORK ACTIVITIES AND UMBRELLA ACTIVITIES (Explain Generic Framework Activities and Umbrella Activities.) Generic Framework Activities In software engineering an effective process model should define a small set of framework activities that are always applicable regardless of project type. There are five process framework activities: Communication: This activity involves communication with customers and other stakeholders in order to gather requirements and other related activities. Planning: it requires defining resources, timelines and other project related information and describe technical and management risks. Modeling: A model will be created to better understand the requirements and design to achieve these requirements. Construction: Here the code will be generated and tested. Deployment: Here, a complete or partially complete version of the software is represented to the customers to evaluate and they give feedbacks based on the evaluation. These above described five activities can be used in any kind of software development. Each framework activity populated by number of task set that identifies work task that are to be completed, milestones that will be used to indicate progress, deliverables that will be produced and quality assurance points that will be required to get quality product at each stage. Umbrella Activities Umbrella activities are independent of anyone framework activity. Typical activities in this category include: Project tracking and control: allows the team to track progress against the project plan and take necessary action to maintain schedule. 7 Dept: CE FSD ( ) Piyush Bhut

8 Rajkot Unit-1 Risk Management: Identify the risks that may affect the outcome of the project or the quality. Software quality assurance: It defines and conducts the activities to ensure the software quality. Formal Technical Review: It is necessary to uncover or remove errors before they are propagated to the next action or activity. Software configuration management: Manages the effect of change throughout the Software process Reusability management: It defines criteria for work product reuse and establishes mechanism to achieve reusable components. Work product preparation and production: It create work products such as models, documents, etc. Measurement: defines and collects process, project, and product measures that assist the team in delivering Software that meets customers needs. LIFE CYCLE MODEL (SOFTWARE DEVELOPMENT MODELS) A software life cycle model (also called process model) is a descriptive and diagrammatic representation of the software life cycle. A life cycle model represents all the activities required to make a software product transit through its life cycle phases. CLASSICAL WATERFALL MODEL (Define SDLC model. Provide a diagram representing waterfall model. Also, explain various phases of waterfall model.) Feasibility study The main aim of feasibility study is to determine whether it would be financially and technically feasible to develop the product. At first project managers or team leaders study different input data to the system and output data to be produced by the system. The feasibility study concentrates on the following area. Operational Feasibility: Operational feasibility study tests the operational scope of the software to be developed. The proposed software must have high operational feasibility. The usability will be high. Technical Feasibility: The technical feasibility study compares the level of technology available in the software development area and the level of technology required for the development of the product. Here the level of technology consists of the programming language, the hardware resources, other software tools etc. Economic Feasibility: The economic feasibility study evaluates the cost of the software development against the income or benefits gets from the developed system. There must be scopes for profit after the successful Completion of the project. 8 Dept: CE FSD ( ) Piyush Bhut

9 Rajkot Unit-1 Feasibility study Requirement analysis and specification Design Coding and unit testing Integration and system testing Requirements analysis and specification Design Maintenance The aim of the requirements analysis and specification phase is to understand the exact requirements of the customer and to document them properly. This phase consists of two distinct activities, namely Requirements gathering and analysis, and Requirements specification Requirements gathering: The goal of the requirements gathering activity is to collect all relevant information from the customer regarding the product to be developed. This is done to clearly understand the customer requirements so that incompleteness and inconsistencies are removed. Requirements analysis: This activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussions. Requirements specification: During SRS activity, the user requirements are systematically organized into a Software Requirements Specification (SRS) document. During the design phase the software architecture is derived from the SRS document. Two distinctly different approaches are available. Traditional design consists of two different activities; first a structured analysis of the requirements specification is carried out where the detailed structure of the problem is examined. During structured design, the results of structured analysis are transformed into the software design. 9 Dept: CE FSD ( ) Piyush Bhut

10 Rajkot Unit-1 Coding and unit testing (Implementation) The purpose of the coding and unit testing phase of software development is to translate the software design into source code. Each component of the design is implemented as a program module. The end-product of this phase is a set of program modules that have been individually tested. Each module is unit tested for determine the correct working of all the individual modules. Integration and system testing Maintenance Integration of different modules is done once they have been coded and unit tested. During the integration and system testing phase, the modules are integrated. Finally, when all the modules have been successfully integrated and tested, system testing is carried out. The goal of system testing is to ensure that the developed system conforms to its requirements specifies in the SRS document. System testing usually consists of three different kinds of testing activities. α testing: It is the system testing performed by the development team. β Testing: It is the system testing performed by a friendly set of customers. Acceptance testing: It is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivered product. Maintenance involves performing any one or more of the following three kinds of activities: Correcting errors that were not discovered during the product development phase. This is called corrective maintenance. Improving and enhancing the functionalities of the system according to the customer s requirements. This is called perfective maintenance. Porting the software to work in a new environment. For example, porting may be required to get the software to work on a new computer platform or with a new operating system. This is called adaptive maintenance. Shortcomings of the classical waterfall model It is very difficult to strictly follow all the phases in all types of projects. It is not possible to go back and solve the error in this model. High amount of risk. PROTOTYPE MODEL (Define SDLC model. Provide a diagram representing prototyping model. Also, explain various phases of prototyping Model.) A prototype is the sample implementation of the real system. A prototype is a toy implementation of the system. A prototype includes limited functional capabilities, low reliability, and inefficient performance compared to the actual software. 10 Dept: CE FSD ( ) Piyush Bhut

11 Rajkot Unit-1 There are several uses of a prototype. An important purpose is to illustrate the input data formats, messages, reports, and the interactive dialogues to the customer. This is a valuable mechanism for gaining better understanding of the customer s needs: how the screens might look like how the user interface would behave how the system would produce outputs Requirement gathering Quick Design Refine requirement incorporating customer suggestions Build prototype Customer evaluation of prototype Prototype development Acceptance by customer Design Implement Iterative development Test Maintain Prototyping model can be used when technical solutions are unclear to the development team. As shown in figure the first phase is prototype development to control various risks. This is followed by an iterative development cycle. In this model prototyping start with an initial requirements gathering phase. A quick design is carried out and a prototype is built. The developed prototype is submitted to the customer for evaluation. Based on the customer feedback the requirements are refined and the prototype is suitably modified. This cycle of obtaining customer feedback and modifying the prototype continues till the customer approves the prototype. Once the customer approves prototype the actual system is developed using the iterative waterfall approach. 11 Dept: CE FSD ( ) Piyush Bhut

12 Rajkot Unit-1 EVOLUTIONARY MODEL (INCREMENTAL MODEL) (Explain Incremental model With Diagram.) In the evolutionary life cycle model the software requirement is first broken down into several modules (functional units) that can be constructed and delivered. Rough requirement specification Identify the core and other parts to be developed incrementally Develop the core part using an iterative waterfall model Collect customer feedback and modify requirement Develop the next identified features using an iterative waterfall model All features complete Maintenance The development team first develops the core modules of the system. The core modules are those that do not need services from core modules. Non-core modules need services from the core modules. This initial product is refined into increasing levels of capability by adding new functionalities in successive version. Each evolutionary version may be developed using an iterative waterfall model of development. Each successive version of the product is fully functioning software capable of performing more work than the previous version. SPIRAL MODEL (Describe Spiral model with necessary diagram.) The Spiral model of software development is shown in figure. The diagrammatic representation of this model appears like a spiral with many loops. The exact number of loops in the spiral is not fixed. Each loop of the spiral represents a phase of the software process. For example, the innermost loop might be concerned with feasibility study. The next loop with requirements specification, the next one with design, and so on. 12 Dept: CE FSD ( ) Piyush Bhut

13 Rajkot Unit-1 Each phase in this model is split into four sectors (or quadrants) as shown in figure. The following activities are carried out during each phase of a spiral model. Quadrant 1: Determine objectives Identify the objectives, relationships and find the possible alternate solution. Objectives like: performance, functionality, hardware software interface etc. Also examine the risks associated with these objectives. Quadrant 2: Evaluate Alternatives, identify and resolve risks Alternative solutions are evaluated and risks are reduces at this quadrant. In this detailed analysis is carried out of each identified risks. Quadrant 3: Develop, Verify, Next-Level Product Develop and validate the next level of the product after resolving the identified risks. Resolution of critical operational and technical issues, activities to develop, then verification of next-level product are performed. As a result, the basic waterfall approach may be used. Quadrant 4: Customer evaluation Includes evaluation of software by the customer and implementing feedback in the next iteration of the software development. 13 Dept: CE FSD ( ) Piyush Bhut

14 Rajkot Unit-1 RAD MODEL (Explain RAD model.) Rapid Application Development (RAD) is an incremental software process model that is a high speed adaptation of the waterfall model. It makes heavy use of reusable software components If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a fully functional system within a very short time period (e.g. 60 to 90 days). Rapid application development (RAD) is a software development methodology that uses minimal planning in favor of rapid prototyping. A prototype is a working model that is functionally equivalent to a component of the product. In RAD model the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery. Communication is an activity which works to understand the business problem and the information characteristics that should be accommodate by the software. In RAD model Planning is required because many software teams work in parallel on different system functions. Modeling includes three major phases - 1. Business modeling 2. Data modeling 3. Process modeling 14 Dept: CE FSD ( ) Piyush Bhut

15 Rajkot Unit-1 Business Modeling: The business model for the product under development is designed in terms of flow of information and the distribution of information between various business functions. A complete business analysis is performed to find the important information for business, how it can be obtained, how and when is the information processed and what are the factors driving successful flow of information. Data Modeling: The information gathered in the Business Modeling phase is reviewed and analyzed to form sets of data objects importance for the business. The attributes of all data sets is identified and defined. The relation between these data objects are established and defined in detail in relevance to the business model. Process Modeling: The process model for any changes or enhancements to the data object sets is defined in this phase. Process descriptions for adding, deleting, retrieving or modifying a data object are given. Construction focuses mainly on the use of existing software components and the application of automatic code generation. In the last stage Deployment establishes a basis for subsequent iterations if necessary. A business application which can be modularizing in a way that allows each major function to be completed in less than three months is useful for RAD. Each major function can be addressed individually by a separate RAD and then integrated to form a whole application. Programs versus Products Program Program is a sequence of logically related statements that are written to perform a specific task. Programs are developed by single user for their personal use. Programs are small in size and have limited functionality. Author of the program himself uses his program so it is possible that there is not a proper user interface and proper documentation. A program consists of only program code. A program can be developed according to the programmer s individual style of development Software Software is a set of programs, which is designed to perform a well defined function. Software is an application that is designed by one or more software developer. Software products are extremely large and they have multiple users. Software has multiple users and therefore it contains good user interface and good documentation. Software consists of program code with specification document, design document, test document and user s manual. Software product must be developed using the software engineering principles. 15 Dept: CE FSD ( ) Piyush Bhut

16 Unit-2 REQUIREMENTS GATHERING AND ANALYSIS The analyst starts requirement gathering activity by collecting all information that could be useful to develop system. In practice it is very difficult to gather all the necessary information from a large number of people and documents and to form a clear understanding of a problem. Availability of working model helps in gathering the requirement. Studying the existing documentation Interview Task analysis Analyst studies existing documents regarding system to be developed before visiting the customer site. These documents are about the basic purpose, the stakeholders etc. All different categories of users are interviewed to gather different functionalities required by them. For example, to perform the requirements analysis of library automation software, the analyst might interview the library members, the librarian, and the accountants. The users usually view software as a black box that provides a set of service is also called a task. For each identified task, the analyst tries to create the different steps necessary to the service in guidance with the users. For example, for the issue book service, the steps may be: authenticate user, check the number of books issued to the customer and determine if the maximum number of books that this member can borrow has been reached, check whether the book has been reserved, post the book issue details in the member s record, and finally print out a book issue slip that can be presented at the security counter to take out the book. Scenario analysis A task can have many scenarios of operation. The different scenarios of a task can occur when the task is invoked under different situations. For different types of scenarios of a task, the behavior of the system can be different. For example, the different scenarios for the book issue task of a library automation software may be: Book issue service is satisfactorily performed and the book issue slip is printed. The book is reserved and cannot be issued to the member. The maximum number of books that can be issued by the member is exceeded, and the book cannot be issued to the member. REQUIREMENTS ANALYSIS After requirements gathering is completed the analyst analyzes the gathered requirements to clearly understand the exact customer requirements. The main purpose of the requirement analysis activity is to analyze the collected information to obtain a clear understanding of the product to be developed, with a view to removing all ambiguities, incompleteness and inconsistencies. 1 Dept: CE FSD ( ) Piyush Bhut

17 Unit-2 The following basic questions should be clearly understood by the analyst: What is the problem? Why is it important to solve the problem? What are the possible solutions to the problem? What exactly are the data input to the system and what exactly are the data output by the system? What are the complexities that might arise while solving the problem? If there are external software or hardware with which the developed software has to interface, then what exactly would the data interchange formats with the external system be? When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered requirements, he resolves them by carrying out further discussions with the customers. SOFTWARE REQUIREMENTS SPECIFICATION After the analyst has gathered all the required information regarding the software to be developed and has remove all incompleteness, inconsistencies, and anomalies from the specification he starts to systematically organize the requirements in the form of an SRS document. SRS document contains all the user requirements. CHARACTERISTICS OF A GOOD SRS DOCUMENT Correct The important properties of a good SRS document are the following: An SRS is correct if every requirement included in the SRS, required in the final system. Correctness ensures that what is specified is done correctly. Unambiguous Complete Consistent An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language. The SRS is complete if, and only if, it includes the following elements: All requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. Definition of the response of the software in all situations. Note that it is important to specify the response to both valid and invalid input values. A consistent requirement does not conflict with other requirements in the requirement specification. It does not duplicate. Ranked for importance The SRS is ranked for importance if, and only if, has an identifier to indicate the importance of the particular requirement. Typically, all of the requirements that relate to a software product are not 2 Dept: CE FSD ( ) Piyush Bhut

18 Unit-2 Verifiable Modifiable Structured Traceable equally important. Some requirements may be essential, especially, while others may be desirable. Each requirement in the SRS should be identified to make these differences clear and explicit. A requirement is verifiable if, and only if, there exists some process with which a person or machine can check that the software product meets the requirement. The SRS is modifiable if, and only if, its structure and style are such that any changes to the requirement can be made easily, completely, and consistently. The SRS is structured if, and only if, it is moduled, and easy to understand and modify. Over the time customer requirements changes, requirement specification also changes. In order to make modification to SRS it is necessary that SRS should be well structured. A traceable requirement has a unique identity or number. REQUIREMENTS SPECIFICATION TYPES Requirement specification activity is translating the gathered information during the analysis phase into a document that defines a set of requirements. Two types of requirements may be included in this document: 1. Customer Requirement 2. System Requirement System Requirements are further classified into more two types. i. Functional requirements ii. Nonfunctional requirements CUSTOMER (USER) REQUIREMENT Customer requirements are high level abstract statements of the system requirement for the customer and end user of the system. These statements are in a natural language. It describes what services the system is expected to provide to customer and the situation under which it must operate. The customer requirement is quite general and simple. SYSTEM REQUIREMENT System requirements are a more detailed description of the functionality to be provided. It describes what the system should do. The system requirements document should define exactly what is to be implemented. The system requirements provide more specific information about the services and function of the system. 3 Dept: CE FSD ( ) Piyush Bhut

19 Unit-2 Functional Requirements The functional requirements discuss the functionalities expected from the system. These are statements of services that provide how the system should react to particular inputs and how the system should behave in particular situation. It describes the relationship between input and output. It also state what the system should do if any situation occurs. The system is considered to perform a set of high level functions. Each function of the system can be considered as a transformation of set of input data to the corresponding set of output data. The user can get some meaningful pieces of work done using a high level function. Select withdraw cash Display account type options Enter option Prompt for amount to be withdrawn Enter amount Enter amount in multiple of 100 Print receipt Insufficient balance in account Document the functional requirements of a system it is necessary to first learn to identify the high level function of the system. The high level function would be split into smaller sub requirement. A high level function is one using which the user can get some useful piece of work done. For example, the receipt printing work during withdrawal of money from an ATM is called a useful piece of work? Receipt printing should not be considered a high-level requirement, because the user 4 Dept: CE FSD ( ) Piyush Bhut

20 Unit-2 does not specifically request for this activity. The receipt gets printed automatically as part of the withdraw money function. In a library automation software a high level functional requirement might be search-book. This function involves accepting a book name or a set of keywords from the user running a matching algorithm on the book list and finally outputting the matched books. The generated system response can be in several form e.g. display on the terminal, a print out or transferred to the other system. High level function usually involves a series of interactions between the system and one or more users. For example as shown in figure user inputs have been represented by rectangles and the response produced by the system by circles. In figure the different scenarios occur depending on the amount entered for withdrawal. Different behavior for different scenarios of the system for the same high level functions. Nonfunctional requirements Nonfunctional requirements deal with the characteristics of the system which cannot be expressed as functions - such as the maintainability of the system, portability of the system, usability of the system, maximum number of current users etc. Nonfunctional requirements may include: reliability issues accuracy of results Constraints on the system implementation, etc. Example of a non functional requirement can be that the user interface of software should be usable by factory shop floor worker who may not even have a high school degree. DESIGN PROCESS The design process is a sequence of steps that enable the designer to describe all aspects of the software to be built. It describes how the system will be implemented and how it will work. Software design deals with transforming the customer requirements, as described in the SRS document, into appropriate form that is suitable for implementation in a programming language. CLASSIFICATION OF DESIGN ACTIVITIES The activities in the design process vary depending on the type of system being developed. The below figure suggest that the stage of the design process are sequential. Design process can be classified as: Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), and their relationships and how they are distributed. It can be derived from DFD. Interface design, where you define the interfaces between system components. It describes how system communicate itself and with the user. It can be derived from DFD and state transition diagram. Component design, where you take each system component and design how it will operate. This is defined the expected functionality to be implemented. It can be derived from state transition diagram. 5 Dept: CE FSD ( ) Piyush Bhut

21 Unit-2 Database design, where you design the system data structures and how these are to be represented in a database. The data objects and relationships defined in the ER diagram and the detailed data content illustrated in the data dictionary. It can be derived from ER diagram. CLASSIFICATION OF DESIGN METHODOLOGIES A design methodology can be simply defined as a set of design procedure that one follows from the beginning to the completion of the software development process. The nature of the methodology is dependent on a number of factors including type of the software being developed, requirements of the users, qualification and training of software development team, available hardware and software resources. There are fundamentally two different approaches: 1. Function oriented design: it can be further divided in two category I. Structured Analysis II. Structured Design 2. Object oriented design Function oriented design (Top-Down approach) A function oriented design is viewed as something that performs a set of functions. Starting at this high-level view of the system, each function is successively refined into more detailed functions. Each of these sub-functions may be split into more detailed sub-functions and so on. It can be further divided in two categories. Structured Analysis It is used to transform a textual problem description into graphical form. It examines the detail structure of the system. It defines the processes and data flow among these processes. In structured analysis functional requirements specified in SRS are decomposed and analysis of data flow is represented diagrammatically by DFD. Structured Design During Structured design all functions identified during analysis mapped to module structure and that is useful for implementation. The aim of structured design is to transform the results of the structured analysis (i.e. DFD) into a structure chart. The structure chart is tree like diagram a popular way to represent the control hierarchy in a high level design. Object oriented design In the Object oriented design approach the system is viewed as collection of objects (i.e. entities). Object Oriented Design supports following object oriented concepts such as Abstraction, Information Hiding, Functional Independence, and Modularity. Design is the initial step in moving towards from the problem domain to the solution domain. A detailed design includes specification of all the classes with its attributes, detailed interface. The 6 Dept: CE FSD ( ) Piyush Bhut

22 Unit-2 purpose of design is to specify a working solution that can be easily translated into a programming language code. UML modeling and Use Case are used in object oriented designing. COHESION Cohesion means the measure of the strength of function relatedness of elements within a module. Elements include instructions, groups of instructions, data definition, and call of another module. Cohesion means how closely the elements of a module are related to each other. It represents how tightly bound the internal elements of the module are to one another. The classification of cohesion are given beloved: Coincidental cohesion It is the lowest cohesion. A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other very loosely. Means the module contains a random collection of functions. For example, in a transaction processing system (TPS), the get-input, print-error, and summarizemembers functions are grouped into one module. The grouping does not have any relevance to the structure of the problem. Logical cohesion A module is said to be logically cohesive, if all elements of the module perform similar operations. An example of logical cohesion is the case where a set of print functions generating different output reports are arranged into a single module. Temporal cohesion When a module contains functions that are related by the fact that all the functions must be executed in the same time span, the module is said to temporal cohesion. The set of functions for start-up, shutdown of some process, etc. exhibit temporal cohesion. Procedural cohesion A module is said to possess procedural cohesion, if the set of functions of the module are all part of a procedure (algorithm) in which certain sequence of steps have to be carried out for achieving an objective, e.g. the algorithm for decoding a message. Communicational cohesion A module is said to have communicational cohesion, if all functions of the module refer to or update the same data structure, e.g. the set of functions defined on an array or a stack. Sequential cohesion A module is said to possess sequential cohesion, if the elements of a module form the parts of sequence, where the output from one element of the sequence is input to the next. For example, in a TPS, the get-input, validate-input, sort-input functions are grouped into one module. 7 Dept: CE FSD ( ) Piyush Bhut

23 Unit-2 Functional cohesion It is the strongest cohesion. Functional cohesion is said to exist, if all the elements of a module are related to perform a single task. All the elements are achieving a single goal of a module. For example, sort the array are examples of these module. COUPLING Coupling between two modules is a measure of the degree of interdependence or interaction between the two modules. It refers to the strengths of relationship between modules in a system. It indicates how closely two modules interact and how they are independent. As modules become more independent the coupling increases and loose coupling minimize interdependency that is better for any system development. If two modules interchange large amount of data then they are highly interdependent. High coupling between modules make the system difficult to understand and increase the development efforts. So low coupling is the best. Data coupling The classification of cohesion are given beloved: Two modules are data coupled, if they communicate through a parameter. An example is an elementary data item passed as a parameter between two modules, e.g. an integer, a float, a character, etc. It is lowest coupling and best for the software development. Stamp coupling Two modules are stamp coupled, if they communicate using a composite data item such as a record in PASCAL or a structure in C. Control coupling Control coupling exists between two modules, if data from one module is used to direct the order of instructions execution in another. An example of control coupling is a flag set in one module and tested in another module. Common coupling Two modules are common coupled, if they share data through some global data items. Content coupling Content coupling exists between two modules, if they share code. That is a jump from one module into the code of another module can occur. e.g. a branch from one module into another module. 8 Dept: CE FSD ( ) Piyush Bhut

24 Unit-2 DATA MODELING CONCEPTS Data object ER diagram represent a set of real-world entities and the logical relationships among them. This diagram depicts entities, the relationships between them, and the attributes pictorially in order to provide a high-level description of conceptual data models. Once an ER diagram is created, the information represented by it is stored in the database. The information depicted in an ER diagram is independent of the type of database and can later be used to create database of any kind such as relational database, network database, or hierarchical database. ER diagram includes data objects and entities, data attributes, relationships, cardinality and modality. A data object is a real world entity or things. Data object is a representation of composite information used by software. Composite information refers to different features or attributes of a data object and this object can be in any of the following forms: External entity, Event or Place etc. An entity is the data that stores information about the system in a database. Examples of an entity is student, department etc. Data attributes Data attributes describe the properties or characteristics of a data object. Attributes that identify entities are known as key attributes. On the other hand, attributes that describe an entity are known as non-key attributes. Data attribute is used to perform the following functions: Naming an instance of data object, Description of the instance, making reference to another instance in another table. For example, attributes of 'account' entity are 'number', 'balance', and so on. Similarly, attributes of 'user' entity are 'name', 'address', and 'age'. 9 Dept: CE FSD ( ) Piyush Bhut

25 Unit-2 Entities are represented by rectangles, attributes are represented by ellipses, and relationships are represented by diamond symbols. A key attribute is also depicted by an ellipse but with a line below it. Relationships Cardinality Modality Entities are linked to each other in different ways. This link or connection of data objects or entities with each other is known as relationship. Note that there should be at least two entities to establish a relationship between them. Once the entities are identified, the development team checks whether a relationship exists between them. Relationship is represented using diamond shape symbol with joined relationship name. Cardinality specifies the number of occurrences (instances) of one data object or entity that relates to the number of occurrence of another data object or entity. It also specifies the number of entities that are included in a relationship. Different cardinalities are explained below: One-to-one (1:1): Indicates that one instance of an entity is related only to one instance of another entity. For example, in a bank, each user is related to only one account number. One-to-many (1: M): Indicates that one instance of an entity is related to several instances of another entity. For example, one user can have many accounts in different banks. Many-to-many (M: M): Indicates that many instances of entities are related to several instances of another entity. For example, many users can have their accounts in many banks. Modality describes the possibility whether a relationship between two or more entities and data objects is required. The modality of a relationship is 0 if the relationship is optional. However, the modality is 1 if an occurrence of the relationship is essential. For example, Customer entity is related to order entity. Here, cardinality for 'customer' entity indicates that the customer places an order whereas modality for 'customer' entity indicates that it is necessary for a customer to place an order. Cardinality for 'order' indicates that a single user can place many orders whereas modality for 'order' entity indicates that a user can arrive without any 'order'. 10 Dept: CE FSD ( ) Piyush Bhut

26 Unit-2 DATA FLOW DIAGRAM (DFD) The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the different processing activities or functions that the system performs and the data interchange among these functions. Each function is considered as a processing station (or process) that consumes some input data and produces some output data. The system is represented in terms of the input data to the system, various processing carried out on these data, and the output data generated by the system. PRIMITIVE SYMBOLS OF DFD A DFD model uses a very limited number of primitive symbols as shown in figure to represent the functions performed by a system and the data flow among these functions. External entity: The external entities are those physical entities external to the software system which interact with the system by inputting data to the system or by consuming the data produce by the system. External entity is represented by a rectangle. For example librarian, library member. External entity Process Output Data flow Data store Function: A function is represented using a circle. This symbol is called a process or a bubble. Data flow: A directed arc or an arrow is used as a data flow symbol. A data flow represents the data flow occurring between two processes or between an external entity and a process in the direction of the data flow arrow. Data store: A data store is represented using two parallel lines. It represents a logical file. It represents data structure or a physical file on disk. Each data store is connected to a process. The direction of the data flow arrows shows whether data is being read from or written into a data store. Output: The output symbol is as shown in figure. The output symbol is used when a hard copy is produced. DEVELOP DFD MODEL OF SYSTEM A DFD model of a system graphically depicts the transformation of the data input to the system to the final result through a hierarchy of levels. The top level DFD is called the level 0 DFD or the context diagram. A DFD starts with the most abstract definition of the system (lowest level) and at each higher level DFD, more details are successively introduced. To develop a higher-level DFD model, processes are decomposed into their sub-processes and the data flow among these sub-processes is identified. 11 Dept: CE FSD ( ) Piyush Bhut

27 Unit-2 To develop the data flow model of a system, first the most abstract representation of the problem is to be worked out. The most abstract representation of the problem is also called the context diagram. After, developing the context diagram, the higher-level DFDs have to be developed. Context Diagram (Level 0) The context diagram is the most abstract data flow representation of a system. It represents the entire system as a single bubble. This bubble is labeled according to the main function of the system. The various external entities with which the system interacts and the data flow occurring between the system and the external entities are also represented. The data input to the system and the data output from the system are represented as incoming and outgoing arrows. These data flow arrows should be annotated with the corresponding data names. The context diagram is also called as the level 0 DFD. Level 1 12 Dept: CE FSD ( ) Piyush Bhut

28 Unit-2 Include all entities and data stores that are directly connected by data flow to the one process you are breaking down. Show all other data stores that are shared by the processes in this breakdown. Decomposition at further level 1 DFD have processes with label 1.0, 2.0, 3.0, and so on. Shortcoming (Disadvantage) of DFD Model DFDs for large system can be become complex, difficult to understand and time consuming. Data flow can become confusing to programmer if it is not well defined. DFD does not specify exactly in which order processes are executed. There are multiple possible ways to execute processes. So several alternate presentations can be possible. In DFD which inputs are consumed and which outputs are produced are not specified. DFD does not provide clear view about decomposition of any process to its sub-process. SCENARIO BASED MODELING UNIFIED MODELING LANGUAGE (UML) UML, as the name implies, is a modeling language. It provides a set of notations (e.g. rectangles, lines, ellipses) to create a visual model of the system. UML has its own syntax (symbols and sentence formation rules) and semantics (meanings of symbols and sentences). WRITING USE CASES While developing software, it is essential for the development team to consider user satisfaction as a top priority to make the software successful. For this, the development team needs to understand how users will interact with the system. This information helps the team to carefully identify each user requirements and then create a meaningful and relevant analysis model and design model. For this, the software engineer creates scenarios in the form of use-cases to describe the system from the users' view. Use cases describe the tasks in which the users will use the software under a specific set of conditions. Each use-case provides one or more scenarios in order to understand how a system should interact with another system. Use cases do not provide descriptions about the implementation of software. Use-cases are represented with the help of a use-case diagram, which indicate the relationships among actors and use cases within a system. A use-case diagram describes what exists outside the system (actors) and what should be performed by the system (use-cases). The notations used to represent a use-case diagram are listed in Table. Name Actor Use-case Communication link Use link Description Actors are different kinds of users who use the system in various ways. For example, one actor can be a library user whereas another user can be part of the library staff. Describes a specific instance of a system function. Indicates the interaction between the actor and the system. Indicates that one of the use-case uses the behavior described by another use-case. 13 Dept: CE FSD ( ) Piyush Bhut

29 Unit-2 Customer (actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and transfer funds (use cases). ATM Technician provides maintenance and repairs. All these use cases also involve Bank actor whether it is related to customer transactions or to the ATM servicing. Generalization Use case generalization can be used when one use case that is similar to another, but does something slightly differently or something more. The child use case inherits the behavior and meaning of the parent use case. The notation for generalization is as shown in figure. Pay membership fee Pay through credit card Pay through library pay card Includes The includes relationship involves one use case including the behavior of another use case. The includes relationship occurs when a part of behavior that is similar across a number of use cases. 14 Dept: CE FSD ( ) Piyush Bhut

30 Unit-2 The factoring of such behavior will help in not repeating the specification and implementation across different use cases. It is represented using a predefined stereotype <<include>>. Deposit Funds Withdraw cash <<include>> <<include>> Customer Authentication ACTIVITY DIAGRAM An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation. Basic Activity Diagram Symbols and Notations Action states Action states represent the actions of objects. You can draw an action state using a rectangle with rounded corners. Action Flow Action flow arrows illustrate the relationships among action states. Initial State A filled circle followed by an arrow represents the initial action state. Final State An arrow pointing to a filled circle nested inside another circle represents the final action state. 15 Dept: CE FSD ( ) Piyush Bhut

31 Unit-2 16 Dept: CE FSD ( ) Piyush Bhut

32 Unit-2 Branching A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with a condition or guard expression. You can also label one of the paths "else." For example, activity diagram of ATM machine Synchronization A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and joining. Swimlanes Swimlanes group related activities into one column. 17 Dept: CE FSD ( ) Piyush Bhut

33 Unit-2 ARCHITECTURAL DESIGN DECISIONS Design and implementation Software design and implementation is the stage in the software engineering process at which an executable software system is developed. Software design is a creative activity in which you identify software components and their relationships, based on a customer s requirements. Implementation is the process of realizing the design as a program. Software Architecture The design process for identifying the sub-systems making up a system and the framework for subsystem control and communication is architectural design. The output of this design process is a description of the software architecture. Architectural design decisions Architectural design is a creative process so the process differs depending on the type of system being developed. However, a number of common decisions span all design processes and these decisions affect the nonfunctional characteristics of the system. Is there a generic application architecture that can be used? How will the system be distributed? What architectural styles are appropriate? What approach will be used to structure the system? How will the system be decomposed into modules? How should the architecture be documented? ARCHITECTURAL VIEWS What views or look are useful when designing and documenting a system s architecture? What notations should be used for describing architectural models? Each architectural model only shows one view or look of the system. It might show how a system is decomposed into modules, how the run-time processes interact or the different ways in which system components are distributed across a network. For both design and documentation, you usually need to present multiple views of the software architecture view model of software architecture 1. A logical view, which shows the key concepts of the system as objects and classes. 2. A process view, which shows how, at run-time, the system, is composed of interacting processes. 3. A development view, which shows how the software is decomposed for development. Means it shows the breakdown of software into modules. 4. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. 18 Dept: CE FSD ( ) Piyush Bhut

34 Unit-2 ARCHITECTURAL PATTERNS Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. Patterns should include information about when they are and when they are not useful. MVC (Model-View-Controller) Pattern The system is structured into three logical components that interact with each other. The Model component manages the system data and associated operations on that data. The View component manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. Used when there are multiple ways to view and interact with data. Allows the data to change independently of its representation and vice versa. Layered architecture Pattern Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system. 19 Dept: CE FSD ( ) Piyush Bhut

35 Unit-2 Client-server In client server architecture, the functionality of the system is organized into services, with each service delivered from a separate server. Clients are users of these services and access servers to make use of them. Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable. The principal advantage of this model is that servers can be distributed across a network. General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services. APPLICATION ARCHITECTURES Software application architecture is the process of defining a structured solution that meets all the technical and operational requirements. Application architecture is the organizational design of an entire software application including all sub component and external applications. Application architecture helps us to understand the operations of the system. It describes the layout of application s deployment. Use of application architectures As a starting point for architectural design. As a way of organizing the work of the development team. As a means of assessing components for reuse. As a vocabulary for talking about application types. 20 Dept: CE FSD ( ) Piyush Bhut

36 Unit-3 RESPONSIBILITY OF SOFTWARE PROJECT MANAGER Job responsibility Software project managers take the overall responsibility of project to success. The job responsibility of a project manager ranges from invisible activities like building up team morale to highly visible customer presentations. Most managers take responsibility for project proposal writing, project cost estimation, scheduling, project staffing, deciding software process, project monitoring and control, software configuration management, risk management, interfacing with clients, and presentations. These activities can be classified into project planning, and project monitoring and control activities. Project planning Project planning involves estimating characteristics of the project and then planning the project activities based on the estimates made. The project planning activity is undertaken after the feasibility study phase. The initial project plans that are made are revised from time to time as the project progresses and more project data become available. Project monitoring and control activities The project monitoring and control activities are undertaken once the development activities start with the aim of ensuring that the development proceeds as per plan and changing the plan whenever required. Skills necessary for software project management A theoretical knowledge of different project management techniques is certainly necessary to become a successful project manager. In addition to having a good understand of the latest software project management techniques such as cost estimation, risk management, configuration management, project managers need good communication skills. However, some skills such as tracking and controlling the progress of the project, customer interaction, managerial presentations, and team building are largely acquired through experience. METRICS FOR SOFTWARE PROJECT SIZE ESTIMATION Estimation of the problem size is estimation of effort, time duration and cost of a software project. The size of a problem is obviously not the number of bytes that the source code occupies. It is neither the byte size of the executable code. Currently two metrics are popularly being used widely to estimate size: Lines of code (LOC) Function point (FP) LINES OF CODE (LOC) LOC metric is very popular because it is the simplest to use. Using this metric, the project size is estimated by counting the number of source instructions in the developed program. Lines used for commenting the code and the header lines should be ignored. 1 Dept: CE FSD ( ) Piyush Bhut

37 Unit-3 Determining the LOC count at the end of a project is a very simple job. To estimate the LOC count at the beginning of a project, project managers usually divide the problem into modules and each module into sub modules and so on, until the sizes of the different leaf-level modules can be approximately predicted. Shortcomings (or Disadvantages) of Lines of Code (LOC) metric LOC gives a numerical value of problem size that can vary with individual coding style different programmers lay out their code in different ways. For example, one programmer might write several source instructions on a single line whereas another might split a single instruction across several lines. Of course, this problem can be easily overcome by counting the language tokens in the program rather than the lines of code. However, a more difficult problem arises because the length of a program depends on the choice of instructions used in writing the program. Therefore, even for the same problem, different programmers might come up with programs having different LOC counts. A good problem size measure should consider the overall complexity of the problem and the effort needed to solve it. That is, it should consider the effort needed to specify, design, code, test, etc. and not just the coding effort. LOC focuses on the coding activity alone; it only computes the number of source lines in final program. Larger code size does not necessarily imply better quality. Some programmers produce lengthy and complicated code as they do not make effective use of the available instruction set. If a programmer uses several library routines, then the LOC count will be lower. This would show up as smaller program size. It is very difficult to accurately estimate LOC in the final product from the problem specification. The LOC count can be accurately computed only after the code has been fully developed. Therefore, the LOC metric is little use to the project managers during project planning, since project planning is carried out even before any development activity has started. This is the biggest shortcoming of the LOC metric. FUNCTION POINT (FP) Function Point metric overcomes many of the shortcomings of the LOC metric. One of the important advantages of using the function point metric is that it can be used to easily estimate the size of a software product directly from the problem specification. LOC metric, where the size can be accurately determined only after the product has fully been developed. The conceptual idea behind the function point metric is that the size of a software product is directly dependent on the number of different functions or features it supports. A software product supporting many features would certainly be of larger size than a product with less number of features. Each function when invoked reads some input data and transforms it to the corresponding output data. For example, the issue book feature (as shown in figure.) of a Library Automation Software takes the name of the book as input and displays its location and the number of copies available. 2 Dept: CE FSD ( ) Piyush Bhut

38 Unit-3 The size of a product in function points (FP) can be expressed as the weighted sum of these five problem characteristics. The weights associated with the five characteristics were proposed empirically and validated by the observations over many projects. Function point is computed in two steps. The first step is to compute the unadjusted function point (UFP). UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number of files)*10 + (Number of interfaces)*10 Number of inputs Each data item input by the user is counted. It must be noted that individual data items input by the user are not considered in the calculation of the number of inputs, but a group of related inputs are considered as a single input. For example, while entering the data concerning employee to pay roll software; the data items name, age, address, phone number, etc. are together considered as a single input. All these data items can be considered to be related, since they count as to a single employee. Number of outputs The outputs considered refer to reports printed, screen outputs, error messages produced, etc. While outputting the number of outputs the individual data items within a report are not considered, but a set of related data items is counted as one input. Number of inquiries Inquiries are user commands such as print-account-balance. Inquiries are counted separately. Number of files Each logical file is counted. A logical file means groups of logically related data. Number of interfaces Here the interfaces considered are the interfaces used to exchange information with other systems. Examples of such interfaces are communication links with other systems etc. Once the unadjusted function point (UFP) is computed, the technical complexity factor (TCF) is computed next. TCF refines the UFP measure by considering 14 other factors such as high transaction rates, throughput, and response time requirements, etc. 3 Dept: CE FSD ( ) Piyush Bhut

39 Unit-3 Each of these 14 factors is assigned from 0 (not present) to 6 (strong influence). The resulting numbers are summed, gives the total degree of influence (DI). Now, TCF = ( *DI). As DI can vary from 0 to 70, TCF can vary from 0.65 to Finally, FP=UFP*TCF. PROJECT ESTIMATION TECHNIQUES Estimation of various project parameters is a basic project planning activity. The important project parameters that are estimated include: project size, effort required to develop the software, project duration, and cost. These estimates not only help in deciding the project cost to the customer, but are also useful in resource planning and scheduling. There are three broad categories of estimation techniques: Empirical estimation techniques Heuristic techniques Analytical estimation techniques EMPIRICAL ESTIMATION TECHNIQUES Empirical estimation techniques are based on making an educated guess of the project parameters. While using this technique, prior experience with development of similar products is helpful. Although empirical estimation techniques are based on common sense. Two popular techniques are: Expert judgment technique and Delphi cost estimation. Expert Judgment Technique Expert judgment is one of the most widely used estimation techniques. In this approach, an expert makes an educated guess of the problem size after analyzing the problem. Usually, the expert estimates the cost of the different components (i.e. modules or subsystems) of the system and then combines them to compute the overall estimate. However, this technique is subject to human errors and individual partiality. Also, it is possible that the expert may not know some factors. Further, an expert making an estimate may not have experience and knowledge of all aspects of a project. For example, he knows the database and user interface parts but may not be very knowledgeable about the computer communication part. A more refined form of expert judgment is the estimation made by group of experts. Estimation by a group of experts minimizes factors such as individual oversight, lack of familiarity with a particular aspect of a project, personal partiality. Delphi cost estimation Delphi cost estimation approach tries to overcome some of the shortcomings of the expert judgment approach. Delphi estimation is carried out by a team of a group of experts and a coordinator. In this approach, the coordinator provides each estimator with a copy of the software requirements specification (SRS) document and a form for recording his cost estimate. 4 Dept: CE FSD ( ) Piyush Bhut

40 Unit-3 Estimators complete their individual estimates and submit to the coordinator. In their estimates, the estimators mention any unusual characteristic of the product which has influenced his estimation. The coordinator prepares and distributes the summary of the responses of all the estimators, and includes any unusual noted by any of the estimators. Based on this summary, the estimators re-estimate. This process is iterated for several rounds. However, no discussion among the estimators is allowed during the entire estimation process. After the completion of several iterations of estimations, the coordinator takes the responsibility of combining the results and preparing the final estimate. HEURISTIC TECHNIQUE COCOMO Heuristic techniques assume that the relationships among the different project parameters can be modeled using suitable mathematical expressions. Once the basic (independent) parameters are known, the other (dependent) parameters can be easily determined by substituting the value of the basic parameters in the mathematical expression. COCOMO (Constructive Cost Estimation Model) was proposed by Boehm (1981). According to the Boehm any software development project can be classified into one of the following three categories based on the development complexity: organic, semidetached, and embedded. Organic: A development project can be considered of organic type, if the project deals with developing a well understood application program, the size of the development team is small, and the team members are experienced in developing similar types of projects. Semidetached: A development project can be considered of semidetached type, if the development consists of a mixture of experienced and inexperienced staff. Embedded: A development project is considered to be of embedded type, if the software being developed is strongly coupled to complex hardware. According to Boehm, software cost estimation should be done through three stages: Basic COCOMO, Intermediate COCOMO, and Complete COCOMO. Basic COCOMO Model The basic COCOMO model gives an approximate estimate of the project parameters. The basic COCOMO estimation model is given by the following expressions: Effort = a1 (KLOC) a2 PM Tdev = b1 (Effort) b2 Months Where KLOC is the estimated size of the software product expressed in Kilo Lines of Code a1, a2, b1, b2 are constants for each category of software products Tdev is the estimated time to develop the software, expressed in months Effort is the total effort required to develop the software product, expressed in person months (PMs) According to Boehm, every line of source text should be calculated LOC. 5 Dept: CE FSD ( ) Piyush Bhut

41 Unit-3 The values of a1, a2, b1, b2 for different categories of products (i.e. organic, semidetached, and embedded) as given by Boehm [1981] are summarized below. He derived the above expressions by examining historical data collected from a large number of actual projects. Estimation of development effort: For the three classes of software products, the formulas for estimating the effort based on the code size are shown below: Organic : Effort = 2.4(KLOC) 1.05 PM Semi-detached : Effort = 3.0(KLOC) 1.12 PM Embedded : Effort = 3.6(KLOC) 1.2 PM Estimation of development time: For the three classes of software products, the formulas for estimating the development time based on the effort are given below: Organic : Tdev = 2.5(Effort) 0.38 Months Semi-detached : Tdev = 2.5(Effort) 0.35 Months Embedded : Tdev = 2.5(Effort) 0.32 Months From the effort estimation, the project cost can be obtained by multiplying the required effort by the manpower cost per month. Example: Assume that the size of an organic type software product has been estimated to be 32,000 lines of source code. Assume that the average salary of software engineers be Rs. 15,000/- per month. Determine the effort required to develop the software product and the nominal development time. From the basic COCOMO estimation formula for organic software: Effort = 2.4 х (32) 1.05 = 91 PM Development time = 2.5 х (91) 0.38 = 14 months Cost required to develop the product = 91 х = Rs /- Intermediate COCOMO model Basic COCOMO model assumes that effort and development time are functions of the product size. Therefore, in order to obtain an accurate estimation of the effort and project duration, the effect of all relevant parameters must be taken into account. The intermediate COCOMO model recognizes this fact and refines the initial estimate obtained using the basic COCOMO expressions by using a set of 15 cost drivers (multipliers) based on various attributes of software development. For example, if modern programming practices are used, the initial estimates are scaled downward. If there are reliability requirements on the software product, this initial estimate is scaled upward. In general, the cost drivers can be classified as being attributes of the following items: Product: The characteristics of the product like reliability requirements of the product. Computer: Characteristics of the computer like execution speed required, storage space required etc. Personnel: experience level of personnel, programming capability, analysis capability, etc. Development Environment: use of the automation (CASE) tools used for software development. 6 Dept: CE FSD ( ) Piyush Bhut

42 Unit-3 Complete COCOMO model A major shortcoming of both the basic and intermediate COCOMO models is that they consider a software product as a single entity. However, most large systems are made up several smaller sub-systems. These subsystems may have widely different characteristics. For example, some subsystems may be considered as organic type, some semidetached, and some embedded. Not only that the development complexity of the subsystems may be different, but also for some subsystems the reliability requirements may be high, for some the development team might have no previous experience of similar development, and so on. The complete COCOMO model considers these differences in characteristics of the subsystems and estimates the effort and development time as the sum of the estimates for the individual subsystems. The following development project can be considered as an example of application of the complete COCOMO model. A distributed Management Information System (MIS) product for an organization having offices at several places across the country can have the following sub-components: Database part Graphical User Interface (GUI) part Communication part Of these, the communication part can be considered as embedded software. The database part could be semi-detached software, and the GUI part organic software. The costs for these three components can be estimated separately, and summed up to give the overall cost of the system. ANALYTICAL ESTIMATION TECHNIQUES Analytical estimation techniques derive the required results starting with basic assumptions regarding the project. Analytical techniques do have scientific basis. Halstead s software science is an example of an analytical technique. Halstead s software science is an analytical technique to measure size, development effort, and development cost of software products. Halstead used primitive program parameters to develop the expressions for overall program length, volume, effort, and development time. So for predicting software estimation it performs both empirical and heuristic techniques. For a given program, you need to calculate: Length: The length of a program as defined by total usage of all operators and operands. Vocabulary: The program vocabulary is the number of unique operators and operands. Program Volume: The program volume is the total number of operators and operands. Difficulty: The difficulty metric indicates how difficult a program is to write or understand. Effort: The effort required to develop a program can be obtained by E = Difficulty * Volume. PROJECT SCHEDULING Project scheduling is an important project planning activity. It involves deciding which tasks would be taken up when. To schedule the activities, a software project manager needs to do the following: 7 Dept: CE FSD ( ) Piyush Bhut

43 Unit-3 Identify all the tasks needed to complete the project. Break down large tasks into small activities. Determine the dependency among different activities. Estimates for the time durations necessary to complete the activities. Allocate resources to activities. Plan the starting and ending dates for various activities. The first step in scheduling a software project involves identifying all the tasks necessary to complete the project. A good knowledge of the project and the development process helps the managers to effectively identify the important tasks of the project. Next, large tasks are broken down into a logical set of small activities which would be assigned to different engineers. The work breakdown structure helps the manager to breakdown the tasks. After the project manager has broken down the tasks and created the work breakdown structure, he/she has to find the dependency among the activities. Dependency among the different activities determines the order in which the different activities would be carried out. If an activity A requires the results of another activity B, then activity A must be scheduled after activity B. In general, the task dependencies define a partial ordering among tasks, i.e. each task may precede a subset of other tasks, but some tasks might not have any precedence ordering defined between them. The dependencies among the activities are represented in the form of an activity network. Once the activity network representation has been worked out, resources are allocated to each activity. Resource allocation is typically done using a Gantt chart. The PERT chart representation is suitable for program monitoring and control. For task scheduling, the project manager needs to decompose the project tasks into a set of activities. The time frame when each activity is to be performed is to be determined. The end of each activity is called milestone. The project manager tracks the progress of a project by monitoring the timely completion of the milestones. If he observes that the milestones start getting delayed, then he has to carefully control the activities, so that the overall deadline can still be met. Work breakdown structure Work Breakdown Structure (WBS) is used to decompose a given task set recursively into small activities. WBS provides a notation for representing the major tasks need to be carried out in order to solve a problem. The root of the tree is labeled by the problem name. Each node of the tree is broken down into smaller activities that are made the children of the node. Each activity is recursively decomposed into smaller sub-activities until at the leaf level, the activities requires approximately two weeks developing. Figure represents the WBS of MIS (Management Information System) software. While breaking down a task into smaller tasks, the manager has to make some hard decisions. To complete a project in the time, the manager needs to break large tasks into smaller ones. However, it is not useful to subdivide tasks into units which take less than a week. 8 Dept: CE FSD ( ) Piyush Bhut

44 Unit-3 Activity networks and critical path method WBS representation of a project is transformed into an activity network by representing activities identified in WBS along with their interdependencies. An activity network shows the different activities making up a project, their estimated durations, and interdependencies (as shown in figure). Each activity is represented by a rectangular node and the duration of the activity is shown alongside each task. Managers can estimate the time durations for the different tasks in several ways. One possibility is that they can assign durations to different tasks. A possible alternative is to let engineer himself estimate the time for an activity he can assigned to. However, some managers prefer to estimate the time for various activities themselves. Many managers believe that good schedule motivates the engineers to do a better and faster job. However, if not careful schedule then it cause for schedule delays. Design database 45 Code database part 105 Specification 15 Design GUI part 30 Code GUI part 45 Integrated and test 120 Finish 0 Write user manual 60 9 Dept: CE FSD ( ) Piyush Bhut