Page 1 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , Unit - IV, Software and Software Engineering: Defining Software, Software Application Domains, Software Engineering, Software, Process, Software Engineering Practice, Software Myths. Process Models: A Generic Process Model, Process Assessment and, Improvement, Prescriptive Process Models, Specialized Process Models, Agile Development: Agility, Agility and the cost of, change, Agile Process, Extreme Programming, Other Agile Process Models. Understanding Requirements: Requirements, Engineering, Establishing the Groundwork, Eliciting Requirements, Developing the use cases, Building the Requirements, Model, Negotiating Requirements, Validating Requirements., , ________________________________________________________________________________________________, Software and software engineering, Definition of software:Software is a (1)instructions(computer programs) that when executed provide desired features, functions and, performance;(2)data structures that enable the program the programs to adequately manipulate information;, (3)descriptive information in both hard copy and virtual forms that describes the operation and use of the programs., Software products, A.Generic products, Stand-alone systems that are marketed and sold to any customer who wishes to buy them., Examples – PC software such as editing, graphics programs, project management tools; CAD software; software for, specific markets such as appointments systems for dentists., B. Customized products, Software that is commissioned by a specific customer to meet their own needs., Examples – embedded control systems, air traffic control software, traffic monitoring systems., Features of software:, , , , Software is developed or engineered; it is not manufactured in the classical sense, Software doesn’t “wear out”, Most software are custom built, , Software application domains:, , , , , , , , System software:- a collection of programs written to service other programs(e.g.compilers,editors), Application software:-stand-alone programs that solve a specific business need., Engineering/scientific software:Embedded software:- resides within a product or system and is used to implement and control features and, functions for the end user and for the system itself(e.g., key pad control for a microwave oven), Product-line software:-this is designed to provide specific capabilities for use by different customers., Web application:-these are called web apps, Artificial intelligence software:-these make use of non-numerical algorithms to solve complex problems that are, amenable to computing or straightforward analysis., , SOFTWARE - NEW CATEGORIES,  Open-world computingthe rapid growth of wireless networking may soon lead to true pervasive, distributed, computing., , -1-

Page 2 : GFGC,KGF, S/W ENGINEERING, DEPT OF CS,  Netsourcing—the World Wide Web is rapidly becoming a computing engine as well as a content provider. The, , challenge for software engineers is to architect simple (e.g., personal financial planning) and sophisticated, applications, that provide a benefit to targeted end-user markets worldwide.,  Open source—a growing trend that results in distribution of source code for systems applications (e.g.,, , operating systems, database, and development environments) so that many people can contribute to its, development, , , , , , DATA MINING, GRID COMPUTING, COGNITIVE MACHINES, NANOTECHNOLOGIES, , SOFTWARE ENGINEERING:-to build software, we must recognize a few simple realities:, , , , , , A concentrated effort should be made to understand the problem before a software solution is developed., Software design becomes a pivotal activity., Software should exhibit high quality., Software should be maintainable., , IEEE (INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERING) has developed a comprehensive, definition i.e. the application of a “systematic, disciplined, quantifiable” approach to the development, operation, and maintenance of software., ESSENTIAL ATTRIBUTES OF GOOD SOFTWARE, Product characteristic, Description, Maintainability, , Software should be written in such a way so that it can evolve to meet the changing, needs of customers. This is a critical attribute because software change is an inevitable, requirement of a changing business environment., , Dependability and security, , Software dependability includes a range of characteristics including reliability, security, and safety. Dependable software should not cause physical or economic damage in the, event of system failure. Malicious users should not be able to access or damage the, system., Software should not make wasteful use of system resources such as memory and, processor cycles. Efficiency therefore includes responsiveness, processing time, memory, utilisation, etc., , Efficiency, , Acceptability, , Software must be acceptable to the type of users for which it is designed. This means, that it must be understandable, usable and compatible with other systems that they use., , SOFTWARE ENGINEERING - A LAYERED TECHNOLOGY, Any engineering approach must rest on organizational commitment to quality which fosters a continuous process, improvement culture., Process layer as the foundation defines a framework with activities for effective delivery of software engineering, technology. Establish the context where products (model, data, report, and forms) are produced, milestone are, established, quality is ensured and change is managed., Method provides technical how-to’s for building software. It encompasses many tasks including communication,, requirement analysis, design modeling, program construction, testing and support., Tools provide automated or semi-automated support for the process and methods., , -2-

