VIDYAVAHINI FIRST GRADE COLLEGE

Save this PDF as:
Size: px
Start display at page:

Download "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 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

Project Planning and Project Estimation Techniques. Naveen Aggarwal

Project Planning and Project Estimation Techniques. Naveen Aggarwal Project Planning and Project Estimation Techniques Naveen Aggarwal Responsibilities of a software project manager The job responsibility of a project manager ranges from invisible activities like building

More information

Module 11. Software Project Planning. Version 2 CSE IIT, Kharagpur

Module 11. Software Project Planning. Version 2 CSE IIT, Kharagpur Module 11 Software Project Planning Lesson 29 Staffing Level Estimation and Scheduling Specific Instructional Objectives At the end of this lesson the student would be able to: Identify why careful planning

More information

Project Plan 1.0 Airline Reservation System

Project Plan 1.0 Airline Reservation System 1.0 Airline Reservation System Submitted in partial fulfillment of the requirements of the degree of Master of Software Engineering Kaavya Kuppa CIS 895 MSE Project Department of Computing and Information

More information

SOFTWARE ENGINEERING INTERVIEW QUESTIONS

SOFTWARE ENGINEERING INTERVIEW QUESTIONS SOFTWARE ENGINEERING INTERVIEW QUESTIONS http://www.tutorialspoint.com/software_engineering/software_engineering_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Software Engineering

More information

CSC 342 Semester I: 1425-1426H (2004-2005 G)

CSC 342 Semester I: 1425-1426H (2004-2005 G) CSC 342 Semester I: 1425-1426H (2004-2005 G) Software Engineering Systems Analysis: Requirements Structuring Context & DFDs. Instructor: Dr. Ghazy Assassa Software Engineering CSC 342/Dr. Ghazy Assassa

More information

Contents. Today Project Management. Project Management. Last Time - Software Development Processes. What is Project Management?

Contents. Today Project Management. Project Management. Last Time - Software Development Processes. What is Project Management? Contents Introduction Software Development Processes Project Management Requirements Engineering Software Construction Group processes Quality Assurance Software Management and Evolution Last Time - Software

More information

SoftwareCostEstimation. Spring,2012

SoftwareCostEstimation. Spring,2012 SoftwareCostEstimation Spring,2012 Chapter 3 SOFTWARE COST ESTIMATION DB Liu Software Cost Estimation INTRODUCTION Estimating the cost of a software product is one of the most difficult and error-prone

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 The purpose of these questions is to establish that the students understand the basic ideas that underpin the course. The answers

More information

Software cost estimation. Predicting the resources required for a software development process

Software cost estimation. Predicting the resources required for a software development process Software cost estimation Predicting the resources required for a software development process Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1 Objectives To introduce the fundamentals

More information

Project Plan. Online Book Store. Version 1.0. Vamsi Krishna Mummaneni. CIS 895 MSE Project KSU. Major Professor. Dr.Torben Amtoft

Project Plan. Online Book Store. Version 1.0. Vamsi Krishna Mummaneni. CIS 895 MSE Project KSU. Major Professor. Dr.Torben Amtoft Online Book Store Version 1.0 Vamsi Krishna Mummaneni CIS 895 MSE Project KSU Major Professor Dr.Torben Amtoft 1 Table of Contents 1. Task Breakdown 3 1.1. Inception Phase 3 1.2. Elaboration Phase 3 1.3.

More information

Software Requirements Specification

Software Requirements Specification 1 of 7 17.04.98 13:32 Software Requirements Specification The sub-sections : 1. What is a Software Requirements Specification 2. Why is a Software Requirement Specification Required 3. What is Contained

More information

Software Engineering Question Bank

Software Engineering Question Bank Software Engineering Question Bank 1) What is Software Development Life Cycle? (SDLC) System Development Life Cycle (SDLC) is the overall process of developing information systems through a multi-step

More information

