1.Software Engineering 2008 Introduction to Software EngineeringSoftware is (1) instructions (computer programs) that when executed provide desired features, function, and performance; (2) data structures that enable the programs to adequately manipulate information; and (3) documents that describe the operation and use of the programs.Software Characteristics:1. Software is developed or engineered; it is not manufactured in the classical sense.2. Software does not wear out. As we see the failure curve for hardware and other engineeredproducts is bath tub shaped. The increase in utility is sudden. But in case of software, thecurves are upward sloping after a downfall. That is because, with the introduction of change(new features) in the software, the utility of software rises suddenly. After a while, due tothe dynamic nature of business, the utility falls again. Again the new enhanced features areintroduced early, to ensure utility does not fall, rather rises. Thus in totality, the curve wouldbe upward sloping.Wear outInfant mortalityFailure curve for hardware Increased failure rate due to side effectsChangeActual CurveIdealized curveFailure curve for software3. Most software continue to be custom built 1

2. Software Engineering 2008 Types of Software1. System Software is a collection of programs written to service other programs. E.g.compilers, editors and file management utilities.2. Application Software consists of standalone programs that solve a specific business need3. Engineering/ Scientific software4. Embedded software resides within a product or system and is used to implement andcontrol features and functions for the end user and for the system itself5. Product-line software are designed to provide a specific capability for use by manydifferent customers, product line software can focus o a limited and esotericmarketplace.6. Web-applications can be a little more than a set of linked hypertext files that presentinformation using text and limited graphics.7. Artificial intelligence software makes use of non-numerical algorithms to solve complexproblems that are not amenable to computation or straightforward analysis.8. Legacy software is the software which is still being used by corporate, in spite of adventof new technologies. These systems have evolved with the changes in environment andare still serving their purpose well.Nature of Software1. Software is flexible, or open for changes2. Software is developed for long term usage3. Software is complex as the problems to be solved are getting more complex.4. Software involves communication with the machineWhat is good software? Good software includes a few qualities that can be grouped into the following categories. 1. Quality of product 2. Quality of the process 3. Quality in the context of business environment (ROI or Return On Investment) Essential qualities of a good software include correctness, reliability, robustness, performance, usability, verifiability, maintainability, repair ability, evolve ability, portability, understand ability, interoperability, productivity, timeliness, visibility and reusability, to name a few.2 3. Software Engineering 2008Measurable Characteristics for Software1. Functionality: The capability to provide functions which meet stated and implied needs(suitability) when the software is used, accuracy and security.2. Reliability: The capability to maintain a specified level of performance. Performance is alsomeasured according to the requirement of the system.3. Usability: The capability to be understood (understand ability), learned (learn ability) andused (operability)4. Efficiency: The capability to provide appropriate performance relative to the amount ofresources used.5. Maintainability: The capability to be modified for purposes of making corrections(changeability, testability), improvements, or adaptation (stability). Software is repairable ifits defects can be corrected with a reasonable amount of work. It should not be cheaper toreplace it than to repair it. Since software is malleable it is easy to modify it. But after a lot ofmodifications, new modifications complicate the execution, causing lack of evolve ability.Thus proper designing before changing the software is important.6. Portability: The capability to be adopted (adaptability) for different specified environments(install ability) without applying actions or means other than those provided for this purposein the product.7. Robustness: Software is robust if it behaves reasonably even in circumstances that were notanticipated in the requirement specification.8. Scalability: Software that runs for a small level should also run on a large scale and viceversa.9. Correctness: is an absolute quality. Any deviation from its requirements would make itincorrect, regardless of how minor or serious the consequences of the deviation are.10. Verifiability: exists if its properties can be verified easily. (Testability)11. Reusability: may be applied at different levels of granularity such as components level, orrequirement specification level, software process level etc. Reusability characterizesmaturity of engineered products.12. Interoperability: refers to the ability of the system to coexist and cooperate with othersystems. Reusability is enhanced with interoperability.13. Productivity: is the quality of software production process, referring to its efficiency andperformance. Modern software engineering tools and environments lead to increase inproductivity.14. Timeliness: is a process-related quality that refers to the ability to deliver a product on time.Due to lack of standard principles, projects prepare improper schedules. Thus measuringtimeliness becomes difficult. Software crisisThere is a rise in software prices as compared to hardware prices. Also the software is difficult to alter, debug and enhance. This is because of lack of adequate training in software engineering. Large software has failed and has caused huge losses and was called software runways.Reasons for software Crisis 1. Lack of communication between developers and users 2. Increase in size of software 3. Increase in cost of developing software 4. Increased complexity of problems3 4. Software Engineering 20085. Lack of understanding of problem and environment 6. High optimistic estimates 7. Difficult estimation of time 8. Quality parameters not standardized 9. Maintenance problems with codeSoftware Engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. It is a layered technology.The engineering approach must rest on an organizational commitment to quality. The foundation of software engineering is the process layer, which defines a framework for effective delivery of software engineering technology. Methods provide the technical how-tos for building software. Software engineering tools provide automated or semi-automated support for the process and methods. Software engineering is about solving problems. It can be broken into analyzing (problem) and synthesis (solution).Computer ScienceCustomer Theories Computer Problem functionsSoftware EngineeringTools and techniques tosolve problems 4 5. Software Engineering 2008Evolution of Software Engineering T e cEngineering h Unorganized use of past n experience Systematic use of past oexperience . Formulation of l Craftscientific basis o Esoteric use of past g Art experience y Time Theory of software evolutionOver the years a few observations made on project display the following laws present in software Law of continuing change, thus adaptability is required. Law of increasing complexity, thus work should be done to reduce it. Law of self-regulation causes balanced and normal product and process improvements Law of conservation of organizational stability Law of conservation of familiarity i.e. all associated with the e-type system evolve with it. Law of continuing growth so as to ensure user satisfaction Law of declining quality unless maintained and adapted The Feedback system law to achieve improvement Emergence of Software Engineering 5 6. Software Engineering 2008 Object Oriented Design Data Flow Oriented DesignData Structure Oriented Design Control Flow Oriented Design Exploratory StyleComparing Software Engineering with other Engineering DisciplinesIssue Software EngineeringEngineeringBased on computer science, Based on science, mathematics, and empirical Foundationsinformation science, and knowledge.discrete mathematics.Compilers and computers arecheap, so software engineering In some projects, construction andand consulting are often more manufacturing costs can be high, sothan half of the cost of a Costengineering may only be 15% of the cost of aproject. Minor software project. Major engineering cost overruns mayengineering cost-overruns can not affect the total project cost.adversely affect the totalproject cost.Replication (copying CDs orRadically new or one-of-a-kind systems candownloading files) is trivial. require significant development effort toMost development effort goes create a new design or change an existing Replicationinto building new (unproven) design. Other kinds of systems may requireor changing old designs andless development effort, but more attention toadding features. issues such as manufacturability. Engineers generally try to apply known andSoftware engineers often apply tested principles, and limit the use of untested Innovation new and untested elements in innovations to only those necessary to create asoftware projects. product that meets its requirements.Software engineers emphasizeSome engineers solve long-ranged problems Duration projects that will live for years(bridges and dams) that endure for centuries.or decades. Engineers in some disciplines, such as civil Management Few software engineers engineering, manage construction, Status manage anyone. manufacturing, or maintenance crews.Software engineers must blame Engineers in some fields can often blame Blamethemselves for projectconstruction, manufacturing, or maintenanceproblems. crews for project problems. Practitioners611,900 software engineers 1,157,020 total non-software engineers6 7. Software Engineering 2008in U.S.Software engineering is about Engineering as a whole is thousands of years Age50 years old. old.Software engineers are In many jurisdictions it is illegal to calltypically self-appointed. Ayourself an engineer without specific formal Titlecomputer science degree is education and/or accreditation by Regulationscommon but not at all a formal governmental or engineering associationrequirement.[bodies.Some engineering disciplines are based on aclosed system theory and can in theory prove Methods for formally verifyingformal correctness of a design. In practice, a correctness are developed inlack of computing power or input data can Analysiscomputer science, but they aremake such proofs of correctness intractable, Methodology rarely used by softwareleading many engineers to use a pragmatic engineers. The issue remainsmix of analytical approximations and controversial.empirical test data to ensure that a product willmeet its requirements. Engineers have nominally refined synthesis techniques over the ages to provide exactly this. However, this has not prevented some notable engineering failures, such as the SE struggles to synthesize Synthesis collapse of Galloping Gertie (the original (build to order) a result Methodology Tacoma Narrows Bridge), the sinking of the according to requirements. Titanic, and the Pentium FDIV bug. In addition, new technologies inevitably result in new challenges that cannot be met using existing techniques. Traditional engineering nominally separatesSoftware engineering is oftenthese activities. A project is supposed to apply Research busy with researching theresearch results in known or new clever ways during unknown (e.g. to derive an to build the desired result. However, ground- Projects algorithm) right in the middle breaking engineering projects such as Projectof a project.Apollo often include a lot of research into the unknown. Some engineering disciplines have thousands of years of best practice experience handed Software engineering has just over from generation to generation via a field's Codified Best recently started to codify and literature, standards, rules and regulations. Practiceteach best practice in the form Newer disciplines such as electronic of design patterns. engineering and computer engineering have codified their own best practices as they have developed.Software Engineering Challenges 7 8. Software Engineering 20081. Scale: Rules for small scale do not apply on large scale 2. Quality and productivity: These are the terms that are vaguely defined. Productivity directlydepends upon the people in development. Quality includes N number of parameters. 3. Consistently and repeatability: The methods for software development should be repeatableacross projects leading to consistency in the quality of software produced. 4. Change: Software should accommodate and embrace change. Since as businesses change,they require that the software supporting it should change. 5. Heterogeneity: Developing techniques for building software that can cope withheterogeneous platforms and execution environments; 6. Delivery: Developing techniques that lead to faster delivery of software; 7. Trust: Developing techniques that demonstrate that software can be trusted by its users.Software process Software projects utilize a process to organize the execution of tasks to achieve the goals on the cost, schedule and quality fronts.A process model specifies a general process, usually as a set of stages in which a project should be divided; the order in which the stages should be executed and any other constraints and conditions on the execution of stages. A projects process may utilize some process model.The process that deals with the technical and management issues of software development is called a software process.The desired Characteristics of a Software Process are:1. Predictability: It determines how accurately the outcome of following the process canbe predicted. The fundamental basis for quality prediction is that quality of the productis determined largely by the process followed for developing it. Effective management ofquality control activities depends upon the predictability of the process.2. Support Testability and Maintainability: One of the most important objectives ofsoftware development should be to reduce the maintenance effort. The process used,should ensure that maintainability. Both testing and maintenance depend heavily on thequality of design and code, and these costs can be considerably reduced if the softwareis designed and coded to make testing and maintenance easier.3. Support change: Software changes are driven by business need, peoples mindset etc.Thus change is prevalent, and a process that can handle change easily is desirable.4. Early Defect removal: We should attempt to detect errors that occur in a phase, duringthat phase itself, to reduce effort and cost or removing them. Error detection andcorrection should be a continuous process.5. Process improvement and feedback: To satisfy the objectives of quality improvementare cost reduction, the software process must be improved. Each step in a process has.. 8 9. Software Engineering 20081. An objective 2. Requires people or effort defined 3. Has inputs and produces specific output 4. Beginning time or criteria, and exit criteria 5. Has a duration 6. Has constraints 7. Must produce information for the management, so that corrective action may be taken e.g.adding more resources 8. Step ends with a review to verify the step is correctly done Software Components In engineering disciplines, products are always constructed from parts or components. Similarly, software engineering is component based. Until the early 1990s, components were routines and libraries. With advances in programming languages, other mechanisms like generic constructs in languages as ADA and C++ and objects and frameworks in object oriented language also came.A framework is a collection of related classes that are designed to be used together in developing applications in a certain domain. Standard template library in C++ is fine grained, code level component. While swing and Java Beans that provide classes and objects for visual approach to software development are medium grained components. Large grained components such as database management systems act as components in the architecture.A component is a software element that confirms to a component model and can be independently deployed and composed without modification, according to a composition standard. Components are standardized, Independent, comparable, deployable and documented.Examples of components are the standard template library in C++, JavaBeans and Swing. Software ReuseAlmost all artifacts associated with software development, including project plan and test plan can be reused. Some prominent items that can be effectively reused are requirements specification, design, code, test cases, knowledge etc.Software reuse requires consideration of the following points:Component creation: It should be decided in advance what should be created. Component indexing and storing: Classification of reuse components is essential Component search: Component matching the requirements has to be identified correctly Component understanding: Proper understanding of the component is necessary beforeapplying it to use. Component adaptation: Customization should be possible Repository maintenance: New components added should be stored and should be traceable.9 10. Software Engineering 2008Increasing reusability Name generalization helps identification with the application of the component Operation generalization increases applicability Exception generalization involves providing for all exceptions that might occur in advance.Software Costs Software costs often dominate computer system costs. The costs of software on a PC areoften greater than the hardware costs. Software costs more to maintain than it does to develop. For systems with a long life,maintenance costs may be several times development costs. Software engineering is concerned with cost-effective software development. Cost of the software includes the cost of developers, the hardware resources used fordevelopment and the cost of infrastructure required for such development.Thus following points become important considerations for software engineering Attempt to estimate cost/effort Define plan Prepare schedules Involve user Identify stages Define milestones Reviews Define deliverables Quality assurance steps (testing) Job of a Software developer Every developer has to become accurate in three forms of communication 1. Communication with the user. The user is not always well informed. There is also a gap between the user and the developer in terms of field of work. Thus getting the right information from the user is very critical task for the developer 2. Communication with the technical specialists. It is difficult to understand the jargon of a technical specialist and thus the developer has to convey the information correctly to him, in the way he can understand. 3. Communication with the management. The management personnel have business knowledge and understanding of the application of the software. But they are not well versed with the technicalities involved. Judging correctly the importance of the requirement stated by the management is an important task for the developer. 10 11. Software Engineering 2008Software Engineering Code of EthicsThe preamble of the code states thatComputers have a central and growing role in commerce, industry, government, medicine, education, entertainment, and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance, and testing of software systems. Because of their roles in developing software systems, software engineers have significant opportunities to do good or cause harm. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:The eight principles are as follows:1. Public: Software engineers shall act consistently with the public interest. 2. Client and Employer: Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest. 3. Product: Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. Judgment: Software engineers shall maintain integrity and independence in their professional judgment. 5. Management: Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. Profession: Software engineers shall advance the integrity and reputation of the profession, consistent with the public interest. 7. Colleagues: Software engineers shall be fair to, and supportive of, their colleagues. 8. Self: Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.Software Metrics are quantifiable measures that could be used in Software engineering to calculate 1. The complexity of the software which in turn helps in other ways 2. Cost estimation based on the calculations 3. Allocation of appropriate resources as per the complexity of project 4. Correct scheduling of tasks as per the complexity 5. Evaluation of Quality and reliability of system 6. Improving quality of the system 7. Help in management of risksThey help in the overall development of the system in a more organized and methodical way. Metrics are important to manage the project successfully. There are three types of software metrics:1. Product metrics measure the software11 12. Software Engineering 2008 2. Process metrics quantify characteristics of the process used3. Project metrics quantifies the whole project such as amount of project completionThere are different scales for measuring metrics such as:1. Nominal which categorizes in groups and is thus a qualitative and not a quantitative measure2. Ordered scale and tell the sequence3. Interval can be incremental or regression analysis4. Ratio can tell exact quantitative differences which can be ordered and groupedExamples: Measures are of different types1. Size metricsa. Lines Of Code (LOC)b. Effective lines of Code (ELOC)/NLOCc. Commented lines of code (LOC)d. Functionalitye. Effort2. Function points3. Complexitya. O notationb. Algorithm/ logic4. Structurea. Cyclomatic complexity5. Process measurementa. Time taken for process activities to be completed E.g. Calendar time or effort to complete an activity or process.b. Resources required for processes or activities E.g. Total effort in person-days.c. Number of occurrences of a particular event E.g. Number of defects discovered. 12 13. Software Engineering 2008Software Development Life Cycle The software Life Cycle encompasses all activities required to define, develop, test deliver, operate and maintain a software product. Planning the software development process involves several important considerations. The first is to define a product life cycle model. The common Software Development Life Cycle activities are: 1. Feasibility: Determine if the software has significant contribution to business. It includes market analysis if similar software is in demand in market. Software is evaluated on the basis of cost, schedule and quality.2. Requirements are determined such as functional properties desired by users, system requirements such as availability, performance and safety, establishing set of objectives the system should meet, characteristics that the system should not exhibit. Such requirements are obtained by various methods such as interviews, communication with stake holders, scenario discussions, use cases and ethnography. These requirements are then verified and tested.3. Project Planning, cost analysis, scheduling, quality assurance plans are made4. Designing i.e. Architectural design, Interface design and detailed design5. Implementation includes writing the code for the project as per the designs and plan6. Testing ensures accuracy and reliability7. Delivery, Installation, Training, Help Desk8. Maintenance, software configuration management. Another view of SDLC emphasizes the milestone, documents and reviews throughout product development. It is difficult for project managers to assess progress or anticipate problems. Establishing milestones, improves product visibility. The following are the milestones for the project. 1.Feasibility report2.System definition, project plan3.Software requirement specification, Preliminary user manual4.Architectural design document5.Detailed design document6.Software verification plan7.Product Schedule8.Software test plan, Acceptance test9.Software quality assurance plan10. User manual11. Source code12. Test results13. Defect report 13 14. Software Engineering 2008Every software engineering organization should describe a unique set of framework activities for the software process it adopts. Various models have been developed over the years to accommodate these activities. Models for Software Development Evolutionary models 1. Waterfall Model suggests a systematic sequential approach to software development that begins with customer specification of requirements. The principle stages of the model map onto fundamental development activities. a. Requirement Analysis and definition b. System and software design c. Implementation and unit testing d. Integration and system testing e. Operation and maintenance The verification at each stage ensures that the output is consistent with its input and overall requirement of the system. These outputs are often called work products and can be listed as:a. Requirements documents 14 15. Software Engineering 2008b. Project plan c. Design documents d. Test plan and test reports e. Final code f. Software manuals (e.g. user, installation, etc)Advantages1. Simple method with clear steps2. Easy to administer as it is systematic3. Verification at each stage ensures early detection of errors / misunderstanding4. Documentation helps in future maintenance and revisionsDisadvantage1. Unchanging requirements are not realistic2. Document driven process3. Change adaptability is very slow 2. Incremental Model: Customer identifies the services to be provided. The delivery increments are then defined, with each increment providing a sub-set of the system functionality. Once the system increments for the services have been identified, the requirements to be delivered in the first increment are defined in detail and the increment is developed. AssignDevelopDefine outlineDesign SystemrequirementsSystemrequirement Architectureto increments increment ValidateIntegrateValidateIncrement IncrementSystem Final SystemAdvantages of Incremental Model 1. Accelerated delivery of customer services 2. User engagement with the systemDisadvantages of incremental Model 1. Management problems: Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done. 2. Contractual problems: The normal contract may include a specification; without a specification, different forms of contract have to be used. 15 16. Software Engineering 2008 3. Validation problems: Without a specification, it is difficult testing the system 4. Maintenance problem: Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements. 3. Prototyping: First a working prototype of the software is developed instead of developing the actual software. The developers use this prototype to refine the requirements and prepare final specification document. After the finalization of SRS document, the prototype is discarded and actual system is then developed using the waterfall approach.RequirementsQuick Design / Prototype Implement Refinement ofCustomer Evaluation Requirements as persuggestionsDesign Implementation and Unit TestingIntegration and System TestingOperation and MaintenanceThere are 2 types of prototypes; throw-away, where the initial prototype is discarded afterthe requirements are defined and the evolutionary prototype, where the system is builtfurther on the prototype itself. A prototype is built for those requirements which are criticalfor the project and are not understood well. If the number of requirements which needclarification is more, then a working prototype is built for them. The importance or criticalityof such requirements is also a significant factor in determining the need of a prototype.Prototyping becomes important in cases where there is no model to follow e.g. experimentalprojects which are being made for the first time.Advantages of Prototyping 1. Users are actively involved in the development16 17. Software Engineering 2008 2. It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency. Thus improved usability.3. Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.4. Errors can be detected much earlier as the system is mode side by side.5. Quicker user feedback is available leading to better solutions.6. Improved design quality because an operational design is created first.Disadvantages1. Leads to implementing and then repairing way of building systems. 2. Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.4. Spiral Model: Boehm tried to incorporate the project risk factor into a life cycle model. Each phase is split roughly into four sections namely planning, risk analysis, development and assessment. There are 4 phases namely feasibility, requirements analysis, design and coding and testing. The spiral development consists of four quadrants as shown in the figure above The first step in each phase is to identify the objective, alternatives and constraints of that phase. The next stage involves identifying the best alternative, by comparing all and performing risk analysis. One the alternative is chose, prototypes are built using simulation 17 18. Software Engineering 2008and benchmarks. Each phase is completed with a review by the people concerned with the project. Specialized process models 1. Extreme programming includes creating a set of stories and assigning their priority. The commitment defines the order for development. The objects are organized for development. Designing occurs both after and before programming, in the form of design and refactoring. Programming happens in the form of pain programming where two people work together at one workstation. Writing test cases before starting the coding is a key feature of extreme programming. Acceptance testing is followed by system testing. The test cases are developed incrementally from scenarios, with user involvement through validation and are supported by automated test tools. Extreme programming delivery cycleS le t u e e c srB a dw re k o ns rie fo th to s r isP n re a e la le ss rie tota ks to s s re a ele sEva alu te R le se ae De lo /in g ra / ve p te te s teys ms ftw re o a te t s ftw re s o a 2. Component-Based Development uses commercial-off-the-shelf (COTS) software components.3. Unified Process is a use-case driven, architecture centric, iterative and incremental software process.4. Dynamic Systems Development Method (DSDM) suggests an iterative software process. After the feasibility study follows the business study that establishes the functional and information requirements for the application. The iteration steps include Functional model iteration which creates a prototype. New requirements might be generated through the prototype, by the user. Subsequently or simultaneously designs are built or rebuilt. Implementation iteration places the latest software increments.5. Feature driven development emphasizes project management guidelines and techniques. The processes defined for such development are to develop an overall model, build a feature list, plan by feature, design by feature, build by feature. A rapid application development environment 18 19. Software Engineering 2008Inte ce rfa Office g nee rato rs te s ys mDBRe o p rtp gram ing romg ne to e ra rla uagng eData a em na g m nt s te bs ae e ys m Rap a p tio id p lica nd ve p e e e lo m nt nviro enm nt Process choice Process used should depend on type of product which is being developed For large systems, management is usually the principal problem so you need astrictly managed process; For smaller systems, more informality is possible.There is no uniformly applicable process which should be standardised within an organisation High costs may be incurred if you force an inappropriate process on a developmentteam; Inappropriate methods can also increase costs and lead to reduced quality. Process analysis and modellingWhen defining the set of process stages for a project, the following steps can be followed. 1. Study an existing process to understand its activities.Some of the process analysis techniques are : Published process models and process standards: It is always best to start processanalysis with an existing model. People then may extend and change this. Questionnaires and interviews: Must be carefully designed. Participants may tell youwhat they think you want to hear. Ethnographic analysis: Involves assimilating process knowledge by observation. Best forin-depth analysis of process fragments rather than for whole-process understanding 2. Produce an abstract model of the process. You should normally represent this graphically. Several different views (e.g. activities, deliverables, etc.) may be required.3. Analyse the model to discover process problems. This involves discussing process activities with stakeholders and discovering problems and possible process changes.Process improvement 19 20. Software Engineering 2008Process improvement is about understanding existing processes and introducing process changes to improve product quality reduce costs or accelerate schedules. Most process improvement work so far has focused on defect reduction. This reflects the increasing attention paid by industry to quality. However, other process attributes can also be the focus of improvement. Feedback is important for process improvement to initiate. Why is it difficult to improve a software process? 1. Not enough time: Developers, because of unrealistic schedules are left with no time toexplore problems of development and find solutions. 2. Lack of knowledge: many developers are not aware of best practices 3. Wrong motivation: The basic motivation should be to eradicate current difficulties and notjust to achieve a higher CMM level. 4. Insufficient commitment: A lot of times when the improvement is identified, we startimplementing it. But before the corrected state is achieved, developers lose hope of findingthe correct solution and quit the improvement process. This should not happen. ProducProcesstivitImprovementy BeginsImproved future state Do not quit here Learning curve TimeProcess improvement stages20 21. Software Engineering 2008 Process measurement: Attributes of the current process are measured. These are a baseline forassessing improvements.Process analysis: The current process is assessed and bottlenecks and weaknesses are identified.Process change: Changes to the process that have been identified during the analysis areintroduced. Process change stages Improvement identification: highlights the area that requires improvement. The assessmentteam seeks feedback from the project representatives to help ensure that they properlyunderstand the issues. The assessment participants are briefed the senior management as agroup about the objectives and activities of the assessment. The team then holds discussionswith the leader of each selected project, functional area representatives (FARs), selectedsoftware practitioners to clarify information provided from the maturity questionnaire. Theteam generates a preliminary set of findings. The findings are revised and presented by theassessment participants and senior site management as preliminary recommendations. Improvement prioritization: involves identifying which recommendations are necessary andshould be implemented. They are evaluated on the basis of quality impacts and costbenefits. Process change introduction: is the first change management step initiated to implementthe recommendation. It includes planning how to implement the change, getting acceptancefrom all users and management to introduce it and defining the new changed process. Process change training: is necessary to educate everyone about the new process and how itshould be performed. Change tuning: is performed finally to practically implement the change. Any problemsassociated with the new process are corrected. It takes some time to reach the correctpractical solution. 21 22. Software Engineering 2008Software RequirementRequirements analysis in software engineering encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.Requirements analysis is critical to the success of a development project. Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.Requirement process Need for Software Requirement Specification (SRS)The Software Requirement Specification describes what the proposed software should do without describing how the software will do it. 1. It establishes the basis for agreement between the client and the supplier on what the software product will do. 2. It provides a reference for validation of the final product 3. A high quality SRS is a pre-requisite for high quality product 4. A high quality SRS reduces the development cost as the cost of fixing a requirement error is high as all the phases have to be repeatedRequirement engineering tasks1. Inception: Casual interaction to get product request2. Elicitation: Ask customer, user and others about their requirements1. Requirement discovery2. Requirement classification and organization3. Requirement prioritizing and negotiation4. Requirement documentation3. Requirement elaboration: refinement of user scenarios 22 23. Software Engineering 2008 4. Negotiation5. Specification in written document6. ValidationThese are discussed in detail in further sections.Requirement DiscoveryRequirements discovery is the process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.Before the system analyst moves on to the task of information collection, he must plan his strategy. The plan must include- Serialized steps of information collection List of information to be collected at each step List of sources for the information to be collected The enquiry about the purpose of each information The method of collection of each informationTechniques for requirement discovery are discussed as follows: 1. Viewpoints: The requirements sources (stakeholders, domain, systems) can all be represented as system viewpoints, where each viewpoint presents a sub-set of the requirements for the system. There are three generic types of viewpoints: 1. Interactor viewpoints represent people or other system that interact directly withthe system. 2. Indirect viewpoints represent stakeholders who do not use the system themselvesbut who influence requirements. 3. Domain viewpoints represent domain characteristics and constraints that influencethe system requirements. 2. Interviewing: Formal or informal interviews with system stakeholders are part of most requirements engineering processes. Interviews may be of two types: 1. Closed interviews where the stakeholder answers a predefined set of questions 2. Open interviews where there is no predefined agenda. For getting the maximum out of an interview, the selection of the right candidate is important. Before starting the interviews, the analyst must write down the hierarchy, or position order of all. The interview must be conducted strictly in that order only, else the integration of information into the system modeling will become impossible, and some information may be lost or may remain unused. It is hard to elicit domain knowledge during interviews for two reasons: 1. All application specialists use terminology and jargon that is specific to a domain. 2. Some domain knowledge may be so familiar to stakeholders that they might forgetto mention it. Effective interviews have two characteristics: 1. They are open-minded, avoid preconceived ideas about the requirements and arewilling to listen to stakeholders. 23 24. Software Engineering 2008 2. They prompt the interviewee to start discussions with a question, a requirements proposal or by suggesting working together on a prototype. Interview Method Personal rapport is the soul of successful interview. The interview of different people has tobe conducted depending upon the level and content of information. Before conducting the interview, the analyst must ensure the status and role of the personin the information system. Accordingly, an ordered list of unambiguous questions must beframed for the interview. Each interview must start with simple and convenient questions toencourage the interviewee. After the statement of the interviewee is over, the analyst mustsummarize his statement to him and get his confirmation. Questions can be closed (requiring areply) or open (requiring interviewee to speak out his mind). Interviews with introvert type ofpeople must start with closed questions whereas those with extrovert persons must start withopen questions. Transition from one to the other type must be gradual and smooth. 3. ScenariosThey start with an outline of the interaction, and during elicitation, details added to create a complete description of that interaction. A scenario includes:1. A description of what the system and users expect when the system starts2. A description of the normal flow of events in the scenario3. A description of what can go wrong and how this is handled4. Information about other activities that might be going on at the same time5. A description of the system state when the scenario finishes4. Use-casesThese are scenarios based techniques which identify the individual interactions with thesystem. Actors in the process are represented as stick figures, and each class of interaction isrepresented as a named ellipse. A use case encapsulates a set of scenarios, and eachscenario is a single thread through the use-case.5. Ethnography is the observational technique that can be used to understand social and organizational requirements. Following two types of requirements can be effectively discovered:24 25. Software Engineering 20081. Requirements that are derived from the way people actually work 2. Requirements that are derived from cooperation and awareness of other peoplesactivities Classification of Requirements When we talk about the detail of requirements in relation to the system, we find two levels. The first is user requirements which are governed by the external users of the system such as client manager, system end-users, client engineers, system architects, etc. These briefly outline the system and are part of high level abstraction specifying the external behavior of the system. The second is system requirement which specifies the characteristics of the system. These define what the system should do. These are defined by the system end-users, client engineers, system architects, software engineers, etc. Each of the above requirements can be further divided as follows: 1. A functional requirement describes an interaction between the system and its environment. (Environmental Model). 2. Non-functional requirement describes a restriction on the system that limits our choices for constructing a solution to the problem. They may relate to emergent system properties such as reliability, response time etc. Failing to meet non-functional requirements can render a system unusable.(Behavioral model) Non-functional requirements can be related to the product, organization (cost, process, quality) or general (such as legislation, ethical). These requirements are difficult to verify because they are not easily quantifiable. 3. Domain requirements are defined by similar systems implemented. These may be functional or non-functional and are important, as they reflect fundamentals of the application domain. The third is interface specification which defines the procedure interface (APIs), Data Structures and representation of Data structures. Types of requirements: 1. Physical environment under which the system should work. 2. Interfaces required for interaction with the external environment 3. User and human factors that affect the operation of system. 4. Functionality desired by the system. 5. Documentation needs can be specified by the management. The time for such documentation can also be specified. 6. Data resource should be carefully defined for the system as data is a precious resource. 7. Resources apart from above should be mentioned, if they are involved with the system. 8. Security requirements are very important for systems dealing with critical resources. 9. Quality Assurance requirements as stated by the user or standards followed, should be mentioned in the requirements report to allow verifications and inspections.25 26. Software Engineering 2008Evaluation: The requirements that have been gathered need to be evaluated to resolve inconsistencies and also to understand why each requirement has been stated. In this task the analyst needs to do the following:o For every requirement X, get answers to question Why do you need X?o Convert any requirements stated as how to into the corresponding what is required.o Capture rationale to support future requirementso Perform risk assessment, feasibility and cost/benefit analysis considering the technical,cost and schedule concerns. A risk assessment is also performed to address technical, cost and schedule concerns. The rationale behind the information gathered in the previous stages is examined to determine whether the true requirements are hidden in this rationale instead of being expressed explicitly. Internally and commercially available software products and components are evaluated for possible reuse.Prioritisation: The requirements are then prioritised based on cost and dependency and user needs. Knowing the rationale behind each requirements helps in deciding the priorityConsolidation is required to put together all the requirements in a way that can be analysed further. It comprises:o Filling in as many to be determined issues as possibleo Validating that requirements are in agreement with originally stated goalso Removing inconsistencieso Resolving conflictso Authorizing/ verifying to move to the next step of development, i.e. detailed requirements analysis Often group development techniques are used for consolidation because they remove the possibility of an individuals interpretation of the requirements. Expressing Requirements Following representational techniques are used: 1. Static descriptions: A static description lists the system entities or objects, their attributes, and their relationships with each other. This view is static because it does not describe how relationships change with time. Different ways to describe a system statically are: 1. Indirect reference is made to the problem and its solution 2. Recurrence relation like Fibonacci 3. Axiomatic definition with the help of axioms/ theorems to specify basic system properties 4. Expression as a language (PDL) 2. Dynamic descriptions 1. Decision tables represent a actions to be taken when the system is in one of the states illustrated. 2. Functional description and transition diagrams (automata) 3. Event tables represent system states and transitions in a tabular form. 26 27. Software Engineering 20084. Petri nets representing a graphical system by drawing a node for each state and anarrow to mark the transitions3. System models are graphical representations that describe business processes and theproblem to be solved. Context models: Architecture models describe the environment of the system. They are supplemented by process models. Example:Behavioral models: They describe the overall behavior of the system. Examples are dataflowdiagrams and state machine models.1. Data flow models are used to show how data flows through a sequence of processingsteps. It shows a functional perspective where each transformation represents a singlefunction or process. These are valuable because tracking and documenting how dataassociated with a particular process moves through the system helps analystsunderstand what is going on. The development of models such as data flow modelsshould be a top-down process.2. State machine models describe how a system responds to internal or external events.This type of model is often used for modeling real-time systems since these systems areoften driven by stimuli from systems environment.3. Data flow diagrams 27 28. Software Engineering 2008Data models: Most widely used technique is Entity-relation-Attribute modeling. Defining the logical form of the data processed by the system is called semantic data modeling. Like all graphical models, data models lack detail. One may collect these descriptions in a repository or data dictionary. Advantages of data dictionary are : 1. It is a mechanism for name management. 2. It serves as a store for organizational information.Object models: Here system requirements are expressed using object model, designing using objects and developing the system in an object-oriented programming language. Developing object models during requirements analysis usually specifies the transition to object-oriented design and programming.1. Inheritance model2. Object aggregation3. Object behavior modeling Critical system specificationHigh potential costs of system failure cause the specification for critical systems to accurately reflect the real needs of users of the system. These are the requirements that should be a part of requirements report. 1. Risk driven specification is an approach that has been widely used by safety and securitycritical systems developers. It is applicable to any system where dependability is a criticalattribute. 2. Safety specification process in its first stage defines the scope of the system, assesses thepotential system hazards and estimates the risk they pose. This is followed by safetyrequirements specification and the allocation of these safety requirements to different sub-systems. These requirements are broken into functional safety requirements and safetyintegrity requirements. After delivery, the system must be installed as planned so that thehazard analysis remains valid. 3. Security specifications are based around the assets to be protected and their value. Thesteps involved are asset identification and evaluation of the degree of protection, threatanalysis and risk assessment, threat assignment to the assets, analysis of availabletechnology and finally specification of security requirements. Different types of security 28 29. Software Engineering 2008specifications are authentication and authorization requirements, immunity requirements, intrusion detection requirements, non-repudiation requirements, privacy requirements etc. Requirement ElaborationThe information obtained from the customer during inception and elicitation is expanded and refined. It focuses on developing a refined technical model of software functions, features, and constraints. The end result is an analysis model that defines the informational, functional, and behavioral domain of the problem.Requirement Negotiation It might be that different users have conflicting requirements. To reach a consensus these requirements are prioritized by all parties and the most important requirements become part of the document. Risk associated with each requirement is identified and evaluated. The finalized requirements are used to assess approximate effort, time and cost for the project. Finally the baseline is defined.Requirements documentation1. Requirement definition is a complete listing of everything the customers expects the system to do. It is written jointly by the customer and developer. First we outline the general purpose of the system; next we describe the background and objectives of system development. We outline a description to the solution. Next we describe the detailed characteristics of the proposed system. Finally we discuss the environment in which the system will operate.2. Requirement specification restates the requirements definition in technical terms appropriate for the development of system design. It is written by requirements specialists. The specification document may define the same requirements as in the definition document as a series of equation.Contents of an SRS1. IntroductionThis chapter contains purpose of the document, scope of the document, an overview ofthe requirements and the context in which the document was prepared2. General DescriptionIn this chapter, the proposed product is described in the context of existing systems, usercharacteristics, problems faced, objectives of the proposed system and any knownconstraints.3. Functional Requirements 29 30. Software Engineering 2008 This chapter lists all the functional requirements in the decreasing order of importance. Foreach requirement, a description, criticality, risks and dependencies with otherrequirements is documented.4.Interface RequirementsThis chapter is used to describe the user interfaces, hardware interfaces, communicationsinterfaces and interfaces to other software systems.5.Performance RequirementsSpeed and throughput requirements are described in this requirement6.Design ConstraintsThis chapter specifies the design constraints imposed on the design team and could coverstandards to be complied with, hardware limitations, etc.7.Other Non-Functional AttributesAspects such as security, reliability, maintainability, etc. that are important to the projectare described in this chapter.8.Preliminary Domain AnalysisThis chapter contains the modelling of the proposed system.9.Operational ScenariosThis chapter contains the main scenarios (use cases) that will be experienced from theproposed system.10. Schedule and BudgetsThis chapter can contain the estimates and a high-level project plan.Characteristics of a good Software Requirement Specification 1. Completeness can be aimed by ensuring the following: Elicitation of the requirements from all the stakeholders Focus on user tasks, problems, bottlenecks and improvements required; rather than thesystem functionality Ranking or prioritising each requirement (functional as well as non-functional) forimportance. Marking areas where requirements are not known as To Be Determined Resolving all to be determined requirements before the design phase. 2. Clarity (Unambiguous) is related by following issues Requirements should be reviewed by an independent entity to identify ambiguous useof natural language. Specifications should be written in a requirement specification language. Requirements can also be expressed using requirements analysis and modellingtechniques. 3. Correctness can be assumed if every requirement stated in the SRS is required in the proposed system. All stakeholders need to review the SRS and confirm that the SRS correctly reflects their needs. 4. Consistency can be maintained when any conflict between requirements within the SRS is identified and resolved. Logical conflicts should be identified and removed. 5. Modifiability can be increased by proper documentation. Certain practices that can lead to high modifiability are: Minimal redundancy leads to lower inconsistencies when changes are incorporated. Labelling helps easily identify changed requirements.30 31. Software Engineering 20086. Traceability cab is created by labelling all requirements and following them all through the designing phase, test phase and so on. Fine grained, structured and precise statements are much more preferable to large, narrative paragraphs. Traceability can be backward or Forward. 7. Feasibility should be checked before including any requirement 8. Testability (Verifiability) should be enhanced by stating the requirements correctly. 9. Ranked for importance and/or stability to ensure the most important ones are incorporated early and carefully.Requirement Validation A number of requirements validation techniques can be used in conjunction or individually: 1. Requirements review where requirements are analyzed systematically by a team ofreviewers. The development team should explain all requirements and their implications tothe reviewing team in a formal review. In an informal review, the team interacts withstakeholders to verify requirements. In both cases the team reviews the requirements forconsistency, verifiability, comprehensibility, traceability and adaptability.Conflicts, contradictions, errors and omissions are pointed out by the review team. 2. Prototyping helps to ensure the correct requirements are found. Throwaway prototype,where the prototype is discarded after correcting requirements is prepared, when the notwell understood requirements are significant for system. Otherwise exploratory prototype isbuilt which enhances the prototype once built. 3. Test case generation is a technique which prepares test cases for the requirements andensures that they are correctly stated. 4. Validation can be done by using checks on1. Validity of requirements2. Consistency to avoid contradiction3. Completeness to include all constraints4. Realism check to see if it can be really implemented5. Verifiability ensures that test cases can be generated to check requirementsCommon problems with Software Requirement Specification1. Making Bad Assumptions due to lack of proper or no information.2. Writing implementation (HOW) instead of requirements (WHAT)3. Using incorrect terms such as will not be limited to, such as etc.4. Using Wrong Language which is ambiguous5. Unverifiable Requirements that are written using terms such as maximize, fast,sometimes etc.6. Missing Requirements can be avoided using proper templates7. Over-Specifying or stating unnecessary things 31 32. Software Engineering 2008 Requirements management consists of: 1. Requirements change management which involves systematic handling of changes to agreed requirements (SRS) during the course of the project. Changes occur because there are changes in the business and technical environment and preferences and priorities of users change. Some requirements are enduring, i.e. relatively stable, and there are volatile requirements that change over time. Change management process is as follows:InitiationFurther Impact analysis Impact analysisPending partly rejectedEvaluationapproved PlanningExecutionClosing Change Management process1. Initiation: A change request form (CRF) is filled. It includes why such a change isrequired, what benefits are expected with the change, or what difficulties will befaced without the change. 2. Impact Analysis: The CRF is handed over to the Configuration Controller, who incooperation with others, evaluates the change from various perspectives e.g.technical feasibility, additional resources, additional calendar time, impact oncurrent activities etc. 3. Evaluation: The change is presented in the periodic Change Control Board (CCB)meeting which may accept, reject, partially approve, keep pending or performfurther impact analysis for the proposed change.32 33. Software Engineering 20084. Planning: If CRF is partially or fully approved, the Configuration controller fill supthe implementation plan for implementing the CRF. 5. Execution: changes are made according to the implementation plan. 6. Closing: The CRF is closed after verifying that all changes that were requiredhave been made. 2. Requirements traceability consists of maintaining traceability between the agreed (and changed) SRS and the other work products (like design documents, test plans) created downstream in the software life cycle. Test case TC01TC02TC03TC04 ...... TC49 requirement R-01X X X R-02Xx R-03x X :R-096XThere are three types of traceability information that may be maintained. 1. Source traceability information links the requirements to the stakeholders who proposed the system. 2. Requirements traceability information links dependent requirements within the requirements document. This helps in assessing how many requirements are likely to be affected by a proposed change. 3. Design traceability information links the requirements to the design modules where these requirements are implemented. 3. Tools for requirement documentation are also available. A few area. PSL/PSA: Problem statement language specifies the requirements which are converted into models by the problem statement analyzer.b. RSL/REVS: Requirement statement language specifies the requirement and Requirement engineering validation system processes and analyzes RSL statements. REVS consists of a translator for RSL, Centralized database and a set of automated tools.c. Structured analyses and design technique (SADT) creates a model that consists of a set of ordered SA diagrams.d. Structured System Analysis (SSA) includes data flow diagrams, data dictionaries, and procedure logic representations and data store structuring techniques.Key enablers that drive the maturity of the requirements engineering process are:33 34. Software Engineering 2008 1. Senior management reviews requirements engineering for process compliance2. Independent Software Quality Assurance group reviews requirements engineering for process compliance.3. Project manager monitors the progress of requirements engineering activities4. Requirements engineering responsibility is explicitly assigned in each project.5. Tools required for facilitating requirements engineering activities are explicitly identified, made available and used.6. Persons performing requirements engineering activities are trained/ skilled in the application domain and requirements engineering process. Other project members are provided the appropriate orientation on the application domain and requirements engineering process.7. Tools and resources are available to be able to maintain the requirements related information and documents of past projects that may be re-used. Commandments for Requirements 1.Dont ignore the other side (LISTEN)2.Understand the Domain (CONCEPTS)3.Understand Why They Want it and How Badly (UNDERSTAND THEM BETTER)4.Dont be in a hurry (IT IS THE MOST IMPORTANT STAGE)5.Do not Consider Anything as Obvious (DOCUMENT EVERYTHING)6.Dont Sweep it Under the Carpet (DONT IGNORE ISSUES)7.Dont say Yes when you may need to say No (PROCEDURES FOR CHANGEMANAGEMENT)8. Work as a team9. Dont expect Analysts to Read your Mind10. Dont Just Sign-off without Rigorous SRS ReviewRequirement metrics Requirements can be measured on various parameters. A few commonly used measurable are: Function point metrics is a calculation dependent on the characteristic of requirement. Number of requirements can be used as a measure Number of changes to requirements is measured during the iterations Requirements size looks at the bigger picture of project size and complexity Kinds of requirements are important to be identified, because critical requiremenst aremore difficult to implement.Function point calculation Factor ValueBackup and recovery4 Data Communications2 Distributed processing 0 Performance critical 4 34 35. Software Engineering 2008 Existing operating environment 3On-line data entry 4Input transaction over multiple screens5ILFs updated online3Information domain values complex5Internal processing complex5Code designed for reuse4Conversion/installation design 3Multiple installations 5Application designed for change5Value adjustment factor1.17 Information domainOpt LikelyPessEst. count Weight FP countNo. of external inputs20243024 497No. of external outputs 12152216 578No. of external inquiries 16222822 588No. of internal logical files 4 4 5 410 42No. of external interface files 2 2 3 2715Count total 320FP=count-total*[0.65+0.01*(Fi)] FP=375 35 36. Software Engineering 2008Software Design Design modeling principles 1.Design should be traceable to the analysis model2.Always consider the architecture of system to be built3.Design of data is as important as design of processing functions4.Interfaces (both internal and external) must be designed, with care5.User interface design should be tuned to the needs of the end users6.Component level design should be functionally independent7.Components should be loosely coupled to each other and to external environment8.Design representations (models) should be easily understandable9.The design should be developed iteratively, with each iteration, the design should strive forgreater simplicity. Design Process model Requirement specification Architectural DesignIt represents a critical link between the design and requirements engineering processes. It establishes a basic structural framework that identifies the major components of a system and the communications between these components. 1. Repository model: Large amounts of data are organized around a shared database or repository.36 37. Software Engineering 2008 2. Call and Return: The system is organized as a set of main program and services and associated servers and clients that access and use the services.3. The layered model: It organizes a system into layers, each of which provides a set of services.4. Pipes and Filter: where input from one goes to the other component.5. Object oriented architecture: accomplishes coordination via message passing. There are architectural models that are specific to a particular application domain. There are two types of domain-specific architectural models:1. Generic models are abstractions from a number of real systems.2. Reference models are most abstract and describe a larger class of systemsRepository model Client-server architecture Documenting Architecture Design A document describing the architecture should contain the following:1. System and architecture context2. Description of architecture views 1. Element catalog describes the purpose of the element and its interfaces and their semantic information 2. Architecture rationale gives the reason for selecting the different elements and composing them in the way it was done. 3. Behavior description is added to help aid understanding of the system execution.37 38. Software Engineering 20084. Other information includes description of all those decisions that have not been taken during architecture creation.3. Across views documentationEvaluating Architectures The architectural tradeoff analysis method (ATAM) helps in identifying dependencies between competing properties and performs a tradeoff analysis. The basic ATAM has the following steps: 1. Collect scenarios 2. Collect requirements or constraints 3. Describe architectural views 4. Attribute-Specific analysis 5. Identify sensitivities and tradeoffs: Sensitivity is the impact an element has on the attribute value and tradeoff points are those elements that have sensitivity points for multiple attributes.Design conceptsAbstraction It is a tool that permits a designer to consider a component at an abstract level without worrying about the details of the implementation of the component. It is an important concept for problem partitioning. During the detailed design and implementation, it is essential to implement the modules so that the abstract specifications of each module are satisfied. There are two common abstraction mechanisms: Functional abstraction and Data abstractionModularity A system is considered modular if it consists of discreet components so that each component can be implemented separately, and a change to one component has minimal impact on other components. Modularity helps in system debugging, system repair, and in system building.Cohesion Cohesion of a module represents how tightly bound the internal elements of the module are to one another. There are several levels of cohesion: 1. Coincidental cohesion is the lowest and occurs when there is no meaningful relationship among the elements of a module. 2. Logical cohesion exists if there is some logical relationship between the elements of a module and elements perform functions that fall in the same logical class. 3. Temporal cohesion is same as above except that elements are also related in time and are executed together. 4. Procedural cohesion contains elements in the same procedural unit.38 39. Software Engineering 2008 5. Communicational cohesion has elements related by reference to the same input or output data.6. Sequential cohesion exists when the output of one form is the input to another.7. Functional cohesion binds the elements performing a single function. CouplingCoupling between modules is the strength of interconnections between modules or a measure of interdependence among modules. Coupling increases with the complexity and obscurity of the interface between modules. There are 8 types of coupling: 1. Content coupling occurs when one component modifies data that is internal to anothercomponent. 2. Common coupling occurs when a number of components all make use of a global variable. 3. Control coupling occurs when operation A() invokes operation B() and passes a control flagto B. 4. Stamp coupling occurs when class B is declared as a type for an argument of operation ofclass A 5. Data coupling occurs when operations pass long strings of data arguments. 6. Routine call coupling occurs when one operation invokes another. 7. Type use coupling occurs when component A imports or includes a package or the contentof component B 8. External coupling when a component communicates or collaborates with infrastructurecomponents.Patterns: are existing designs that are standardized and can be used the same format in other designs.Software reuse Almost all artefacts associated with software development, including project plan and test plan can be reused. Some prominent items that can be effectively reused are requirements specification, design, code, test cases, knowledge etc. The software units that are reused may be of radically different sizes like:1. Application system reuse i.e. whole of an application system. It can be vertical reuse, i.e.reused at all levels, or horizontal reuse, where it can be used across domains.2. Component reuse from sub-systems to single objects.3. Generative reuse is the use of components in a specific application domain.4. Object and function reuse e.g. library files Reuse can be black-box reuse, where the product is used as it is. It can also be clear-box reuse, where the product is customized as per the user.Benefits of software reuse1. Increased dependability as the reused software is tested and tried2. Reduced process risk as cost of component is known, thus no error in cost estimation3. Effective use of specialists who develop these reusable software. 39 40. Software Engineering 2008 4. Standards compliance in reusable components5. Accelerated development by reduced production time. Excessive reuse of components can cause design complexities, because of customisation, or compromise in requirements.Software reuse requires consideration of the following points: Component creation: It should be decided in advance what should be created. Component indexing and storing: Classification of reuse components is essential Component search: Component matching the requirements has to be identified correctly Component understanding: Proper understanding of the component is necessary beforeapplying it to use. Component adaptation: Customization should be possible Repository maintenance: New components added should be stored and should be traceable. Increasing reusability Name generalization helps identification with the application of the component Operation generalization increases applicability Exception generalization involves providing for all exceptions that might occur in advance. Component Based Software EngineeringCBSE process 40 41. Software Engineering 2008 User Interface Design To make visual interfaces more attractive, 14 guidelines are laid. The important ones being:1. Limit the number of colors employed and be conservative how these are used.2. Use color change to show a change in system status.3. Use color coding to support the task users are trying to perform.4. Use color coding in a thoughtful and consistent way.5. Be careful about color pairings to avoid eye straining. One should anticipate the background and experience of users when designing error messages. Error messages should be polite, concise, consistent and constructive. Factors to be considered while designing messages are context, experience, skill level, style and culture.User Interface Design process Sometimes the interface is separately prototyped and at times generated iteratively. The three core activities are: 1. User analysis: It is the analysis of user activities. 2. User interface prototyping: There are three approaches for UI prototyping 1. Script driven approach where a script is associated with each element like menu orbutton. 2. Visual programming language allows access to reusable object to develop interfacesquickly 3. Internet-based prototyping using java, which is fast to develop 2. Interface evolution is the process of assessing the usability of an interface and checking that it meets user requirements. Some techniques for UI evaluation are: 1. Questionnaires to users and their views on UI 2. Observation of user at work 3. Snapshots of typical system use 4. Most common errors and most used facilities41 42. Software Engineering 2008 User Interface Design issues Design issues 1. User interaction Styles of interaction depend upon the type of application and user. A few styles are discussed below:1. Direct manipulation using pointer devices like mouse2. Menu selection through direct manipulation3. Form fill4. Command language5. Natural language 2. Information presentation Information can be presented in the form of tables, pictures or graphs. But information should be isolated from presentation. Changing information can be shown graphically. Large pieces of information can be shown visually.Mapping data flow into software architecture Transform flow: Information enters the system along paths that transform external data into an internal form. 1. Review the fundamental system model 2. Review an refine data flow diagram for the software 3. Determine whether the DFD has transform or transaction flow characteristics 4. Isolate the transform centre by specifying incoming and outgoing flow boundaries 5. Perform first level factoring 6. Perform second level factoring 7. Refine the first iteration architecture using design heuristics for improved software quality 42 43. Software Engineering 2008Transaction flow: Information flow is often characterized by a single data item, called a transaction that triggers other data flow along one of many paths. 1. Review the fundamental system model 2. Review and refine data flow diagram for the software 3. Determine whether the DFD has transform or transaction flow characteristics 4. Identify the transaction centre and the flow characteristics along each of the action paths. 5. Map the DFD in a progress structure amenable to transaction processing 6. Factor and refine the transaction structure and the structure of each action path 7. Refine the first iteration architecture using design heuristics for improved software quality. Software Design Approaches 1. Function-oriented design1. The system is viewed as something that performs a set of functions. This functionmay consist of sub-functions which may be split into more detailed sub-functions.2. The system state is centralized and shared among different functions 2. Object-oriented design1. The system is viewed as a collection of objects. The system state is viewed as acollection of objects.2. The system state is decentralized among the objects and each object manages itsown state information.3. Objects have their own internal data which define their state. Similar objectsconstitute a class .4. Objects communicate by message passing.Object oriented Vs Function oriented Function-oriented Object-oriented Basic abstraction are not real world Basic abstraction are real world entities functions State information is distributed among State information is represented in a the objects of the system and objects centralized shared memorycommunicate with messages Functions are grouped together if they No class grouping is performed constitute a higher level function.Pure object oriented development starts from object oriented approach from requirement gathering to design and development. 43 44. Software Engineering 2008 Object oriented design concepts1. Classes and objects are basic building blocks of an OOD. Encapsulation is a property of objects, by which objects encapsulate the data and information it contains and supports a well defined abstraction2. Inheritance is a relation between classes that allows for definition and implementation of one class based on the definition of existing classes. Inheritance can be strict inheritance where all features of the super-class plus additional features exist in base class; or non-strict inheritance, where some features of super-class do not exist in base class and some features are redefined. When a class inherits from more than one class then it is called multiple inheritances. Polymorphism deals with the ability of an object to be of different types.3. Objects communicate by message passing often implemented as calls4. Abstraction is the elimination of the irrelevant and amplification of the essentials.5. Coupling is of three types: 1. Interaction coupling occurs due to methods of a class invoking methods of otherclasses. The worst form of coupling exists if methods directly access internal parts ofother methods. Coupling reduces if methods of a class interact with methods inanother class by directly manipulating instance variables of objects of other classes.Coupling is least if methods communicate directly through parameters. 2. Component coupling refers to the interaction between two classes where a class hasvariables of other class. 3. Inheritance coupling is due to the inheritance relation between classes. The worstform is when a subclass B modifies the signature of a method in B. The leastcoupling scenario is when a subclass only adds instance variables and methods butdoes not modify any inherited ones.6. Cohesion is of three types: 1. Method cohesion focuses on why the different code elements of a method aretogether within the method. 2. Class cohesion focuses on why different attributes and methods are together in thisclass. 3. Inheritance cohesion focuses on why classes are together in a hierarchy. Main tworeasons for inheritance are to model generalization-specialization relationship andfor code-reuse7. Open closed principle states: Software entities should be open for extension, but closed for modification. The inheritance and polymorphism concepts allow extension in behavior of existing classes without changing original classObject oriented analysis and design (OOAD)The fundamental difference between object-oriented analysis (OOA) and object-oriented design (OOD) is that the former models the problem domain, leading to an understanding and specification of the problem, while the latter models to solution to the problem.Detailed design Design can be expressed in any of the following ways:44 45. Software Engineering 2008 1. Process design language (PDL) minmax(infile) ARRAY a DO UNTIL end of input READ an item into a ENDDO max, min:=first item of a DO FOR each item in a IF maxitem THEN set min to item ENDDO END1. Logic/ algorithmic design involves statement of the problem, development of a mathematical model, design of the algorithm, verification of correctness.2. State modeling represents the logical state of an object such as finite state modelSoftware Design Strategies Top-down designAdvantages1. It has a strong focus on specific requirements that help to make a design responsiveto its requirements.Disadvantages1. Component-reuse is missed as the system boundaries are specification oriented2. Misses the benefits of well-structured simple architecture. Bottom-up designAdvantages1. General solution can be reused2. It can hide low-level details of implementationDisadvantages1. It is not so closely related to structure of the problem2. It may not fit a given need3. Hard to construct and thus under-designed4. It leads to proliferation of potentially useful functions rather than the mostappropriate onesMetrics for Software Design (detailed design)1. Cyclomatic complexity for a graph G with n nodes , e edges and p connected components is 1. V(G)=e-n+p 2. The number of regions, 3. The number of decisions+12. Data binding captures the module level concept of coupling. It is defined as a triplet (p, x, q) where p and q are modules and x is a variable within the static scope of both p and q. An used data binding exists when both p and q use the variable x for reference or assignment.45 46. Software Engineering 2008 An actual data binding exist when the module p assigns a value too x and q references xtherefore information flow exists.3. Cohesion metrics CM=i=nC(Ri) where C(Ri)=|S| Dim (S) where |S| is the set of statements and |G|=(no. of|G|dim (G) nodes-1) for a reduced graph and dim() is the dimension of a set of statements which is the max. no. of linearly independent paths for S.Metrics for software design (functional)1. Network metrics focuses on the structure chart. The graph impurity increases with the increase in the number of interactions. Graph impurity=n-e-12. Stability metrics tries to quantify the resistance of the design to ripple effects that are caused by changes in modules. Jx= {modules that invoke x} Jx= {modules invoked by x} Rxy= {passed parameters returned from x to y, y Jx} Rxy= {parameters passed from x to y, y Jx} GRx= {Global data referenced in x} GDx= {Global data defined in x} TPxy= {total number of assumptions made by module y about parameters in Rxy} TPxy= {total number of assumptions made by y called by module x about elements in Rxy} TGx= {total number of assumptions made by other modules about the elements in GDx} Design Logical ripple effect (DLRE) = TGx + TPxy + TPxy Design Stability (DS) = 1/(1+DLREx) Program Design Stability (PDS) = 1/(1+DLREx) 3. Information flow metrics is the amount of interaction with other modules Complexity = fan-in*fan-out + inflow*outflow where Fan-in is the number of modules that call module x Fan-out is the number of modules called by module x Inflow is the amount of information sent to module x Outflow is the amount of information sent out by module xMetrics for software design (object-oriented)1. Weighted methods per class (WMC) WMC=i=nCi where Ci is the complexity of methods Mi(M1, M2..) being all the methods of class. Complexity can be estimated size, interface complexity or data flow complexity.2. Depth of inheritance tree (DIT) is the length of the shortest path from the root of the tree to the node representing C or the number of ancestors C has.3. Number of children (NOC) is the number of immediate subclasses of C 46 47. Software Engineering 2008 4. Coupling between classes (CBC) is the total number of other classes to which the class is coupled.5. Response for a class (RFC) is the cardinality of the response set for a class. The response set of a class C is the set of all methods that can be invoked if a message is sent to an object of this class.6. Lack of cohesion in methods (LCOM) LCOM=|P|-|Q|, if |P|>|Q|, 0 otherwise, where Q is the set of all cohesive pairs of methods and P is the set of non cohesive pairs.Design Verification methods1. Design walkthrough is a manual method of verification and is done in an informal meetingcalled by designer or the leader of the designers group. In a walkthrough designer explainsthe logic step-by-step, and the members of the group ask questions, point out possibleerrors or seek clarification.2. Critical design review ensures that the detailed design satisfies the specification laid downduring system design. The process is same as inspection with aim of revealing design errorsor undesirable properties. The use of checklists ensures focus of discussion on the search oferrors. A sample checklist might include following questions: 1. Does each module in system design exist in detailed design 2. Are all assumptions explicitly stated 3. Are all exceptions handled 4. Is the design standardized 5. Is the module logic too complex 6. Are data structures properly created3. Consistency checkers are essentially compilers that take as input the design specification ina design language. A consistency checker can ensure that any modules invoked or used by agiven module actually exist in the design that the interface used by the caller is consistentwith the interface definition of the called module.The fourth generation technique model encompasses a broad array of software tools that have one thing in common: each enables the software developer to specify some characteristic of the software at a high level. The tool then automatically generated source code based on the developer's specification. The 4GT paradigm for software engineering focuses on the ability to specify software to a machine at a level that is close to natural language or in a notation that imparts significant function, but it tends to be used in a single, well defined application domain. Also the GT approach reuses certain elements, such as existing packages and databases rather than reinventing them.Fourth generation techniques have already become an important part of software development when coupled with CASE tools, the 4GL paradigm may become the dominant approach to software developmentFourth generation Techniques: 1. Report generation47 48. Software Engineering 2008 2.Database query language3.Data manipulation4.Screen definition5.Code generation6.Connectivity and interfacing7.Web designing tool8.Graphics generation capability9.CASE tools10. Reuse of codeSoftware Implementation Coding ProcessThe coding activity starts when some form of design has been done and the specifications of the modules to be developed are available. The programming team must have a designated leader, a well defined organization structure and a thorough understanding of the duties and responsibilities of each team member. The implementation team must be provided with a well defined set of software requirements, an architectural design specification, and a detailed design description. Also, each team member must understand the objectives of implementation. A famous experiment by Weinberg showed that if programmers are specified a clear objective for the program, they usually satisfy it.Incremental Coding Process A code is written for implementing only part of the functionality of the module. This code is compiled and tested with some quick tests to check and when it is passed, the developer proceeds to add further functionality. The advantage is easy identification of error in the code as small parts are tested. Test scripts can be prepared and run each time with new code to ensure the old functionality is still working.Other methods Test driven developmentThe programmer first writes the test scripts then writes the code to pass the tests. Thewhole process is done incrementally. Visual programmingScripting languages such as Visual Basic support visual programming where the prototype isdeveloped by creating a user interface from standard items and associating componentswith these items. A large library of components exists to support this type of development.These may be tailored to suit the specific application requirements Pair programming 48 49. Software Engineering 2008More than one programmer implements the code and thus algorithms are checked in a better way. In XP, programmers work in pairs, sitting together to develop code. This helps develop common ownership of code and spreads knowledge across the team. It serves as an informal review process as each line of code is looked at by more than 1 person. It encourages refactoring as the whole team can benefit from this. Measurements suggest that development productivity with pair progra