Page 3 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , Software process:-A software process is a collection of activities, actions and tasks that are performed when some, work product is to be created., Generic process framework:-it encompasses five activities:, , , , , , , Communication, Planning, Modeling, Construction, Deployment, , Umbrella activities for process framework:-typical umbrella activities include:, , , , , , , , , , Software project tracking and control, Risk management, Software quality assurance, Technical reviews, Measurement, Software configuration management, Reusability management, Work product preparation and production, , Software engineering practice:-A generic software process model composed of a set of activities that establishes a, framework for software engineering practice., The essence of practice:, , , , , , Understand the problem, Plan a solution, Carry out the plan, Examine the result for accuracy, , General principles:- DAVID HOOKERS has proposed seven principles that focus on software engineering practice., , , , , , , , , The reason it all exists, KISS (keep it simple, stupid), Maintain the vision, What you produce, others will consume, Be open to the future, Plan ahed for reuse, Think, , Software myths:-these are erroneous beliefs about software and the process that is used to build it., Three types of myths: management myths and customer myths, practitioners’s myths., Management myths:, , , , We already have a book that is full of standards and procedures for building software. Will that not provide us, with everything they need to know?, If we get behind schedule, we can add more programmers and catch up(Mongolian horde concept), If I decide to outsource the software project to a third party, I can just relax and let that firm build it., , Customer’s myths:-, , -3-

Page 4 : GFGC,KGF, S/W ENGINEERING, DEPT OF CS,  A General statement of objectives is sufficient to begin writing programs.,  Software requirements continually change, but change can be easily accommodated because software is, , flexible., Practitioner’s myths:, , , , , Once we write the program and get it work, our job is done., Until I get the program “running” I have no way of accessing its quality., The only deliverable work product for a successful project is the working program., Software engineering will make us create voluminous and unnecessary documentation and will invariably slow, us down., , Process models, Process flow:-it describes how the framework activities and the actions and tasks that occur within each framework, activity organized with respect to sequence., Types of process flow:, , , , , Linear process flow – it executes each of the five framework activities in sequence, beginning with, communication and culminating with deployment., Iterative process flow – repeats one or more of the activities before proceeding to the next., Evolutionary process flow - it executes the activities in circular manner., Parallel process flow – executes one or more activities in parallel with other activities., , Process patterns:- it describes a process related problem that is encountered during software engineering work,, identifies the environment in which the problem has been encountered, and suggests one or more solutions to the, problem., Ambler’s process pattern:- ambler has proposed a template for describing a process pattern:, , , , , , , , , , , Pattern name, Forces, Type(stage pattern, task pattern, phase pattern), Initial context, Problem, Solution, Resulting context, Related patterns, Known uses and examples, , Advantages of process pattern:, , , , An effective mechanism for addressing problems associated with any software process, Enables us to develop a hierarchical process description that begins at a high level of abstraction, A customized process model can be defined by a software team using the patterns as building blocks for the, process model, , Approaches to software process assessment:, , , , , Standard CMMI assessment method for process improvement(SCAMPI), CMM-based appraisal for internal process improvement(CBAIPI), SPICE(ISO/IEC15504), ISO 9001:2000 for software, , PERSPECTIVE PROCESS MODELS:- it is a traditional model., , -4-

Page 5 : GFGC,KGF, S/W ENGINEERING, DEPT OF CS,  1. Waterfall model:-the waterfall model, sometimes called the classic life cycle or linear sequential approach to, , software development that begins with customer specification of requirements and progresses through planning,, modeling, constriction and deployment culminating in ongoing support of the completed software., , The sequential phases in Waterfall model are:, Requirement Gathering and analysis: All possible requirements of the system to be developed are captured in this phase, and documented in a requirement specification doc., System Design: The requirement specifications from first phase are studied in this phase and system design is prepared., System Design helps in specifying hardware and system requirements and also helps in defining overall system, architecture., Implementation: With inputs from system design, the system is first developed in small programs called units, which are, integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing., Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of, each unit. Post integration the entire system is tested for any faults and failures., Deployment of system: Once the functional and non functional testing is done, the product is deployed in the customer, environment or released into the market., Maintenance: There are some issues which come up in the client environment. To fix those issues patches are released., Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the, customer environment., pros, , Cons,  Simple and easy to understand and use,  No working software is produced until late during the life cycle.,  Easy to manage due to the rigidity of the model .,  High amounts of risk and uncertainty., each phase has specific deliverables and a review,  Not a good model for complex and object-oriented projects., process.,  Poor model for long and ongoing projects.,  Phases are processed and completed one at a time.  Not suitable for the projects where requirements are at a moderate to high, risk of changing.,  Works well for smaller projects where requirements,  So risk and uncertainty is high with this process model., are very well understood.,  It is difficult to measure progress within stages.,  Clearly defined stages.,  Cannot accommodate changing requirements.,  Well understood milestones.,  No working software is produced until late in the life cycle.,  Easy to arrange tasks.,  Adjusting scope during the life cycle can end a project.,  Process and results are well documented .,  Integration is done as a "big-bang. at the very end,, which doesn't allow identifying any technological or, bottleneck or challenges early., , -5-