Software Engineering. Objectives. Designing, building and maintaining large software systems

Software Engineering. Objectives. Designing, building and maintaining large software systems Software Engineering Objectives Designing, building and maintaining large software systems To define software engineering and explain its importance To discuss the concepts of software products and software

More information

Software cost estimation

Software cost estimation Software cost estimation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 26 Slide 1 Objectives To introduce the fundamentals of software costing and pricing To describe three metrics for

More information

MTAT.03.244 Software Economics. Lecture 5: Software Cost Estimation

MTAT.03.244 Software Economics. Lecture 5: Software Cost Estimation MTAT.03.244 Software Economics Lecture 5: Software Cost Estimation Marlon Dumas marlon.dumas ät ut. ee Outline Estimating Software Size Estimating Effort Estimating Duration 2 For Discussion It is hopeless

More information

Chapter 23 Software Cost Estimation

Chapter 23 Software Cost Estimation Chapter 23 Software Cost Estimation Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1 Software cost estimation Predicting the resources required for a software development process

More information

E-COCOMO: The Extended COst Constructive MOdel for Cleanroom Software Engineering

E-COCOMO: The Extended COst Constructive MOdel for Cleanroom Software Engineering Database Systems Journal vol. IV, no. 4/2013 3 E-COCOMO: The Extended COst Constructive MOdel for Cleanroom Software Engineering Hitesh KUMAR SHARMA University of Petroleum and Energy Studies, India hkshitesh@gmail.com

More information

(Refer Slide Time 00:56)

(Refer Slide Time 00:56) Software Engineering Prof.N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-12 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue

More information

Introduction and Overview

Introduction and Overview Introduction and Overview Definitions. The general design process. A context for design: the waterfall model; reviews and documents. Some size factors. Quality and productivity factors. Material from:

More information

Software Engineering. What is a system?

Software Engineering. What is a system? What is a system? Software Engineering Software Processes A purposeful collection of inter-related components working together to achieve some common objective. A system may include software, mechanical,

More information

Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e.

Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e. Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e., a representation of information as a continuous flow that

More information

(Refer Slide Time: 01:52)

(Refer Slide Time: 01:52) Software Engineering Prof. N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture - 2 Introduction to Software Engineering Challenges, Process Models etc (Part 2) This

More information

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University

Software Engineering Introduction & Background. Complaints. General Problems. Department of Computer Science Kent State University Software Engineering Introduction & Background Department of Computer Science Kent State University Complaints Software production is often done by amateurs Software development is done by tinkering or

More information

IF2261 Software Engineering. Introduction. What is software? What is software? What is software? Failure Curve. Software Applications Type

IF2261 Software Engineering. Introduction. What is software? What is software? What is software? Failure Curve. Software Applications Type IF2261 Software Engineering Introduction Program Studi Teknik Informatika STEI ITB What is software? Definitions: Computer programs, procedures, and possibly associated documentation and data pertaining

More information

Software cost estimation

Software cost estimation Software cost estimation Sommerville Chapter 26 Objectives To introduce the fundamentals of software costing and pricing To describe three metrics for software productivity assessment To explain why different

More information

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur Module 2 Software Life Cycle Model Lesson 3 Basics of Software Life Cycle and Waterfall Model Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what is a

More information

Peter Mileff PhD SOFTWARE ENGINEERING. The Basics of Software Engineering. University of Miskolc Department of Information Technology

Peter Mileff PhD SOFTWARE ENGINEERING. The Basics of Software Engineering. University of Miskolc Department of Information Technology Peter Mileff PhD SOFTWARE ENGINEERING The Basics of Software Engineering University of Miskolc Department of Information Technology Introduction Péter Mileff - Department of Information Engineering Room

More information

And the Models Are 16-03-2015. System/Software Development Life Cycle. Why Life Cycle Approach for Software?