Page 6 : GFGC,KGF, S/W ENGINEERING,  2. V-MODEL:- a variation in the representation of the waterfall model is called the v-model., , DEPT OF CS, , V- Model design, Under V-Model, the corresponding testing phase of the development phase is planned in parallel. So there are, Verification phases on one side of the .V. and Validation phases on the other side. Coding phase joins the two sides of, the V-Model., The below figure illustrates the different phases in V-Model of SDLC., , Verification Phases, Following are the Verification phases in V-Model:, , , , , , , Business Requirement Analysis: This is the first phase in the development cycle where the product, requirements are understood from the customer perspective. This phase involves detailed communication with the, customer to understand his expectations and exact requirement. This is a very important activity and need to be, managed well, as most of the customers are not sure about what exactly they need. The acceptance test design planning, is done at this stage as business requirements can be used as an input for acceptance testing., System Design: Once you have the clear and detailed product requirements, it.s time to design the complete, system. System design would comprise of understanding and detailing the complete hardware and communication setup, for the product under development. System test plan is developed based on the system design. Doing this at an earlier, stage leaves more time for actual test execution later., Architectural Design: Architectural specifications are understood and designed in this phase. Usually more, than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken., System design is broken down further into modules taking up different functionality. This is also referred to as High, Level Design (HLD)., The data transfer and communication between the internal modules and with the outside world (other systems) is clearly, understood and defined in this stage. With this information, integration tests can be designed and documented during, this stage., , , , Module Design:In this phase the detailed internal design for all the system modules is specified, referred to as, Low Level Design (LLD). It is important that the design is compatible with the other modules in the system architecture, and the other external systems. Unit tests are an essential part of any development process and helps eliminate the, , -6-

Page 7 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , maximum faults and errors at a very early stage. Unit tests can be designed at this stage based on the internal module, designs., Coding Phase, The actual coding of the system modules designed in the design phase is taken up in the Coding phase. The best suitable, programming language is decided based on the system and architectural requirements. The coding is performed based, on the coding guidelines and standards. The code goes through numerous code reviews and is optimized for best, performance before the final build is checked into the repository., Validation Phases, Following are the Validation phases in V-Model:, , , , , , , , Unit Testing: Unit tests designed in the module design phase are executed on the code during this validation, phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be, uncovered by unit testing., Integration Testing: Integration testing is associated with the architectural design phase. Integration tests are, performed to test the coexistence and communication of the internal modules within the system., System Testing: System testing is directly associated with the System design phase. System tests check the, entire system functionality and the communication of the system under development with external systems. Most of the, software and hardware compatibility issues can be uncovered during system test execution., Acceptance Testing: Acceptance testing is associated with the business requirement analysis phase and, involves testing the product in user environment. Acceptance tests uncover the compatibility issues with the other, systems available in the user environment. It also discovers the non functional issues such as load and performance, defects in the actual user environment., V- Model Application, V- Model application is almost same as waterfall model, as both the models are of sequential type. Requirements have, to be very clear before the project starts, because it is usually expensive to go back and make changes. This model is, used in the medical development field, as it is strictly disciplined domain. Following are the suitable scenarios to use VModel:, , , , Requirements are well defined, clearly documented and fixed., , , , Product definition is stable., , , , Technology is not dynamic and is well understood by the project team., , , , There are no ambiguous or undefined requirements., , , , The project is short., V- Model Pros and Cons, The advantage of V-Model is that it.s very easy to understand and apply. The simplicity of this model also makes it, easier to manage. The disadvantage is that the model is not flexible to changes and just in case there is a requirement, change, which is very common in today.s dynamic world, it becomes very expensive to make the change., The following table lists out the pros and cons of V-Model:, Pros, This is a highly disciplined model and, Phases are completed one at a time., , Cons, High risk and uncertainty., , Not a good model for complex and, Works well for smaller projects whereobject-oriented projects., requirements are very well understood., , -7-

Page 8 : GFGC,KGF, , S/W ENGINEERING, , Simple and easy to understand and use., , DEPT OF CS, , Poor model for long and ongoing, projects., , Easy to manage due to the rigidity of the, model . each phase has specific deliverables and a, Not suitable for the projects where, review process., requirements are at a moderate to high risk, of changing., Once an application is in the testing, stage, it is difficult to go back and change a, functionality, , No working software is produced, until late during the life cycle., , 3. INCREMENTAL MODEL:, In incremental model the whole requirement is divided into various builds. Multiple development cycles take place, here, making the life cycle a“multi-waterfall” cycle. Cycles are divided up into smaller, more easily managed modules., Each module passes through the requirements, design, implementation and testingphases. A working version of, software is produced during the first module, so you have working software early on during the software life cycle., Each subsequent release of the module adds function to the previous release. The process continues till the complete, system is achieved., For example:, , In the diagram above when we work incrementally we are, adding piece by piece but expect that each piece is fully finished. Thus keep on adding the pieces until it’s complete. As, in the image above a person has thought of the application. Then he started building it and in the first iteration the first, module of the application or product is totally ready and can be demoed to the customers. Likewise in the second, iteration the other module is ready and integrated with the first module. Similarly, in the third iteration the whole, product is ready and integrated. Hence, the product got ready step by step., Diagram of Incremental model:, , -8-

Page 9 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , Advantages of Incremental model:, , , Generates working software quickly and early during the software life cycle., , , , This model is more flexible – less costly to change scope and requirements., , , , It is easier to test and debug during a smaller iteration., , , , In this model customer can respond to each built., , , , Lowers initial delivery cost., , , , Easier to manage risk because risky pieces are identified and handled during it’d iteration., , Disadvantages of Incremental model:, , , Needs good planning and design., , , , Needs a clear and complete definition of the whole system before it can be broken down and built, incrementally., , , , Total cost is higher than waterfall., , EVOLUTIONARY MODELS, Software system evolves over time as requirements often change as development proceeds. Thus, a straight line to a, complete end product is not possible. However, a limited version must be delivered to meet competitive pressure., Usually a set of core product or system requirements is well understood, but the details and extension have yet to be, defined., You need a process model that has been explicitly designed to accommodate a product that evolved over time., It is iterative that enables you to develop increasingly more complete version of the software., Two types are introduced, namely Prototyping and Spiral models., 1. PROTOTYPING MODEL, , -9-

Page 10 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , In Prototyping model, a prototype of the system is developed first keeping in view the requirements of the client. It will, try to implement only few important requirements of the client and will be given to the client for evaluation. After, evaluating this prototype, System Analyst will ask the client for modifications and additions that he is expecting.This, cycle of Development, Evaluation and Modification will be repeated a number of times to produce the final software., The software analyst and the client together define the overall objective for the software, identify the requirements that, are known and outline area for further modification. The iteration is planned and modeled in quick design.The design, focuses only on the aspects which are visible to the user. The quick design leads to the construction of a prototype. The, prototype is evaluated by the customer. The feedback is taken and used to refine the requirements for the software. The, iteration continue each time refining the software., ADVANTAGE:, 1) When prototype is shown to the user, he gets a proper clarity and 'feel' of the functionality of the software and he can, suggest changes and modifications., 2) This type of approach of developing the software is used for non-IT-literate people. They usually are not good at, specifying their requirements, nor can tell properly about what they expect from the software., 3) When client is not confident about the developer's capabilities, he asks for a small prototype to be built. Based on, this model, he judges capabilities of developer., 4) Sometimes it helps to demonstrate the concept to prospective investors to get funding for project., 5) It reduces risk of failure, as potential risks can be identified early and mitigation steps can be taken., 6) Iteration between development team and client provides a very good and conductive environment during project., 7) Time required to complete the project after getting final the SRS reduces, since the developer has a better idea about, how he should approach the project., DISADVANTAGE, 1) Prototyping is usually done at the cost of the developer. So it should be done using minimal resources. It can be done, using Rapid Application Development (RAD) tools. Please note sometimes the start-up cost of building the, development team, focused on making prototype, is high., 2) Once we get proper requirements from client after showing prototype model, it may be of no use. That is why,, sometimes we refer to the prototype as "Throw-away" prototype., 3) It is a slow process., 4) Too much involvement of client, is not always preferred by the developer., 5) Too many changes can disturb the rhythm of the development team., 2. Spiral Model, Spiral model is a meta-model, that is model for other models. Spiral Model includes risk analysis also. Each phase, i.e., Requirement Analysis, Design or Coding should iterate through four activities, , Planning, , , Evaluate Alternatives, , , , Analyze Risks, , , , Engineering, , - 10 -