And the Models Are 16-03-2015. System/Software Development Life Cycle. Why Life Cycle Approach for Software? System/Software Development Life Cycle Anurag Srivastava Associate Professor ABV-IIITM, Gwalior Why Life Cycle Approach for Software? Life cycle is a sequence of events or patterns that are displayed in

More information

Chapter 13: Program Development and Programming Languages

Chapter 13: Program Development and Programming Languages Understanding Computers Today and Tomorrow 12 th Edition Chapter 13: Program Development and Programming Languages Learning Objectives Understand the differences between structured programming, object-oriented

More information

Introduction to Software Paradigms & Procedural Programming Paradigm

Introduction to Software Paradigms & Procedural Programming Paradigm Introduction & Procedural Programming Sample Courseware Introduction to Software Paradigms & Procedural Programming Paradigm This Lesson introduces main terminology to be used in the whole course. Thus,

More information

2. Analysis, Design and Implementation

2. Analysis, Design and Implementation 2. Subject/Topic/Focus: Software Production Process Summary: Software Crisis Software as a Product: From Individual Programs to Complete Application Systems Software Development: Goals, Tasks, Actors,

More information

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software...

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software... 1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand

More information

ICS 121 Lecture Notes Spring Quarter 96

ICS 121 Lecture Notes Spring Quarter 96 Software Management Cost Estimation Managing People Management Poor managment is the downfall of many software projects Ð Delivered software was late, unreliable, cost several times the original estimates

More information

Various Software Development Life Cycle Models

Various Software Development Life Cycle Models Various Software Development Life Cycle Models Sahil Jindal, Puneet Gulati, Praveen Rohilla Dronacharya College of Engineering, India Abstract:An SDLC model is a conceptual framework describing different

More information

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur

Module 2. Software Life Cycle Model. Version 2 CSE IIT, Kharagpur Module 2 Software Life Cycle Model Lesson 4 Prototyping and Spiral Life Cycle Models Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what a prototype is.

More information

Cost Estimation Strategies COST ESTIMATION GUIDELINES