Page 11 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , This model is based on the advantages of Waterfall model and Prototyping Model. The spiral model combines the, iterative nature of the prototyping model and the controlled,systematic nature of the waterfall model. The model has a, series of improved vesrions of the software in form of prototypes, as it is being developed. The later protypes are, nearing towards the complete versions of the software to be produced., The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals., Identification:This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals, as the product matures, identification of system requirements, subsystem requirements and unit requirements are all, done in this phase., This also includes understanding the system requirements by continuous communication between the customer and the, system analyst. At the end of the spiral the product is deployed in the identified market., Design: Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical, design of modules, physical product design and final design in the subsequent spirals., Construct or Build: Construct phase refers to production of the actual software product at every spiral. In the baseline, spiral when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in, this phase to get customer feedback., Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software, called build is produced with a version number. These builds are sent to customer for feedback., Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and monitoring technical feasibility and, management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the, customer evaluates the software and provides feedback., Pros, Cons, Changing requirements can be accommodated., End of project may not be known early., Not suitable for small or low risk projects and could, Allows for extensive use of prototypes, be, expensive, for small projects., Requirements can be captured more, Process, is complex, accurately., Spiral, may, go indefinitely., Users see the system early., Large number of intermediate stages requires, Development can be divided into smaller, excessive, documentation., parts and more risky parts can be developed earlier, Management, is more complex., which helps better risk management., CONCURRENT MODEL, , - 11 -

Page 12 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , Allow a software team to represent iterative and concurrent elements of any of the process models. For example, the, modeling activity defined for the spiral model is accomplished by invoking one or more of the following actions:, prototyping, analysis and design., The Figure shows modeling may be in any one of the states at any given time. For example, communication activity has, completed its first iteration and in the awaiting changes state. The modeling activity was in inactive state, now makes a, transition into the under development state. If customer indicates changes in requirements, the modeling activity moves, from the under development state into the awaiting changes state., Concurrent modeling is applicable to all types of software development and provides an accurate picture of the current, state of a project. Rather than confining software engineering activities, actions and tasks to a sequence of events, it, defines a process network. Each activity, action or task on the network exists simultaneously with other activities,, actions or tasks. Events generated at one point trigger transitions among the states., , SPECIALIZED PROCESS MODELS, Component based development—the process to apply when reuse is a development objective ( like spiral model), Formal methods—emphasizes the mathematical specification of requirements ( easy to discover and eliminate, ambiguity, incompleteness and inconsistency), Aspect Oriented software development (AOSD)—provides a process and methodological approach for defining,, specifying, designing, and constructing aspects, Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned, with the Unified Modeling Language (UML) to model and develop object-oriented system iteratively and incrementally., AGILE DEVELOPMENT, What is agile development?, Agile software engineering combines a philosophy and a set of development guidelines. The development stress, delivery over analysis and design, and active and continuous communication between developers and customer., Agile process: - Any agile software process is characterized in a manner that addresses a number of, Key assumptions about the majority of software projects:-, , - 12 -

Page 13 : GFGC,KGF, S/W ENGINEERING, DEPT OF CS,  It is difficult to predict in difficult to predict how customer advance which software requirements will persist, , , , , and which will change. It is equally priorities will change as the project proceeds, For many types of software, design and construction are interleaved. That is, both activities should be, performed in tandem so that design models are proven as they are created. It is difficult to predict how much, design is necessary before construction is used to prove the design., Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might, like, , Agility principles:-there are 12 agility principles:, , , , , , , , , , , , , Our highest priority is to satisfy the customer through early and continuous delivery of valuable software., Welcome changing requirements, even late in development. Agile processes harness change for the customer’s, competitive advantage., Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the, shorter timescale, Business people and developers must work together daily throughout the project., Build projects around motivated individuals. Give them the environment and support they need, and trust them, to get the job done., The most efficient and effective method of conveying information to and within a development team is face-toface conversation., Working software is the primary measure of progress., Agile processes promote sustainable development. The sponsors, developers, and users should be able to, maintain a constant pace indefinitely., Continuous attention to technical excellence and good design enhances agility., Simplicity—the art of maximizing the amount of work not done—is essential., The best architectures, requirements, and designs emerge from self– organizing teams., At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior, accordingly, , Human factors :, , , , Competence:- In an agile development “competence” encompasses innate talent, specific software-related, skills, and overall knowledge of the process that the team has chosen to apply. Skill and knowledge of process, can and should be taught to all people who serve as agile team members., Common focus. Although members of the agile team may perform different tasks and bring different skills to, the project, all should be focused on one goal—to deliver a working software increment to the customer within, the time promised. To achieve this goal, the team will also focus on continual adaptations (small and large) that, will make the process fit the needs of the team., Collaboration. Software engineering (regardless of process) is about assessing, analyzing, and using, information that is communicated to the software team; creating information that will help all stakeholders, understand the work of the team; and building information (computer software and relevant databases) that, provides business value for the customer. To accomplish these tasks, team members must collaborate—with, one another and all other stakeholders., Decision-making ability. Any good software team (including agile teams) must be allowed the freedom to, control its own destiny. This implies that the team is given autonomy—decision-making authority for both, technical and project issues., Fuzzy problem-solving ability. Software managers must recognize that the agile team will continually have to, deal with ambiguity and will continually be buffeted by change. In some cases, the team must accept the fact, that the problem they are solving today may not be the problem that needs to be solved tomorrow. However,, lessons learned from any problem-solving, Mutual trust and respect. The agile team must become what is called “jelled” team . A jelled team exhibits the, trust and respect that are necessary to make them “so strongly knit that the whole is greater than the sum of the, parts., Self-organization. In the context of agile development, self-organization implies three things:, , 1., 2., , The agile team organizes itself for the work to be done, The team organizes the process to best accommodate its local environment, , , , , , , , , , , , - 13 -

Page 14 : GFGC,KGF, S/W ENGINEERING, 3. The team organizes the work schedule to best achieve delivery of the software increment, , DEPT OF CS, , Extreme programming:- Beck defines a set of five values that, , establish a foundation for all work performed as part of XP—communication, simplicity, feedback, courage, and, respect. Each of these values is used as a driver for specific XP activities, actions, and tasks. In order to achieve, effective communication between software engineers and other stakeholders (e.g., to establish required features and, functions for the software), The key XP activities:, , , , , Planning, Design, Coding, Testing, , Industrial XP:, , , , , , , , , , , Reading assessment, Project community, Project chartering, Test-driven management, Retrospectives, Continuous learning, SSD:story-driven development, DDD:domain-driven design, Pairing, Iterative usability, , The XP debate :, , , Requriments volatility, Conflicting customer needs, , - 14 -

Page 15 : GFGC,KGF, S/W ENGINEERING,  Requirements are expressed informally,  Lack of formal design, , Other agile process models:, , , Adaptive software development (ASD), , , , , , Speculation, Collaboration, Learning, adapt ive cycle planning, uses mission st at ement, project const raint s, basic requirement s, , Requirement s gat hering, JAD, mini-specs, , t ime-boxed release plan, , Release, sof t w are increm ent, adjust m ent s f or subsequent cy cles, , , , Scrum, , , , , , , Backlog, Sprints, Scrum meetings, Demos, , component s implement ed/ t est ed, focus groups for feedback, formal t echnical reviews, post mort ems, , , , , Dynamic system development method(DSDM), , - 15 -, , DEPT OF CS