Cost Estimation Strategies COST ESTIMATION GUIDELINES Cost Estimation Strategies Algorithmic models (Rayleigh curve Cost in week t = K a t exp(-a t 2 ) Expert judgment (9 step model presented later) Analogy (Use similar systems) Parkinson (Work expands to

More information

2. Analysis, Design and Implementation

2. Analysis, Design and Implementation 2. Analysis, Design and Implementation Subject/Topic/Focus: Software Production Process Summary: Software Crisis Software as a Product: From Programs to Application Systems Products Software Development:

More information

Introduction to Software Engineering. Adopted from Software Engineering, by Ian Sommerville

Introduction to Software Engineering. Adopted from Software Engineering, by Ian Sommerville Introduction to Software Engineering Adopted from Software Engineering, by Ian Sommerville To discuss the factors that led to software failures and the phenomenon of the Software Crisis ; To introduce

More information

A. Waterfall Model - Requirement Analysis. System & Software Design. Implementation & Unit Testing. Integration & System Testing.

A. Waterfall Model - Requirement Analysis. System & Software Design. Implementation & Unit Testing. Integration & System Testing. Processing Models Of SDLC Mrs. Nalkar Sanjivani Baban Asst. Professor, IT/CS Dept, JVM s Mehta College,Sector 19, Airoli, Navi Mumbai-400708 Nalkar_sanjivani@yahoo.co.in Abstract This paper presents an

More information

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0 NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

Software Development Life Cycle

Software Development Life Cycle 4 Software Development Life Cycle M MAJOR A J O R T TOPICSO P I C S Objectives... 52 Pre-Test Questions... 52 Introduction... 53 Software Development Life Cycle Model... 53 Waterfall Life Cycle Model...

More information

Karunya University Dept. of Information Technology

Karunya University Dept. of Information Technology PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main

More information

Introduction. Getting started with software engineering. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1

Introduction. Getting started with software engineering. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Introduction Getting started with software engineering Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 1 Objectives To introduce software engineering and to explain its importance

More information

Fourth generation techniques (4GT)

Fourth generation techniques (4GT) Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some

More information

SOFTWARE REQUIREMENTS

SOFTWARE REQUIREMENTS SOFTWARE REQUIREMENTS http://www.tutorialspoint.com/software_engineering/software_requirements.htm Copyright tutorialspoint.com The software requirements are description of features and functionalities

More information

Software Engineering. What is SE, Anyway? Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. What is SE, Anyway? Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering What is SE, Anyway? Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software engineering and to explain its importance To set out the answers

More information

An Introduction to Software Engineering

An Introduction to Software Engineering An Introduction to Software Engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Objectives To introduce software engineering and to explain its importance To set out the

More information

An Introduction to Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

An Introduction to Software Engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 An Introduction to Software Engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1 Objectives To introduce software engineering and to explain its importance To set out the

More information

Software testing. Objectives

Software testing. Objectives Software testing cmsc435-1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating

More information

CS6403-SOFTWARE ENGINEERING UNIT-I PART-A

CS6403-SOFTWARE ENGINEERING UNIT-I PART-A Handled By, VALLIAMMAI ENGINEERING COLLEGE SRM Nagar, Kattankulathur-603203. Department of Information Technology Question Bank- Even Semester 2014-2015 IV Semester CS6403-SOFTWARE ENGINEERING MS.R.Thenmozhi,

More information

SOFTWARE PROJECT MANAGEMENT

SOFTWARE PROJECT MANAGEMENT SOFTWARE PROJECT MANAGEMENT http://www.tutorialspoint.com/software_engineering/software_project_management.htm Copyright tutorialspoint.com The job pattern of an IT company engaged in software development

More information

Subject : System Analysis and Design BCA -II UNIT 1

Subject : System Analysis and Design BCA -II UNIT 1 Subject : System Analysis and Design BCA -II UNIT 1 Ques1 what is system design.explain its types. Ans: SYSTEM DESIGN :Systems design is the process or art of defining the architecture, components, modules,

More information

COURSE CODE : 4072 COURSE CATEGORY : A PERIODS / WEEK : 4 PERIODS / SEMESTER : 72 CREDITS : 4

COURSE CODE : 4072 COURSE CATEGORY : A PERIODS / WEEK : 4 PERIODS / SEMESTER : 72 CREDITS : 4 COURSE TITLE : SOFTWARE ENGINEERING COURSE CODE : 4072 COURSE CATEGORY : A PERIODS / WEEK : 4 PERIODS / SEMESTER : 72 CREDITS : 4 TIME SCHEDULE MODULE TOPICS PERIODS 1 Software engineering discipline evolution

More information

Comparison of SDLC-2013 Model with Other SDLC Models by Using COCOMO

Comparison of SDLC-2013 Model with Other SDLC Models by Using COCOMO International Journal of Emerging Science and Engineering (IJESE) Comparison of SDLC-2013 Model with Other SDLC Models by Using COCOMO Naresh Kumar, Pinky Chandwal Abstract There exist a large number of

More information

Process Models and Metrics

Process Models and Metrics Process Models and Metrics PROCESS MODELS AND METRICS These models and metrics capture information about the processes being performed We can model and measure the definition of the process process performers

More information

Software Engineering

Software Engineering Software Engineering Lecture 06: Design an Overview Peter Thiemann University of Freiburg, Germany SS 2013 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 1 / 35 The Design Phase Programming in

More information

CMSC 435: Software Engineering Course overview. Topics covered today

CMSC 435: Software Engineering Course overview. Topics covered today CMSC 435: Software Engineering Course overview CMSC 435-1 Topics covered today Course requirements FAQs about software engineering Professional and ethical responsibility CMSC 435-2 Course Objectives To

More information

PESIT Bangalore South Campus. Department of MCA SOFTWARE ENGINEERING

PESIT Bangalore South Campus. Department of MCA SOFTWARE ENGINEERING PESIT Bangalore South Campus Department of MCA SOFTWARE ENGINEERING 1. GENERAL INFORMATION Academic Year: JULY-NOV 2015 Semester(s):III Title Code Duration (hrs) SOFTWARE ENGINEERING 13MCA33 Lectures 52Hrs

More information

Answers to Review Questions

Answers to Review Questions Tutorial 2 The Database Design Life Cycle Reference: MONASH UNIVERSITY AUSTRALIA Faculty of Information Technology FIT1004 Database Rob, P. & Coronel, C. Database Systems: Design, Implementation & Management,

More information

Information system for production and mounting of plastic windows

Information system for production and mounting of plastic windows Information system for production and mounting of plastic windows MARCEL, MELIŠ Slovak University of Technology - Faculty of Material Sciences and Technology in Trnava, Paulínska 16 street, Trnava, 917

More information

Algorithm & Flowchart & Pseudo code. Staff Incharge: S.Sasirekha

Algorithm & Flowchart & Pseudo code. Staff Incharge: S.Sasirekha Algorithm & Flowchart & Pseudo code Staff Incharge: S.Sasirekha Computer Programming and Languages Computers work on a set of instructions called computer program, which clearly specify the ways to carry

More information

risks in the software projects [10,52], discussion platform, and COCOMO

risks in the software projects [10,52], discussion platform, and COCOMO CHAPTER-1 INTRODUCTION TO PROJECT MANAGEMENT SOFTWARE AND SERVICE ORIENTED ARCHITECTURE 1.1 Overview of the system Service Oriented Architecture for Collaborative WBPMS is a Service based project management

More information

Chapter 8 Approaches to System Development

Chapter 8 Approaches to System Development Systems Analysis and Design in a Changing World, sixth edition 8-1 Chapter 8 Approaches to System Development Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases

More information

Competencies for Secondary Teachers: Computer Science, Grades 4-12

Competencies for Secondary Teachers: Computer Science, Grades 4-12 1. Computational Thinking CSTA: Comp. Thinking 1.1 The ability to use the basic steps in algorithmic problemsolving to design solutions (e.g., problem statement and exploration, examination of sample instances,

More information

University of Dayton Department of Computer Science Undergraduate Programs Assessment Plan DRAFT September 14, 2011

University of Dayton Department of Computer Science Undergraduate Programs Assessment Plan DRAFT September 14, 2011 University of Dayton Department of Computer Science Undergraduate Programs Assessment Plan DRAFT September 14, 2011 Department Mission The Department of Computer Science in the College of Arts and Sciences

More information

Principles of Software Engineering: Software Methodologies. COSI 120b, Spring 2005

Principles of Software Engineering: Software Methodologies. COSI 120b, Spring 2005 Principles of Software Engineering: Software Methodologies COSI 120b, Spring 2005 Overview What are methodologies? The methodologies Traditional Incremental Evolutionary Other Conclusions Way Forward What

More information

2 Evaluation of the Cost Estimation Models: Case Study of Task Manager Application. Equations

2 Evaluation of the Cost Estimation Models: Case Study of Task Manager Application. Equations I.J.Modern Education and Computer Science, 2013, 8, 1-7 Published Online October 2013 in MECS (http://www.mecs-press.org/) DOI: 10.5815/ijmecs.2013.08.01 Evaluation of the Cost Estimation Models: Case

More information

General Problem Solving Model. Software Development Methodology. Chapter 2A

General Problem Solving Model. Software Development Methodology. Chapter 2A General Problem Solving Model Software Development Methodology These focus on understanding what the problem is about Chapter 2A Concerned with understanding more about the nature of the problem and possible

More information

CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective:

CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective: CS 487 Week 8 Reading: 1. Ian Sommerville, Chapter 3. Objective: 1. To check the understandibility of the students in life cycle and process model for development of a software product. 2. To check if

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Software Engineering CSCI 4490. Lesson 9 Project Management Part 1- Planning & Estimating. February 23, 2015

Software Engineering CSCI 4490. Lesson 9 Project Management Part 1- Planning & Estimating. February 23, 2015 Lesson 9 Project Management Part 1- Planning & Estimating February 23, 2015 Projects and Project Managers Project a [temporary] sequence of unique, complex, and connected activities having one goal or

More information

Software Requirements Metrics

Software Requirements Metrics Software Requirements Metrics Fairly primitive and predictive power limited. Function Points Count number of inputs and output, user interactions, external interfaces, files used. Assess each for complexity

More information

Software Paradigms (Lesson 1) Introduction & Procedural Programming Paradigm

Software Paradigms (Lesson 1) Introduction & Procedural Programming Paradigm Software Paradigms (Lesson 1) Introduction & Procedural Programming Paradigm Table of Contents 1 Introduction... 2 1.1 Programming Paradigm... 2 1.2 Software Design Paradigm... 3 1.2.1 Design Patterns...

More information

A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management

A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management International Journal of Soft Computing and Engineering (IJSCE) A Study on Software Metrics and Phase based Defect Removal Pattern Technique for Project Management Jayanthi.R, M Lilly Florence Abstract:

More information

An Introduction to Software Engineering

An Introduction to Software Engineering An Introduction to Software Engineering ACSC 383 Software Engineering Efthyvoulos C. Kyriacou (PhD) Assoc. Prof. Computer Science and Engineering Department Resources : Ian Sommervile Software engineering,

More information

BCS HIGHER EDUCATION QUALIFICATIONS Level 6 Professional Graduate Diploma in IT. March 2013 EXAMINERS REPORT. Software Engineering 2

BCS HIGHER EDUCATION QUALIFICATIONS Level 6 Professional Graduate Diploma in IT. March 2013 EXAMINERS REPORT. Software Engineering 2 BCS HIGHER EDUCATION QUALIFICATIONS Level 6 Professional Graduate Diploma in IT March 2013 EXAMINERS REPORT Software Engineering 2 General Comments The pass rate this year was significantly better than

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

Umbrella: A New Component-Based Software Development Model

Umbrella: A New Component-Based Software Development Model 2009 International Conference on Computer Engineering and Applications IPCSIT vol.2 (2011) (2011) IACSIT Press, Singapore Umbrella: A New Component-Based Software Development Model Anurag Dixit and P.C.

More information

Module 11. Software Project Planning. Version 2 CSE IIT, Kharagpur

Module 11. Software Project Planning. Version 2 CSE IIT, Kharagpur Module 11 Software Project Planning Lesson 27 Project Planning and Project Estimation Techniques Specific Instructional Objectives At the end of this lesson the student would be able to: Identify the job

More information

Applications in Business. Embedded Systems. FIGURE 1-17 Application Types and Decision Types

Applications in Business. Embedded Systems. FIGURE 1-17 Application Types and Decision Types 22 CHAPTER 1 Overview of Software Engineering she may determine his or her degree of confidence in the ES's results. These four application types-transaction, query, DSS, and ES-will be referenced throughout

More information

Chapter 24 - Quality Management. Lecture 1. Chapter 24 Quality management

Chapter 24 - Quality Management. Lecture 1. Chapter 24 Quality management Chapter 24 - Quality Management Lecture 1 1 Topics covered Software quality Software standards Reviews and inspections Software measurement and metrics 2 Software quality management Concerned with ensuring

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,

More information

SOFTWARE DESIGN TECHNIQUES. Nagalaxmi Telkar CSCI 5828 Presentation Slides

SOFTWARE DESIGN TECHNIQUES. Nagalaxmi Telkar CSCI 5828 Presentation Slides SOFTWARE DESIGN TECHNIQUES Nagalaxmi Telkar CSCI 5828 Presentation Slides CONTENTS Introduction Software Design Life Cycle Software Design Process Tackling Design Problems Architectural Design Abstract

More information

Foundations for Systems Development

Foundations for Systems Development Foundations for Systems Development ASSIGNMENT 1 Read this assignment introduction. Then, read Chapter 1, The Systems Development Environment, on pages 2 25 in your textbook. What Is Systems Analysis and

More information

IV. Software Lifecycles

IV. Software Lifecycles IV. Software Lifecycles Software processes and lifecycles Relative costs of lifecycle phases Examples of lifecycles and processes Process maturity scale Information system development lifecycle Lifecycle

More information

Software Development Processes. Software Life-Cycle Models

Software Development Processes. Software Life-Cycle Models 1 Software Development Processes Sequential, Prototype-based RAD, Phased, Risk-based Spiral (c) 1998 M Young CIS 422/522 4/3/98 1 Software Life-Cycle Models Breaking projects down into pieces for... Planning

More information

Software Engineering. Software Development Process Models. Lecturer: Giuseppe Santucci

Software Engineering. Software Development Process Models. Lecturer: Giuseppe Santucci Software Engineering Software Development Process Models Lecturer: Giuseppe Santucci Summary Modeling the Software Process Generic Software Process Models Waterfall model Process Iteration Incremental

More information

Requirements engineering and quality attributes

Requirements engineering and quality attributes Open Learning Universiteit Unit 2 Learning Unit 2 Requirements engineering and quality attributes Contents Introduction............................................... 21 2.1 Important concepts........................................

More information

Software Design Document (SDD) Template

Software Design Document (SDD) Template (SDD) Template Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase.

More information

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.) The Software Process Xiaojun Qi 1 The Unified Process Until recently, three of the most successful object-oriented methodologies were Booch smethod Jacobson s Objectory Rumbaugh s OMT (Object Modeling

More information

Glossary of Object Oriented Terms

Glossary of Object Oriented Terms Appendix E Glossary of Object Oriented Terms abstract class: A class primarily intended to define an instance, but can not be instantiated without additional methods. abstract data type: An abstraction

More information

Software Life Cycle Processes

Software Life Cycle Processes Software Life Cycle Processes Objective: Establish a work plan to coordinate effectively a set of tasks. Improves software quality. Allows us to manage projects more easily. Status of projects is more

More information

Software Project Models

Software Project Models INTERNATIONAL JOURNAL OF TECHNOLOGY ENHANCEMENTS AND EMERGING ENGINEERING RESEARCH, VOL 1, ISSUE 4 135 Software Project Models Abhimanyu Chopra, Abhinav Prashar, Chandresh Saini Email-abhinav.prashar@gmail.com,

More information

WebSphere Business Modeler

WebSphere Business Modeler Discovering the Value of SOA WebSphere Process Integration WebSphere Business Modeler Workshop SOA on your terms and our expertise Soudabeh Javadi Consulting Technical Sales Support WebSphere Process Integration

More information

Java Programming (10155)

Java Programming (10155) Java Programming (10155) Rationale Statement: The world is full of problems that need to be solved or that need a program to solve them faster. In computer, programming students will learn how to solve

More information

MEng, BSc Applied Computer Science

MEng, BSc Applied Computer Science School of Computing FACULTY OF ENGINEERING MEng, BSc Applied Computer Science Year 1 COMP1212 Computer Processor Effective programming depends on understanding not only how to give a machine instructions

More information

Software Engineering (Set-I)

Software Engineering (Set-I) MCA(4 th Sem) Software Engineering (Set-I) Q. 1) Answer the following questions (2x10) a) Mention the importance of phase containment errors. Relate phase containment errors with the development cost of

More information

Software Engineering. Tutorial

Software Engineering. Tutorial Software Engineering Tutorial Simply Easy Learning About the tutorial Software Engineering Tutorial This tutorial provides you the basic understanding of software product, software design and development

More information