Page 16 : GFGC,KGF, , , , , , , S/W ENGINEERING, , Feasibility study, Business study, Functional model iteration, Implementation, , , , , Crystal, , Proposed by Cockburn and Highsmith, Crystal—distinguishing features, Actually a family of process models that allow “maneuverability” based on problem characteristics, Face-to-face communication is emphasized, Suggests the use of “reflection workshops” to review the work habits of the team, , , Feature driven development(FDD), , Originally proposed by Peter Coad et al as a object-oriented software engineering process model., FDD—distinguishing features, , , , , , , , , , , Emphasis is on defining “features” which can be organized hierarchically., a feature “is a client-valued function that can be implemented in two weeks or less.”, Uses a feature template, <action> the <result> <by | for | of | to> a(n) <object>, E.g. Add the product to shopping cart., Display the technical-specifications of the product., Store the shipping-information for the customer., A features list is created and “plan by feature” is conducted, Design and construction merge in FDD, , - 16 -, , DEPT OF CS

Page 17 : GFGC,KGF, , , , S/W ENGINEERING, , DEPT OF CS, , Lean software development(LSD), , , , , , , , , Eliminate waste, Build quality, Create knowledge, Refer commitment, Deliver fast, Respect people, Optimize the whole, , , , Agile modeling(AM), , , , , , , , , model with a purpose, use multiple models, travel light, content is more important than representation, know the models and tools you use to create them, adapt locally, , , , agile unified process(AUP), , , , , , , , , modeling, implementation, testing, deployment, configuration and project management, environment management, , UNDERSTANDING REQUIREMENTS:, REQUIREMENT ENGINEERING, The broad spectrum of tasks and techniques that lead to an understanding of requirements is called requirements, engineering., , - 17 -

Page 18 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing, need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the, specification, and managing the requirements as they are transformed into an operational system., Requirement Engineering Task:, It encompasses seven distinct tasks: inception, elicitation, elaboration, negotiation, specification, validation, and, management., Inception: most projects begin when a business need is identified or a potential new market or service is discovered., Stakeholders from the business community (e.g., business managers, marketing people, product managers) define a, business case for the idea, try to identify the breadth and depth of the market, do a rough feasibility analysis, and, identify a working description of the project’s scope., At project inception, we establish a basic understanding of the problem, the people who want a solution, the nature of, the solution that is desired, and the effectiveness of preliminary communication and collaboration between the other, stakeholders and the software team., Elicitation:objectives for the system or product identified, Christel and Kang [Cri92] identify a number of problems that are encountered as elicitation occurs., Problems of scope, Problems of understanding, Problems of volatility, Elaboration:, The information obtained from the customer during inception and elicitation is expanded and refined during elaboration., This task focuses on developing a refined requirements model that identifies various aspects of software function,, behavior, and information., Elaboration is driven by the creation and refinement of user scenarios that describe how the end user (and other actors), will interact with the system., Negotiation:Customers, users, and other stakeholders are asked to rank requirements and then discuss conflicts in, priority. Using an iterative approach that prioritizes requirements, assesses their cost and risk, and addresses internal, conflicts, requirements are eliminated, combined, and/or modified so that each party achieves some measure of, satisfaction., Specification:In the context of computer-based systems (and software), the term specification means different things to, different people. A specification can be a written document, a set of graphical models, a formal mathematical model, a, collection of usage scenarios, a prototype, or any combination of these., Software Requirements Specification Template:, Software Requirements Specification (SRS) is a document that is created when a detailed description of all aspects of, the software to be built must be specified before the project is to commence. It is important to note that a formal SRS is, not always written. In fact, there are many instances in which effort expended on an, SRS might be better spent in other software engineering activities. However, when software is to be developed by a, third party, when a lack of specification would create severe business issues, or when a system is extremely complex or, business critical, an SRS may be justified., , - 18 -

Page 19 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , Validation:, The primary requirements validation mechanism is the technical review. The review team that validates requirements, includes software engineers, customers, users, and other stakeholders who examine the specification looking for, errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies, (a major problem when large products or systems are engineered), conflicting requirements, or unrealistic, (unachievable) requirements., Requirements management:, Requirements for computer-based systems change, and the desire to change requirements persists throughout the life of, the system. Requirements management is a set of activities that help the project team identify, control, and track, requirements and changes to requirements at any time as the project proceeds, Establishing The Groundwork:, The steps required to establish the groundwork for an understanding of software requirements—, Identifying Stakeholders, Recognizing Multiple Viewpoints, Working toward Collaboration, Asking the First Questions, ELICITING REQUIREMENTS:, Requirements elicitation (also called requirements gathering) combines elements of problem solving, elaboration,, negotiation, and specification., Collaborative Requirements Gathering, Quality Function Deployment, Usage Scenarios, Elicitation Work Products, A. Collaborative Requirements Gathering:, Many different approaches to collaborative requirements gathering have been proposed., Meetings are conducted and attended by both software engineers and other stakeholders., • Rules for preparation and participation are established., • An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free, flow of ideas., , - 19 -

Page 20 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , • A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting., • A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room,, or virtual forum) is used, B. Quality Function Deployment:, Quality function deployment (QFD) is a quality management technique that translates the needs of the customer into, technical requirements for software., QFD “concentrates on maximizing customer satisfaction from the software engineering process”, QFD identifies three types of requirements [Zul92]:, Normal requirements. The objectives and goals that are stated for a product or system during meetings with the, customer. If these requirements are present, the customer is satisfied. Examples of normal requirements might be, requested types of graphical displays, specific system functions, and defined levels of performance., Expected requirements. These requirements are implicit to the product or system and may be so fundamental that the, customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction. Examples of, expected requirements are: ease of human/machine interaction, overall operational correctness and reliability, and ease, of software installation., Exciting requirements. These features go beyond the customer’s expectations and prove to be very satisfying when, present. For example, software for a new mobile phone comes with standard features, but is coupled with a set of, unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight every user of the product, C. Usage Scenarios:, it is difficult to move into more technical software engineering activities until you understand how these functions and, features will be used by different classes of end users, To accomplish this, developers and users can create a set of scenarios that identify a thread of usage for the system to be, constructed., The scenarios, often called use cases, provide a description of how the system will be used., D. Elicitation Work Products, For most systems, the work products include,  • A statement of need and feasibility.,  • A bounded statement of scope for the system or product.,  • A list of customers, users, and other stakeholders who participated in,  requirements elicitation.,  • A description of the system’s technical environment.,  • A list of requirements (preferably organized by function) and the domain,  constraints that apply to each.,  • A set of usage scenarios that provide insight into the use of the system or,  product under different operating conditions.,  • Any prototypes developed to better define requirements., BUILDING OF REQUIREMENT MODEL:, The intent of the analysis model is to provide a description of the required informational,, functional, and behavioral domains for a computer-based system., 1. Elements of the Requirements Model:, set of generic elements is common to most requirements models., A. Scenario-based elements. The system is described from the user’s point of view using a scenario-based approach., For example, basic use cases and their corresponding use-case diagrams evolve into more elaborate, template-based use cases. Scenario-based elements of the requirements model are often the first part of the model, that is developed. As such, they serve as input for the creation of other modeling elements., B. Class-based elements. Each usage scenario implies a set of objects that are manipulated as an actor interacts with, the system. These objects are categorized into classes—a collection of things that have similar attributes and, common behaviors., C. Behavioral elements. The behavior of a computer-based system can have a profound effect on the design that is, chosen and the implementation approach that is applied. Therefore, the requirements model must provide modeling, elements that depict behavior., D. Flow-oriented elements. Information is transformed as it flows through a, computer-based system. The system accepts input in a variety of forms, applies functions, , - 20 -

Page 21 : GFGC,KGF, , S/W ENGINEERING, , DEPT OF CS, , to transform it, and produces output in a variety of forms., 2. NEGOTIATING REQUIREMENTS:, In most cases, stakeholders are asked to balance functionality, performance, and other product or system, characteristics against cost and time-to-market. The intent of this negotiation is to develop a project plan that meets, stakeholder needs while at the same time reflecting the real-world constraints (e.g., time, people, budget) that have, been placed on the software team., Boehm [Boe98] defines a set of negotiation activities at the beginning of each softwareprocess iteration. Rather than, a single customer communication activity, the following activities are defined:, 1. Identification of the system or subsystem’s key stakeholders., 2. Determination of the stakeholders’ “win conditions.”, 3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all, concerned (including the software team)., 3. VALIDATING REQUIREMENTS, As each element of the requirements model is created, it is examined for inconsistency,, omissions, and ambiguity. The requirements represented by the model are prioritized by the stakeholders and, grouped within requirements packages that will be implemented as software increments. A review of the, requirements model addresses the following questions:, • Is each requirement consistent with the overall objectives for the, system/product?, • Have all requirements been specified at the proper level of abstraction? That, is, do some requirements provide a level of technical detail that is inappropriate, at this stage?, , - 21 -