[MSBTE| "Strictly as per new revised syllabus of ‘I’ Scheme wefi academic year 2018-2019 - Software Engineering | (Code : 22413) Second Year Diploma - Semester IV Computer Engineering Program Group / Information Technology (CO/CM/IF/CW) S.Y. Diploma 25] chaplerwise MSBTE Questions|&)Answers) t ©) Scheme eeSottware Enginooring (MSBTE - Som fabhe of Contents aaa] Y——Syfiebus Tople: Agle Sofware Development - Agus Chanter 1: Introduction to Software Engineering ena | 1.8 Process Models I-10 1-20 pment, scrum, Dynamic velopment Method (OSDM), eryetal. Solecion era model tea 123 13 t9.1 132 Aetitios of Sotware Engineering. 1.8.3 Neo of Sotware Engineenng. ‘Syllabus Tople : Software M4 14a toa Procnss and a Import oun (Other Aghle Process Model. — 120 ‘Syllabus Tope : Adaptive Software Development... 1-21 121 ‘Serum. Syllabus Tople : Dynamic Systems Development Mettod (OSDM).... a 128 Syllabus Topic : Selection Cteria or Software Process Model 15 1a ¥ Sytiabus Topic Process Modes, 16 16.1 1.62 1.6.21) 16.218) 163 164 Syllabus Tople : Spociaized Procoss Models. 1.7 Speciatized Process Models... 1.71 Component - Based Devolopmont 172 The Formal Methods Model , 1.7.3 Aspoct-Oriented Software Development. 1.74 The Unitiod Procoss.. Syllabus Tople : Core Principles.252 26 261 262 27 28 es 282 283 214 area Design Modeling Principles a Syllabus Tople : Construction Practices! Principles 2-8 ‘Software Deployment (Statement and Meaning of ‘each Principle for each Practice... ‘Syliabus Tople : Requirement Engineering ‘Syllabus Tople : Requirement Analysis. 32 pices NA | OEY Syllabus Tople : Types of Requrements (Functional, | 32:2 Product, Organizational, Extemal Requirements) % 32! 324 ‘Non Functional Requirements (NFR). sytabus Topic: Typas of Non-Funcional Reguirements: Sree Onrizatonal, Exiomal Reqiremerts..2-16 | ~ “Types of Non-Functona! Reqarements 246 | 39? Domain Roque a es syttabus Topic : Butdng Requirement Model. ° Busting Regutrament Moda ae Sylabus Topic : Developing Use Cases . Developing Use C8809 mmm aaa as Requirement Specification: fe . ieas''| 80 Vasication.. < Syllabus Tope : Softwore Nood ot SRS. a ‘Software Requiremont Spociication : Need of SRS..2-23, ‘Advantages of SRS... Syllabus Tople : Characteristics of SRS. Characteristics of SAS. ‘Syltabus Tople : Data Mosoting Mapping Cardinaliies ‘syllabus Tople : Analysis Moding Analysis Modeling Ary Pubes of TRUM om Syllabus Tople : Elements of Anatyets Modo nn 38 Syllabus Tople : Fundamental Dasign Concepts (Abstraction, information Hiding, Structure, Mooksarty, 38a7 38 aa1 a2 391 a92 393 310 sa01 an aaa siz su21 122+ sas. 3194 au32 9.13.2(A) Characteristics of good tast cases... 3133 ‘Syilebue Topi: Testng Meaning and Purpose. Testing Meaning and Purpose. ‘Testing Principles and Objectives. ‘Advantages of Software Testing ‘Software Testing Process. ‘Methods used in Bteck Box Testing. ‘Syllabus Topic : Testing Mothod : White Box. Testing. a | White Box Testing nn 323 Ditlorence between White Box Testing and Black Box Testing... - Syllabus Topic: Testing Mothod: Level of Testing - Unit Testing . Level of Testing - Unit Testing. ‘Stubs and Drivers in Unit Testing. {stot Eros Detected by Uni Testing Syllabus Tople : Test Documentation. ‘Test Documentation Syllabus Tople : Test Pian. Tost Plan. . ‘Syltabus Tope : Test Case Template. Tost Case Template. Syllabus Topi : intoduction to Detect Report.....:28 Introduction o Detect Report. 8.13.4(8) Guidefines to Generate Test Summary Report... 3-30 313.4(C) Contos ofa Test Summary Report jbus ; The management spectrum - 4P's, Metrics for She Estnaton Lin of Code (a0), Function Poa, Project Cost Estimation Approaches : Overview of Heuristic, Analytical and Empitical Estimation, COCOMO. {Constructive Cost Mode), COCOMO II, Fisk Management + Risk Identification, Risk Assessment, Risk Containment, Mois for Size Estimation ‘Syllabus Topic : Overview of Analytical Estimation ..4-5 Overview of Analytical Estimation... Syllabus Topte : Overview of Empirical Estimation... 4-7. Overview of Empirical Estimation nT Syliabue Tope : COCOMO (Constructive Cost Mode), cocomo A COcoMo (Consiretve Cost Meda), COCOMO I. 4a Syllabus Tople: Fisk Management. a0 Srtabue Tope: ra Saag) MM Stayee ‘Grapter 5: Software Quality Assurance and Security 5-1 10 5.27, —— ‘gylabue : Project Scheduling : Basle principle, Work breakdown enucture, Activity notwork and crtical path method, scheduling techniques (CPM, PERT), Project tracking : Timoline charts, emed valve analysis, Gant! Charts, Software Quality Management vs. Software Quality Assurance, Phases of Sofware ‘Quslty Assurance : Planning, Activities, auc, and review, Quality Evaluation standards: Six Sigma, 1SO for software, CMMI: Levels, Process aroas, Software Security Introduion to DevOps, Secure software engineering. : 7 Syllabus Tople : Project Scheduling. 561 Project Scheduting.. 7 Syllabus Tople : Principle of Work Break Down Structure, 541 Basic Principle of Work Braake Down Structure. 5.1.2 Reasons for creating a WBS ina project ¥—— Syllabua Tople : Scheduling Technique, 52 ~ Scheduling Technique. Technique. s+ 5.22 Program Evaluation and Review Techniques 5-4 ’ ‘Syllabus Topic : Project Tracking.. 53 Project Tracking... 534 Timeline Charts. ‘Syllabus Topic : Earved Value Analysis... 54 5105 5Ad v 642 Bat 543 Batt sate 55 5113 551 552 Implementation of te Quilty Assurance... Review the Process... osponsibiltiesroles in a Six Sigma. ‘Syllabus Tople : ISO For Software 1S0 For software. ‘Software Development Challenge... ISO/IEC 9128, ISOTIEC s241-11, 1S0 / TEC 25000:2066..... 180 /HEC 12119.‘CMMI: Level, Procens, Aroas Aevmatire ve Mature Orgarizaton... (Cu and Processes. (Compartaon of CMM and CMMI. 5141 516 5154 5182 6183 DovOps Litecyte. ‘Syllabus Tople : Secure Sofware Engineering. ‘Secure Sofware Engineering... What a Securtty Testing 7 Preventive Measures ann Install anti-Arus software. (Crt he TT nT Let of Programs abt tL ‘goaIntroduction to Software Engineering and Process Models Software, Software engineering as layered approach and its characteristics, types of software. Software development framework, software process framework, process models: perspective process models, specialized process models. ‘Agile software development: Agile process and its importance, extreme programming, Adaptvo software davelopment. ‘scrum, Dynamic Systems Development Mathod (SOM), crystal. Selection criteria for softwaro process model. Syllabus Topic : Software 1.1 Software > (MSBTE - S-17, W-17) Computer ‘software, or simply sofware, is a generic | term that refers to a collection of data or computer: instmetions that tll the compoter how to work, in | = In computer “science and software engineering, computer software is all the information processed by computer systems, programs and data. “= Computer software includes computer programs, libraries and related non-executable data, such as online documentation or digital media. = Computer hardware and software require each other and neither can be realistically used on its own. — At the lowest level, executable code consists of machine language instructions specific to an individual processor-typically a Central Processing Unit (CPU). ‘A machine language consists of groups of binary values signifying processor instructions that change the state of the computer from its preceding state. For example, an instruction may change the value stored in a particular storage location in the computer - ‘an effect that is not directly observable to the user. ‘An instruction may also (indirectly) causes something ‘to appear on a display of the computer system - a state ‘change which should be visible to the user. ‘The processor carries out the instructions in the order they are provided, unless it is instructed to "jump" to a different instruction, or is interrupted by the operating system. ‘The majority of software is written in high-level programming languages that are easier and more efficient for programmers to use because they are closer than machine languages to natural languages. High-level languages are translated into machine language using a compiler or an interpreter or ‘combination of both. Software may also be weitten in a low-level assembly Ianguage, which has strong correspondence to the ‘computer's machine language instructions and is translated into machine language using an assembler.ane BPE sonar — 12 retina Somsies data. It also helps Fig. 1.1.1 : User interaction with application = Above diagram shows how the user interacts with application software on a typical desktop computer. ‘The application software layer interfaces with the ‘operating system, which in tum communicates with the hardware. The arrows indicate information flow. 1.2 Nature of Software — Nowadays the software is not only remains a product, it also becomes an interface for delivering a product. — As a product, software is able to deliver the computing potential which is basically embodied by computer hardware or precisely we can say, by a network of computers which one can access through local hardware. Software is considered as an information transformer or producer irrespective of whether it resides within a ‘smart phone or functions inside a mainframe computer. = Just like any transport vehicle, software can work as the "basis for the control of the computer (operating systems), the transport of information (networks), and the generation and management of other programs (such as various software tools). = Information delivery is the most important aspect of software, To make any data more useful in a local sform the context, software can trans! i sn improving tbe compettivencss of = business by ‘managing the business information. ‘Over the last half-century, significant changes are ‘occurred in the role of computer software. Nowadays the software becomes more sophisticated as well as complex because of various aspects such as spectacular improvements in hardware performance, tremendous up gradations in computing architectures, ‘huge enhancements in memory and storage capacity, and extensive diversity of exotic input and output options. Sophistication as well as complexity leads to amazing results on success of systems, but they may also lead to huge problems for those who want to develop complex systems. In the economies of the industrialized world, the big software industry is considered as a dominant factor. In an earlier era, software was developed individually. Now days an entire team works for it.in which every person is responsible for one part of the technology which is necessary to deliver a complex application, 1.2.1. Defining Software > (MSBTE- 5-16)‘Sofware (MSBTE - Som 4. = Now to understand the software exactly we have 10 examine some characteristics of it which make it ifferent from remaining human made things. ‘Software ix considered ax logical rather than a physical system element. Hence, there are characteristics of software which are significantly different than those of hardware. ‘Syllabus Topic : Characteristics of Software \ 19 Characteristics of Sotware D> (MSBTE - W-14, W-15, S-18, W-17) > 1. Softwares developed or engineered; itis not ‘mannfactored in the classical sense ven though there are some similarities found software development and hardware manufacturing, both the activities are considered as fundamentally different. In both of the activities, good design is base for high quality, but in the process of manufacturing there may be quality problems in hardware which may not present in case of software. 13 Introduction 1o Softwar = Ta both of the activities there is prominent dependency ‘on people but there is vast difference in the relationship between people and work accomplished. ‘The main aim of both the activities is construction of a “product,” but the perspectives are not same. Software costs are concentrated in engineering which indicates that it is difficult to manage software projects imilar to manufacturing projects. 2 Software doesn't “wear out” > qussTe-s-18) In case of hardware, the failure rates are high as Such failures are mainly concerned with design or manufacturing defects. Itis possible to comect the defects and drop the failure rate to a steady-state level for some time period. ‘However after some time period, there is again increase in the failure rate as there are cumulative effects of dust, vibration, mishandling, tremendous high or low temperature, and number of other environmental maladies on components of hardware. In simple words, the hardware begins to wear out. Software does not have any risks of such environmental maladies which lead to wear out of hardware. In early life of software there may be high failure rates __ because of undiscovered defects. However, these can be corrected. ‘Now it is clear that there is no possibility of software ‘wear out but it does deteriorate. In it life change is an integral part of software. Whenever any change is made, there is possibility of introduction of errors which increase the failure rate. Before the software gets consistent state by corrections, ‘any new change’get introduced which again increases the failure rate, Gradvally, the lowest failure rate level stars to increase which indicates that the software is deteriorating due to change.eee (MSBTE - Sem 4—Comp\T) 1-4 ~ There is one Important difference in hardware and software regarding wear aspect is that in case of hardware, a failed component can be replaced by spare Parts. This facility is not available in software as there are no such spare parts. ~ Allthe software failures point out that there is an error in design or in the method by which the respective sesign was transformed into machine executable code. ~ Hence the tasks of software maintenance which handles ‘quests for change has significantly more complexity 25 compared to hardware maintenance. > 3. Custom built software Component reusability is an important aspect in software industry. Ibis responsibitity of software engineer to design and implement a software component in such a way that it ‘should be reused easily in many different programs. ~ Latest reusable components summarize both data as Wwell as the processing which is applied to the data, Which helps the software engineer to develop new applications from existing components. ~ For example, reusable components are used in the development of modem interactive user interfaces that tenable the generation of graphics windows, pull-down menus, as well. as wide range of interaction mechanisms. > 4 EMeency ~ Software is said to be efficient if it uses the available resources in the most efficient manner and prodtice desired result in timely manner. > 5. Maintainability ~ Hf customer requirements changes, programmers need to modify the software to fulfill those requirements. Software engineering provides the ability to maintain the software through modifying the software rather than changing whole product like hardware. > 6 Dependability ~ Dependability is the ability of the software that Provides services which can be trusted by users. Procass Models sofware Engg. 8. Introduction 0 Dependability is the ability of the software the = ee ane cea ro neipl wo eteve st FCI: On system. “Symmes Tope Types of Software 2 1.2.3 Types of Software > (MSBTE -5-16, W-16, S-18) a Virtually on all computer platforms, software can be ‘grouped into few broad categories : other programs. Few of them such as compilers, editors, and file management utilities are used to Process complex but determinate information structures. ~ Some other system software such as components of OS, several drivers, networking related software, and ‘elecommunications processors are generally used to Process heavily indeterminate data,Soferare ‘Som 4: depends upon the interaction with computer hardware. 2 Application software “These are the stand-alone programs which are specially developed for specific business needs. ‘The Application Software helps to process business oF technical data in auch a way that it should be useful 10 manage business operations as well as management or With traditional processing applications, one can also uuse application software to keep control on business functions in real time. P 3. Engincertng/ectentific software ‘These types of software are characterized through the “number crunching” algorithms. There are number of engineering software in various fields like astronomy, space shuttle orbital dynamics, automotive stress analysis, automated manufacturing, molecular biology etc. However, there are drastic changes in modern applications within the engincering/scientific area as they are shifting from traditional numerical algorithms. D4 Embedded software These are the software which are merged within electronic devices and are used for the purpose of implementing and controlling the features as well as funetions forthe end user as well as system itself > 5. Productiine software ‘These software are developed to provide » particular functionality for use by several customers. The focus of product-line software may be on a restricted marketplace like inventory control applications or can focus on mass consumer markets such as word processing. spreadsheets, graphics based applications, mukimedia, database management, and personal as well as business financial products. In ll the situations, the system software area jx broadly | =» ¢ Web applications ‘These applications are also called as “WebApps™. This i a network-centric software category which covers lasge number of applications. In shortest form, WebApps are same as of the group of inked hypertext files which provides information through text and limited graphics. Nowadays the modern WebApps are evolving into environments of sophisticated computing which offer stand-alone features, computing functions, as well os ‘content to the end user. It is also possible to integrate WebApps with corporate databases and business applications. Artificial intelligence software In these applications non-numerical algorithms are ‘generally used for the purpose of solving complex problems which cannot be handled by computation or straightforward analysis. ‘There are various applications in this category such as robotics, games, expert systems, artificial neural networks, proving theorem, pattem matching like image and voice. B —_—_—_—_———————————_—____——_—— ‘Syllabus Topic : Software Engineering as Layered —————————— 1.3 Software Engineering as Layered Approach at ngneeting 'a8 a1 pete aco aes W-16. 4 Harks Bi Software Engineering combines two concepts, Software and Engineering.‘Sottwaro| ie az Introduction 1o Sohware Engg. & Process Modols Som 4 > Software “This approach is divided into 4 layers ~ As we have already scen Software is set of executed | 1. A quality Process . Programs ‘elated to specific functionality. Set of] aay engineering approach must rest on the quality, ‘executable instructions is called as a program. = The mott important aspect in software Engineering is Software ie more than just a program code: it also | “8 eNO fncludes data structures. which allow programs to ‘manipulate information, and documentation related to | 2 Process software product which defines the functionality and . Foundation for SE is the Process Layer. Suidance for the user to use this software. Software ‘engineers design and build the software product. — SE process is the GLUE that holds all the technology a les the timely development of ‘7 Engineering layers together and enab! ly development computer software. ~ Engineering is an application of knowledge and well = Ti forms the base for management control of software defined principles to develop product, forms ec Project. 2 Methods Software Engineering ~ SE methods provide the "Technical Questions” for building Sonware. Methods contain a broad array of tasks that inchide ‘communication requirement analysis, design modeling, program construction testing and support. 4. Tools ~ SE tools provide automated or semi-automated suppor for the "Process" and the "Methods" — Tools are integrated so that information created by one tool can be used by another 1.3.2 Activities of Software Engineering © Understanding the user requirements is the fist ‘most important activity in software engineering. According to the requirements designing the System and taking decisions, which further leads {© Successful completion of development of Product. Mig 13.1 : Layered Approach of software Technology |. 0! Constructing the software product based upon p(MSBTE - Sern 4 — Cot designs and decisions made earlier is the next activity in software engineering. To verify the performance and quality of software, testing software product is essential after software product is constructed by software engineers. (© Providing maintenance for software product which is deployed to the customer. 1.3.3 Need of Software Engineering — As the technology changes, the user requirements and environment on which software is working also ‘changes. So every organization is ranked based on the software engineering principles used by that organization. = Implementing and managing large size of software, Programmer requires a specific method to modularize the tasks so that size of sofware can't harm the software quality. Software engineering provides | 1, ‘methodology for implementing complex software systems with high quality. ‘Without any standard method or management, it is ifficult to address defects in the product and correct them as carly as possible. Software Engineering provides this functionality — Extending the previous software functionality requires more cost in terms of time to develop and efforts taken by people, as compare to the process of developing new software to provide that | _ functionality. Software engineering provides a way in Which software system can be able to scale as needed in future. —— Syllabus Topic : Software Development Framework 1.4 Software Development Framework to add new Introduction to Software Engg. & Process Models ‘A software engineering process is the model selected for managing the creation of software from customer fnitiation to the release of the finished product. The selected process typically involves methods such as TW Requirement gathering and] “analysis Design Fig. 1.4.1 : Software engineering process ‘The software life cycle follows the sequential flow in order to develop software. We will see each and every stage of this life cycle in (MSBTE -S-16, W-17) ‘manuals for the purpose of developing software.Fig. 1.6.1 : Waterfall Model Waterfall model is the first approach used in software development process. It is also called as classical life cycle model or Hinear ‘sequential model. In waterfall model any phase of development process begins only if previous phase is completed. Requirement Analysis In this phase all business requirements of systerm are gathered and analysed by communication between stakeholders and customer of user. 'At the end of this phase Requirement Specification Document (SRS) is created. Design Based on requirement specification document design of system is created called software architecture. It is blue print of system representing system’s internal structure and behavior. Implementation In implementation phase actual coding is constructed for software architecture using hardware and software requirements of system. tis responsibility of developer. Verification / Testing Here coding or job done by developer is verified agsinst requirements of user in order to ensure that Introduction to Software Process Models ‘After the successful verification software is deployed ‘user's site for their use. Maintenance ‘While using software if user faces some problems, then those problems must be solved time to time by development team, This tnsk comes under maintenance of software. Maintenance also includes adding new functionalities {n software as per user requirements. = Advantages of waterfall mode! (@ Wis very simple to understand and easy t0 use, (Gi) Phases of waterfall model do not overlap with each other. (ii) Tt is useful for small projects in which requirements are clear initially. iv) Since development is linear it is easy fo manage development process. Disadvantages of waterfall mode! (@_Itisnot useful for large projects. Gi) Not suitable for projects in which requirements are not clear initially. System or product is available only at the end of development process. (iv) Itis very difficult to modify system requirements in the middle of development process. @ Practical situations in which Waterfall model can be used Gi ‘This model is used only when the requirements are very well known, clear and fixed. Product definition is stable. ‘Technology is understood. ‘There are no ambiguous requirements — Ample resources with required expertise are available freely ‘The project is short. software will satisfy all business requirements of User.1.8.2 V-Model fr coer — In software development, the V-model represents & development process that may be considered so Gxension of the waterfall model, and is an example of the more general V-model. — instead of moving down in a linear way, the Process steps are bent upwards aftr the eoding phase, to form the typical V shape. = ‘The V-Model demonstrates the relationships Deswern cach phase of the development life cycle and its associated phase of testing. = The horizontal and vertical axes represent time OF project completeness (left-to-right) and level of — This model is basically divided into two phases; verification and validation : 1.6.2{A) Verification Phases Fig. 1.6.3 : Verification phases tn the requirements analysis phase, the first step in the verification process, the requirements of the sysiem are Collected by analyzing the needs of the user(®) ‘This phase is concerned with establishing what the deal system has to perform. However it Joss, nat Germine how the software will be designed or built. Usually, the users are interviewed and 2 document called the user requirements document is generated. “The user requirements document will typically describe the system's functional, interface, performance, data, sccurty, etc. requirements as expected by the user. This used by business snalysts to communicate their understanding of the system to the users. ‘The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. “The user acceptance tests are designed in this Phase- “There are different methods for gathering requirements or bath soft and hard methodologies including: fmterviews, questionnaires, document analysis “observation, Uhrow-away prototypes, use ease and static and dynamic views with users. 2, System Design ‘systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. ‘They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. ‘The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data siructures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other tec! documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing are prepared.‘Software > 3. Architecture Design — This phase of the design of computer architecture and software architecture can also be referred to ss high-level design. — The baseline in selecting the architecture is that it should realize all which typically consists of the list of ‘modules, brief. functionality of ‘each module, their imerface relationships, dependencies, database tables, architecture diagrams, technology details etc. — The integration testing design is carried out in the particular phase. > 4. Module Design — The module design phase can also be referred to as Jow-level design. The designed system is broken up into smaller units or modules and cach of them is explained so that the programmer can start coding directly. ~The low level design document or progam specifications will contain a detailed functional logic of the module, in pseudo-code = © Database tables, with all elements, including their type and size. co All interface details with complete APL (Application Programming Interface) references. 0 ‘Allddependency issues. 0 Errormessage listings. © Complete input and outputs for a module. = The unit test design is developed in this stage. 1.6.2(8) Validation Phases Fig. 1.64 : Valldation phases (MSBTE - Sem 4 — 1413 Introduction to Software Engg. & Process Models In the V-model, each stage of verification phase has a corresponding stage in the validation phase. ‘The following are the typical phases of validation im the V-Model: 2. Unit Testing In the V-Model, Unit Test Plans (UTPs) are developed during module design phase. ‘These UTPs are executed to eliminate bugs at code level or unit level. ‘A unit is the smallest entity which can independently exist, e.g. a program module. Unit testing verifies that the smallest entity can function correctly when isolated from the rest of the ‘codeshunits. 2. Integration Testing Integration Test Plans are developed during the Architectural Design Phase. ‘These tests verify that units created and tested independently can coexist and communicate among themselves. . ‘Test results are shared with customer’ team. 3. System Testing System Tests Plans are developed during System ‘Design Phase. Unlike Unit and Integration Test Plans, System Test Plans are composed by client's business team. System Test ensures that expectations from application developed are met. The whole application is tested for its functionality, interdependency and communication. System ‘Testing verifies that functional and non functional requirements have been met. Load and performance testing, stress testing, Tegression testing, etc., are subsets of system testing. 4, User acceptance Testing User Acceptance Test (UAT) Plans sre developed during the Requirements ‘Analysis phase.TE - Sem: ‘Test Plans are composed by business users. UAT is Performed in a user environment that resembles the Production environment, using realistic data. UAT Verifies that delivered system meets user's requirement and system is ready for use in real time. ‘7 Advantages of V-model 1. This model is simple and easy to use. 2. The testing activities such as planning, test designing ‘are occurred prior to coding. This avoids wastage of me. Hence it has better chance of success compared to ‘waterfall model, 3. Proactive defect tracking ~ that means the diagnosis of ‘defects is done at early stage. : 4. Avoids the downward flow of the defects. Tt is considered as good for small projects in which ‘requirements are easily understood. ‘7 Disadvantages of V-modet 1. This model is considered as very rigid and least flenible. 2. The development of software is done in the implementation phase hence no carly prototypes regarding the software are produced. 3. If there are changes in midway, then there is need to update the test documents along with requirement documents. 1.6.3 Incremental Process Models ~The incremental model applies the waterfall model incrementally. ~The ceres of releases in refered to as “increments”, With cach increment providing more functionality to the customers. ~ After the frst increment, a core product is delivered, ‘which can already be used by the customer, 1.14 \ to Sotware Engg. & Process Models Based on customer feedback, a plan it developed for the next increments, and modifications are maje accordingly. This poses comin, wih nce big delivered until the complete product is delivered. The incremental philosophy is also used in the agile process Fig. 1.65 : Incremental Mode! Following tasks are common to all the models 1. Communication : helps to understand the objective, 2 Planning : required as many people (software teams) Work on the same project but different functions at ‘same time. 3% Modelling : involves business modelling, data ‘modelling, and process modelling, Construction : this involves the reuse of software ‘components and automatic code, Deployment : integration of all the increments ‘7 Characteristics of incremental Mode! System is broken down into many mini development Projects. Partial systems are built to produce the final system. 3. First tackled highest priority requirements, ‘The requirement of a portion is frozen once the incremented portion is developed, ‘Advantages of incremental Model 1. After cach iteration, regression testing should be Conducted. During this testing, faulty elements of the(MSBTE - Som 4 —, software can be, i duickly identifi oan ; ied because few changes ‘made within any single iteration, 1 is generally casier to test and debug than other methods of sofiwe Of software development because relativel smaller chan, it " vges are made during each iteration. This Hows for more targeted and rigorous testing of each ‘element within the overall product, Customer can respond to features and review the ‘product for any needed or useful changes, 4. Initial product delivery is faster and costs less. ‘7 Disadvantages of incremental Model 1, Resulting cost may exceed the cost ofthe organization. 2. As additional functionality is added to the product, Problems may arise related to system architecture ‘which were not evident in earlier prototypes 1.8.4 Difference between Waterfall Model and Incremental Model D> cusete-8-45,w.16, 5-18) ‘Simplicity Simple Intermediate Risk High Basily Involvement manageable Flexibility to | Difficult Easy change User Only at | Intermediate involvement _| beginning Flexibility Rigid Less Flexible Maintenance | Least Promotes maintainability Duration Long. ‘Very Long Inyroduction to Software Engg. & Process Modal, a SS ‘Tarim Toi Spc roses Mee 1.7 Specialized Process Models Spc proces mote ule on miny of Be Se oo atom or me of coven ‘models. However, specialized models tend to be applied when a narrowly defined software engineering, approach is chosen. 4.7.1 Component - Based Development séftware ‘Commercial —offthe-shelf (COST) components, developed by vendors who offer them as products, can be used when software i 0 be built. “These components provide targeted functionality with well-defined interfaces that enable the component to be imtegrate into the sofware. “The component-based development model incorporates many of the charactecstcs of the spiral model. It is evolutionary in nature, demanding an iterative approach tothe creation of software. However, the model composes spplications from prepackaged software components. Modeling and construction activities begin with the identification of candidate component ‘These components can be designed as either conventional software modules or object-oriented clasts or packages of classes. Regardless of the technology that is used to create the components, the component-based development model incorporates following steps (implemented using an ‘evolutionary approach ) : Available component-based products ate researched and evaluated for the application domain in question. Component integration issues are considered. Software architecture is designed to accommodte the componentsi y ‘Components are integrated into the architecture. Comprehensive testing is conducted to ensure Proper functionality. The component-based evelopment model leads to software reuse, and usability provides software engineers with a ‘umber of measurable benefits. Based on studies of reusability, component-based development can Jead to reduction in development cycle time, reduction in project cost and increase in productivity. Although these results are function Of the robusiness of the component library, there is litle question that whether the component-based evelopment model provides significant advantages for software engineers. 1.7.2 The Formal Methods Model ~The formal methods model encompasses a set of activities that leads to formal mathematical ‘specification of computer software. — Formal methods enable a software engineer to specify, develop, and verify a computer-based system by applying rigorous, mathematical notation. = A variation on this approach is called clean-room software engineering. = When formal methods are used during development, they provide a mechanism for eliminating many of the problems that are difficult to overcome using other software engineering paradigms. — Ambiguity, incompleteness, and inconsistency can be Giscovered and comected more easily, not through ad hoc review, but through the application of mathematical analysis. When formal methods are used during design, they serve as a basis for program verification and therefore enable the software engineer to discover and correct errors that might otherwise go undetected. = Although not a mainstream approach, the formal methods model offers the promise of defect-free s omar Engg. Process Moog Seiten trreney core sonecoeiy 135 eet Se TM Tontware. Yet. concern about its applicability in tusines environment has been expressed ‘The development of formal models is cureayy ° quite time-consuming and expensive. Because only few software GevelOPErs have the ecessary background 10 apply FOrMl methods training is required. extensive otis iffielt to use the model as a communicajog mechanism for technically — UNsOphin customers “ 4.73 Aspect-Orlented Software Development Regardiees of the software process that is chosen, the builders of complex software invariably implemeat ‘set of localized features, functions and information content. = “These localized software characteristics are modeled as components and then constructed within the context of a system architecture, ‘As modem computer-based systems become more sophisticated and complex, certain concems, customer required properties or areas of technical interest, span the entire architecture. Some concems are high-level properties of a system: ‘thers affect functions or are systemic. When concers ‘cut across multiple system functions, features, aid __ information they are often referred to as crosscutting concerns, Aspectual requirements define those crosscutting concems that have impact across the softwar architecture, Aspects are mechanisms beyond subroutines and inheritance for localizing the expression of # crosscutting concems. Aspect-Oriented Software Development (AOSD), often ‘referred to as Aspect-Oricated Programming (AOP) is 8 relatively new software engineering paradigm thst‘Sottware (MSBTE = Som 4 provides a process and methodological approach for defining, specifying, designing, and constructing, aspects. = A distinct aspect-oriented process has not yet matured. However, it is likely that such a process will adopt ‘characteristics of both the spiral and concurreat process models. = The evolutionary nature of the spiral is appropriate as aspects are identified and then constructed. The parallel nature of concurrent development is essential because aspects are engineered independently of localized software components and yet aspects have a direct, impact on these components. 1.74 The Unified Process = In some ways the unified process (UP) is an attempt to draw on the best features and characteristics of conventional software process models, but characterize them in a way that implements many of the best principles of agile software development. — The umified process recognizes the importance of customer communication and streamlined methods for describing the customer's view of a system. = Wt emphasizes the important role of software architecture and helps the architect focus on the right ‘goals, such as, understandability, reliance to future changes, and reuse. — It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is essential in modem software development. ——_————————— ‘Syllabus Topic : Agile Software Development - Agile Process and its Importance 1.8 Aglle Software Development : Agile Process and its Important Ace Introduction to Software Engg. & Process Modela ‘Agile software development describes an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and crose-functional teams and their ‘customers (end users). It advocates adaptive planning, evolutionary * development, early delivery, continual improvement, and it encourages rapid and flexible response to change. “The term Agile was popularized, im this context, by the Manifesto for Agile Software Development. ‘The values and principles adopted in this manifesto were derived from and underpin a broad range of software development frameworks, including Serum and Kanban. ‘There is significant subjective evidence that adopting agile practices and values improves the agility of software professionals, teams and organizations. and ‘© Aglle Software Development Values Based on their combined experience of developing, software and helping others do that, the seventeen signatories to the manifesto proclaimed that they value: ‘© Individuals and Interactions over processes and tools © Working Software over comprehensive documentation © Customer Collaboration over contract negotiation © Responding to Change over following a plan. ‘As per the view of Scott Ambler (Canadian software engineer, consultant and author) : ‘© Tools and processes are important, but it is more important to have competent people working together effectively. © Good documentation is useful in helping people to understand how the software is built and how to use it, but the main point of development is to create software, not documentation. © A contract is important but is no substitute for(MSBTE - Som; working closely with customers to discover. what they need, ‘A project plan is important, but it must not be too ‘gid to accommodate changes in technology or the environment, stakeholders’ priorities, and People's understanding of the problem and its solution. 1.8.1 Agility Principles / Features ‘The Manifesto for Agile Software Development is based on twelve principles 1. Customer satisfaction by early and continuous delivery of valuable software 2 Welcome changing requirements, even in late development Working software is delivered frequently (weeks rather ‘than months) 4. Close, daily cooperation between business people and developers 5. Projects are built around motivated individuals, who should be trusted 6. Face-to-face conversation is the best form of ‘communication (co-location) 7. Working software is the primary measure of progress 8. Sustainable development, able to maintain a constant Pace a 9. ‘Continuous attention to technical excellence and good design 10. Simplicity is essential 11. Best architectures, requirements, and designs emerge from self-organizing teams 12. Regularly, the team reflects.on how to become more effective, and adjusts accordingly eduction to Software Engg. 8 Process Modis 1.8.2... Difteconce betreeAgte Provese Mode! These models satisfy customer through carly and continuous delivery. Functionality | Itean Defines a distinct set accommodate | of activities, actions, changing tasks, milestones, and requirements | work products that are required to cengincer high-quality software Popularity | itis more Comparatively less | popular, popular Examples — | Water fall Scrum, eXtreme ‘model, Programming (XP), Incremental _| Feature Driven models Development (FD), Dynamic Systems Development Method (SDM), Adaptive Software Development (ASD) Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements, eePET sotmaro. — As atype of agile software development, it advocates frequent "releases" in short development cycles, which is imended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. — Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer's requirements as ‘time passes and the problem is better understood, and frequent communication with the customer and among Programmers. (MSBTE - Som — The methodology takes its name from the idea that the beneficial elements of traditional software engineering. ‘practices are taken to "extreme" levels, = As an example, code reviews are considered 2 beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair : 1 1.9.1 XP Values — Extreme programming initially recognized four ‘values In 1999 : communication, simplicity, feedback, and courage. A Extreme Programming Explained. “Those five values are described below. Fig. 19.1 : XP values > 1. Communication — Building software systems requires communicating system requirements to the developers of the system. In \ Introduction to Softwar formal toftware development methodologies, this task is accomplished through documentation. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional Knowledge among members of a evelopment team. “The goal isto give all developers a shared view of the system which matches the view held by the users ofthe system To this end, extreme programming favort simple esigns, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback. 2 Stmplkity Extreme programming encourages starting with the simplest solution. Extra functionality ean then be added later. “The difference between this approach and more conventional system development methods is the focus ‘on designing and coding for the needs of today instead of those of tomorrow, next week, or next month “This is sometimes summed up as the "You aren't gonna need it" (YAGND approach. Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomerrow to change the system: their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed, while perhaps delaying crucial features Related to the “communication” value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by-most programmers inthe tear, & Process Models =~(MSBTE - Som 4 — Comp\T)_1-20 F3 Feedhack ~ Within extreme programming, feedback relates to ‘ifferent dimensions of the system development: ~ Feedback from the system : by writing unit tests, or Tunning periodic integration tests. the programmers have direct feedback from the state of the system after implementing changes. ~ Feedback from the customer : The functional tests (oka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the Current state of their system. This review is planned ‘once in every two or three weeks so the customer can ‘easily steer the development. ~ Feedback from the team : When customers come up with new requirements in the planning game the tearm directly gives an estimation of the time that it will take ‘0 implement. ~ Feedback is closely related to communication and simplicity. Flaws in the system are easily ‘communicated by writing a unit test that proves a ‘certain pioce of code will break. ~The direct feedback from the system tells programmers to recode this part. ~ A customer is able to test the system periodically ‘according to the functional requirements, known ‘as user stories. ~ AS per Kent Beck (American software engineer and the Creator of extreme programming), "Optimism is an ional hazard of programming. Feedback is the treatment." > 4 Courage ~ Several practices represent courage, One is the ‘Commandment to always design and code for today and ‘ot for tomorrow, ~ This is an effort to avoid getting delayed in design and ‘mquiring a lot of effort to implement anything else Gourge enables developers 10 feel comfortable with refactoring their code when ‘necessary, Introduction to Software EN99. & Process Model, the existing system ang ‘This means reviewing ie modifying it so tat future changes can be implementeg ‘more easily. “Another example of courage is knowing when to throw code away: courage {0 remove source code that is obsolete, no mater how much effort was used to create that source code. / Also, courage means persistence: a programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, but only if they are persistent. > 5. Respect ‘The respect value includes respect for others as well as. self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. ~ Adopting the four earlier values leads to respect gained from others in the team. ~ Nobody on the team should feel unappreciated or ‘ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. ~ This value is dependent upon the other values, and is oriented toward teamwork. 1.10 Other Agile Process Models ae Frocess Models ~ Im general Extreme Programming (XP) is considered as ‘he most widely used of all agile process models, ~ But there are several agile process models which are in Sst across the industry. Among them most commoaly sed are : _“conan be reqdromerts ebm eau lan ‘Software| ota bv ASD. Se aa): ‘Adaptive Software Development (ASD) has been Proposed by Jim High smith and Sam Bayer as a technique for the purpose of developing complex software as well as systems. ‘The main focus of ASD is on human collaboration and team self-organization. High smith defines an ASD “life eycle” which include three important phases; speculation, callaboration, and earning. ‘Aaspeve cra reing Ferrante gaterng enn tena pe WD meeps co comeonats motmaneitestes os gpa tote ol ‘Scjmeal eve posmonoma Fig. 1.10.2: Adaptive software development In the process of project development, adaptive cycle planning is conducted in initial phase. Adaptive cycle planning refers the important {information regarding project initiation such as mission Statement of customer, important constraints in the Project (such as, delivery dates, user descriptions etc.), (MSBTE - Som 4 321 Introduction to Software Engg. & Process Models and basic requirements which are necessary to define the tet of release cycles (software increments) which will be essential forthe project. ‘There is always possibility of changing the cycle plan ‘even if it may be complete or perfect. Depending on the data obtained at the completion of the first cycle, the review of plan is taken and is adjusted so that planned work must be compatible with the reality in which an ASD team is working. Collaboration is always used by the motivated people in such a way that their talent will be multiplied and enhances the creative output beyond their absolute fumbers. ‘This approach is frequently used in all agile methods. But itis not easy to implement the collaboration. 1 mostly depends upon communication and teamwork, Dut it also focus on individualism, since individual creativity considered as an important aspect -in collaborative thinking. Above all these things, important is matter of trust, Individuals working together should have trust in between them for the purpose of : (Q) Criticize without hatred @) Assist without anger (3) Work as hard as much possible (4) Posses skill set to contribute to the work (5) Discuss problems or concems in a manner that leads to effective action. ‘As members of an ASD team start developing the components which are part of an adaptive cycle, mostly the focus is on “Ieaming” as much as possible as steps forward toward a completed cycle. ‘Highsmith argues that it is usual habit of software developers to overestimate their own understanding (regarding the aspects such as the technology, the process, and the project) and such types of teaming will efinitely assist them to enhance their level regarding real understanding.molto Ei (MSBTE - Som a Sylinbua Tople : Scrum 1.10.2 Scrum > cusere -5-17) EET | Tum is an agile framework for managing knowledge ‘work, with an emphasis on software development. I is designed for teams of three to nine members, who break theit work into actions that can be completed ‘Within time boxed iterations, called “sprints”, no longer Introduction 10 Soltwaro, 4 most commonly WO weeks, ig £ Procoen Movi, than one month ani track progress and resplan in scrums. © ony, meetings, called daily Serum principles are moatly based on the ogy manifesto and help to guide activitics tepariin, development inside a process which includ, framework activities such as requirements, analysiy, design, evolution, and delivery. In all the framework activities, work tasks happen within a process pattern called spring Sort, ‘Sprint planning backlog GS] } Toplez: Plan work (6.9. tasks) Sprint Prodvet backiog Aovew ——"*TOCPNCtVO Fig. 1.10.3 : Scrum Framework ‘The work implemented in a sprint i tailored to the problem at hand and is defin. the respective Scrum team. ed and usually tailored in real time by a co OAL, wy = ‘te eran Fig, 1.10.4 : The scrum process‘Software (MSBTE - Sem 4 — Com, = Serum mostly focus om the use of a bunch of software 4+ process patterns which are proved effective for projects with restrictive timelines, changing requirements, and business criticality. All such process patterns defines several sets of development actions : — Backlog - a prioritized list regarding project needs or features which offer business value for the customer. It {is possible to add items to the backlog at any time. The respective product manager assesses the backlog and ‘changes the priorities as per necessity ~ Sprints - Includes work units which are necessary to ‘gain ¢ requirement defined in the backlog which should bbe incorporated in predefined time-box (usually thirty days), Modifications (such as backlog work items) are not involved during the sprint. Therefore, team members are allowed by the sprint to work in a shortterm, but stable environment. = Scrum meetings - are short (usually fifteen minutes) ‘meetings conducted on daily basis by the Scrum team. ‘Three most important key questions which are asked ‘and must be answered by all team members are: 1, What did you do since the last team meeting? 2. What obstacles are you encountering? 3. What do you plan to accomplish by the next team meeting ? = A team leader, who is known asa Scrum master, handles the meeting, and evaluates the responses from each person. — ‘The important use of Scrum meeting tothe team is that itcan uncover critical issues as early as possible. One more benefit of these daily meetings is that they lead to “knowledge socialization” and thus encourage a self-organizing team strocture. Demos - implement the software increment atthe client side (customer) 0 that the newly developed functionality can be demonstrated as well as evaluated by the customer. 23 Introduction to Software E 8 Process Models ~ _ Itis also possible that the demo may not able to contain all planned functionality, but instead such functions ‘which can be delivered within the established time-box. ——— ‘Syllabus Topic : Dynamic Systems Development Method (DSDM) 1.10.3 Dynamic Systems Development Method (DSDM) = The DSDM (Dynamic Systems Development Method) is an agile software development approach which offers framework for the purpose of building as well as maintaining systems which satisfy the tight time constraints with the help of incremental prototyping in ‘controlled project environment. = The DSDM philosophy is basically derived from an updated version of the Pareto principle- it is possible to deliver eighty percent of an application in twenty percent of the time. = DSDM is considered as an iterative software process in Which all the iterations follow the eighty percent rule. ‘That indicates that, only adequate work is necessary for each’ increment for the purpose of facilitating ‘movement to the next increment. It is possible to complete the left over detail later on ‘when additional business requirements are acquired or modifications have been requested as well as accommodated, — The DSDM Consortium (website - www.dsdm.org) is 8 worldwide group of associated companies which jointly take on the role of “keeper” of the method. = Am agile process model fas been described the consortium known as DSDM life cycle which describes three dissimilar iterative cycles, preceded by two more life cycle activities: — Feasibility Study - sets the basic business needs and ‘constraints connected with the application which is to be built and then checks whether the application isSotware feasible for the SDM (Dynamic Systems Development Method) process, Business study - sets the fimctional ss well as {information needs which will permit the application to Supply business value; also, describes the fundamental application architecture and recognizes the ‘maintainability necessities forthe application. Functional Model Iteration - generates a bunch of incremental prototypes which are used to demonstrate functionality for the customer. ‘The main aim during this iterative cycle is to collect ‘more requirements by drawing feedback from users as ‘they exercise the prototype. Design and Build Iteration - revisits prototypes built jn the iteration of functional model to make sure that all the prototypes have been engineered in a way which ‘will enable it to give operational business value for end users, ‘Sometimes, functional model iteration and design and ‘build iteration take place simultaneously. Implementation - introduces the most recent software increment into the operational enviroameat. Important points are: 1. The increment may be incomplete or 2. New requests for changes may come as the incremeat is put into place. In either case, DSDM development work carry on by the process of coming back to the functional model iteration activity. : It is possible to combine DSDM with XP to offer a ‘combination approach which defines a concrete process. ‘model with the muts and bolts practices (XP) which are ‘necessary to build software increments ‘Syllabus Tople : Crystal (MSBTE - Sem 4 io troduction to Sottware Eng. 8 Process Modo, ays methods are a family of methodologies (ie © Gysta) family) that were developed by Alinaiy ‘Cockburn inthe mid-1990s. boil ‘come from years of study and interview, ‘of teams by Cockburn. Cockburn's no that the teams be interviewed did not follow the formay ‘methodologies yet they still delivered succexsfy, projects. = The Crystal family is Cockburn’s way of cataloguing what they did that made the projects successful. Crystal methods are considered and described ay “lightweight methodologies”. The use of the wont CCoystal comes from the gemstone where, in software terms, the faces are a different view on the “underlying core” of principles and values. = The faces are a representation of techniques, tools, standards and oles. = Methodology, techniques, and policies are (MSBTE- W-14, S-15, W-15, S-17, W-17) Need of SRS, Format, and tts Software engineering is considered as guided by a set of core principles that help in the application of a significant software process and the implementation of efficient software engineering methods. AC the process level, the important use of core principle is to establish a philosophical foundation which guides members of a software -team as they perform framework and umbrella activities, navigates the Process flow, and generates a collection of software ‘engineering related work products. At the practice level, core principles create a set of values and rules which serve as a guide when there is analysis of a problem, designing of a solution, implementing and testing of the solution, and finally deployment of the software in the user community.eee ~ There is a set of general principles which span sofware we pegareent a ol Enginecting process and practice. Those principles sre 43 follows : (8) Provide value to end. users, ©) Keepit simple, (©) Maintain the vision (of the product and the Project), ©) Beopen to the future, (© Plan ahead for reuse, and @) Thinks ~ Although these are important general principles, their characterization is done at such a high level of abstraction that in some situations, it becomes complicated to implement them in day-to-day software ‘engineering practice, ~ Tm the next sections we are going to sce core principles in more detail which guide process and practice. 2241 Principles that Guide Process ~ Uptill now we have seen the significance of the several Process models which are used in softwaze engineering work. ~ i spite Of whether a model is linear or iterative, Prescriptive or agile, it is possible to characterize it with the help of generic process framework which is ‘applicable for all process models, - “Herein set of core principles which can be applied to ihe framework, and by extension, to any ofthe software Process, ‘8. Create work products that provide value for others, Fig. 22.1 : Principles that guide process ‘> Principle 1, Be agile — Whether the selected process model is prescriptive or agile, the basic view of agile development must be able to gover the approach. ~ Each and every part of the work done should highlight economy of action - keep the technical approach as ‘maximum easy, keep the generated products as concise ‘8 possible, and try to make decisions locally whenever itis possible. ‘ > Principle 2, Focus on quality at every step ‘The exit condition regarding all the Process activities, Sstions, and tasks must concentrate on the quality ofthe Work of generated Product. > Principle 3, Be ready to adapt Fess cannot be considered asa religious experense, i belief has no place init. Whenever there is need Problem, the people, and the project itself. > Principe 4, Build an effective teamSoftware| (MSBTE - Sem 4. Principle 5, Establish mechanisms for communteation and coordination The reason of project failure is that the critical {nforroation falls into the cracks and/or stakeholders sre not able to coordinate their effors to produce a successful end product. ‘These are considered as management Jevel concerns snd must be addressed. Principle 6, Manage change ‘The approach sometimes is formal while sometimes informal, but there is need of mechanisms to handle the way changes are requested, assessed, approved, and implemented. Principle 7, Assess risk ‘There is possibility of concems in several things as there is progress in software development. It's important that you set contingency plans. Principle 8, Create work products that provide value for others Create only such types of work products which offer value for other process activities, actions, or tasks. Each and every produced work product which is a part of software engineering practice will be passed on to others. A list of necessary factions as well as features will be provided to the individual who will develop a design, the design will be provided to the individual who ‘generate code, and 50 on. 2.2.2 Principles That Guide Practice ‘The important aim of Software engineering practice is to deliver on-time, high quality, operational software that consists of functions and features which meet the requirements of all the stakeholders. To make it possible, we should adopt a set of core principles which are able to guide the technical work. ‘There are merits in these principles despite of the applied analysis. and design methods, the used construction techniques (€.g,, programming language, ‘Software Recicement E automated tools), or the selected verification and validation approach. Here is a set of core principles which are fundamental to the practice of software engineering: 7 Dluson rem a rurroor of deferent porspocives 'B, Remember that someone will maintain the sofware Fig. 222:: Principles that guide practice ‘> Principle 1, Divide and conquer In a more technical way, analysis and design should always emphasize Separation of Concems (SOC). ‘To solve a large problem easily, itis benter to subdivide it into a set of elements (or concerns). Ideally, each and ‘every concem provides distinct functionality which can be developed, and sometimes validated, separately of other concems. Principle 2, Understand the use of abstraction ‘An abstraction is considered as a simplification of any complex element of a system which helps to communicate meaning in a single phrase. In software engineering practice, several levels of abstraction are used, all of which imparting or implying, ‘meaning that must be communicated. > Principle 3, Strive for consistency Whether it's making of a requirements model, building, 1a software design, creating source code, or generating(MSBTE - Sem 4 — batons the Principle of consistency imply thet a NaF COMLEX makes software easer to se. Bg think © design of 9 user interface for a WebApp. stent position of menu options, consistent color use, and the consistent use of recognizable fons: all these elements make the interface very sound. =e Principle 4. Focus on the tranafee of information Sv end user, from 2 legacy system to a WebApp, from Sn end user into a graphical user interface (GUI), from 7 ‘operating system to an application, from one Sofware component to another - the list is almost endless, {m all these case, information flows across an interface, ‘and as a result, there is possibility of error, or omission, or ambiguity, ‘This Principle implics that one must give special sention to the analysis, design, construction, and testing of interfaces, > Principle 5. Build software that exhibits effective ‘modularity ~ Separation of concems (Principle 1) describes a Philosophy for software. Modularity gives a ‘mechanism for realizing the particular philosophy. ~ It is possible to divide any complex system into modules (components), but there are more expectations from good software engineering practice. ~ Modularity must be effective. That means, each and every module should concentrate solely on one well- constrained aspect of the system. — Also, the connections between modules should be relatively simple - each module must show. low coupling with other modules, to data sources, and to other environmental aspects. ‘> Principle 6. Look for patterns - ‘The aim of pattems within the software community is to generate a structure of literature to facilitate software. developers resolve ‘ecurring problems occurred in the entire process of software development. Patter help t0 generate a shared language prnpose of communicating ISiBMt and expe regaring these problems with ther solutions, Formally codifying these solutions ang relationships allows us to effectively confine the of knowledge which sets our understanding of architectures which satisfy the user requirements 7. When possible, represent the prob > Pe te colution from «number of diners perspectives When a problem with its solution is inspected from several perspectives, there is possibility of ben, insight andthe error and omissions will be uncovered, For example, data oriented viewpoint can be used tg represent a requirements model. - Data oriented viewpoint isa function-oriemteg viewpoint, or a behavioral viewpoint. — Bach provides a unique view of the problem with its requirements, > Principle 8. Remember that someone will maintain the software — Over the long period of time, software will be corrected ‘as issues are resolved, adapted as its environment changes, and improved as stakeholders expect more capabilities. ~ To facilitate these maintenance activities, there is need Of solid software engineering practice throughout the software process. Syllabus Topic : Communication Practices! Principles es 2.3 Communication Practices / Principles eit cation Practices / Principles ~ Before customer requirements can be analyzed, ‘modeled, or specified they must be gathered through communication (also called requiccment elicitation) activity,PE sotmaro, (MSBTE = Som 4— Compl 12:5. Effective communication (among technical poers, with the customer and other stakeholders, and with project ‘managers) is among the most challenging activities that confront software engineer. In this context, following are the communication principles and concepts that apply to customer ‘communication : Principle 1. Listen : focus on the speaker's words, rather than formulating your response to those words. Be a polit listener. Principle 2, Prepare before you communicate + Spend the time to understand the problem before you ‘meet with others “research”. Princlple3. Someone should facilitate the communication activity : Have a leader “moderator” to keep the conversation moving in a productive direction. Principle 4. Face-to-face communication Is best. Principle 5. Take notes and document decisions. Principle 6. Collaborate with the customer : Each small collaboration serves to, build trust among team ‘members and creates a common goal for the team. Principle 7. Stay focused, modularize your discussion : The facilitator should keep the conversation modular; leaving one topic only after it has been resolved. Principle 8. Draw pictures when things are unclear. Principle 9 (a) Once you agree to something, move on; (&) Ifyou can't agree to something, move on; (© If a feature or function is unclear and can’t be clarified at the moment, move on. Principle 10 : Negotiation is not a contest or a game. It works best when both parties win. 2.4 Planning Practices / Principles encompasses a set of ‘The planning activity management and technical practices that enable the road map as it travels toward its, SMW team to define a strategic goal and tactical objectives. Regardless of the rigor with which planning is ‘conducted, the following principles always apply: * = iakehordors) inte planning activity 10, Track what youve planned and make adjustments as required Fig. 24.1 : Planning Practices / Principles ‘> Principle 1. Understand the project scope ‘Scope provides the S/W team with a destination. > Principle 2. Involve the customer (and other stakeholders) in the planning activity ‘The customer defines priorities and establishes project constraints. S/W engineers must often negotiate order Of delivery, timelines, and other related issues. > Principle 3. Recognize that planning is iterative ‘A plan must be adjusted to accommodate changes. weThe intent of estimation isto provide an indication of Sffort, cost, and task duration, based on the team's ‘CUrTent understanding of the work to be dane. Principle 5, Conskter risk me you define the plan > Principle 6. Be reallctle Even the best S/W engincers make mistakes. > Principle 7. Adjust granularity as you plan A fine granularity plan provides significant work task detail that ix planned over relatively short time ‘increments, A coarse granularity plan provides broader ‘work tasks that are planned over fonger time periods. Principle 8. Define how quality will be achieved. “> Principle 9. Define how you'll accommodate changes “Can the customer request a change at any time?” ‘> Principle 10. Track what you've planned and make 8 required. ~ Bary Bochm states : “You need an organizing Principle that scales down to provide simple plans for simple projects.” ~ Boehm suggests an approach that addresses project ‘Objectives, milestones, and schedules, responsibilities, management and technical approaches, and required resources. Boehm calls it WSHH principle, after a series of questions that lead to 2 definition of key project characteristics and the resultant project plan — Why 1s the system being developed? Does the business purpose justify the expenditure of people, time and money? — What will be done? Identify the functionality to be built When will it be accomplished? Establish a workflow and timeline for key project tasks and identify milestones required by the customer. “ — Who is responsible for a function? Define members’ roles and responsibilities. ~ Where are they located —(organizationally)? ‘Customers also have responsibilities. Software Requirement Tow wil the Job be dove techateny * nageially 7 Once a scope is defined a te, strategy must be defined. How much of each resource fs needed? The ia derived by developing estimates based on answen ‘earlier questions. Ertan Topi Modeling Practices Prinses ‘syilal 2.5 Modelling Practices / Principles ‘The process of developing analysis and design model, is described in this section. The emphasis is on describing how to gather the information needed to build reasonable models, but no specific’ modeling notations are presented in this chapter. UML and other ‘modeling notations are described in detail later in the text In Software Engineering work, two models are created: analysis models and design models. = Analysis models represent the customer requirements by depicting the S/W in three different domains: the information domain, the functional domain, and the behavioral domain. = Design models represent characteristics of the S/W thet help practitioners to construct it effectively: the architecture, the user interface, and component-level detail, — _Intheir book on agile modeling, Scott Ambler and Ron Jeffries define a set of modeling principles that are intended for those who use the agile process model but are appropriate for all software engineers who perform modeling actions and tasks: Principle 1 : The primary goal of the software team is to build software, not create models. Prineiple 2 : Don’t create more models than you need. Principle 3 : Strive to produce the simplest model that will describe the problem or the software.(ASBTE = Som EP sonwaro, AD Principle 4 : Buikd models in a way that mahes them agreeable to change. Principle § : Re able to state an explicit parpse for cach model that is erated, Prinetple 6 : Adapt the models you develop to the system at hand Principle 7 : Try to build useful models, but forget about building perfect models. Prineiple 8 : Don't become inflexible about the syntax of the model. If it communicates content successfully. representation is secondary. Principle 9 + If your instincts tell you a mode! isn't right even though it scems okay on paper, you probably hhave reason to be concemed. Principle 10 : Get feedback as soon as you can. 2.5.1. Requirement / Analysis Modelling Principles > qasete-w-14) 1. The information domain of a problem must be] presented and understood Soltwnro Roguiromont Represent software functlons Ponctions can be described at many different levels of ibetraction, ranging from a gener statement of purpose to 8 detailed description of the processing elements that must be invoked. PA. Represent software behavior = The behavior of the software ix driven by the interaction with the extemal environment. = The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in Inyered fashion (or hicrarchical) <> 4 The analysis task shonkd move from essential Information tawaru implementation detall = Analysis begins by describing the problem from the end-user perspective, The “essence” of the problem is described without any consideration of how a solution will be implemented. 25.2 Design Modelling Principles = The software design model is the equivalent of an architect's plans for a house. Set of principles used Fig. 25.1 : Analysis modelling principles > 1. The information domain of a problem must be represented and understood ‘The informasion domain encompasses the data that flow into the system (end-users, other systems, or extemal devices), the data that flow out of the system and the data stores that collect and organize persistent data objects. ‘Focus on the dovign of data as Ris as important as a designSofware ~The analysis model describes the information domain f the problem, user visible functions, system behavior, and a set of analysis classes that package business objects with the methods that service them. — The design model translates this information into an architecture: a set of subsystems that implement major functions, and a set of component-level designs that are the realization of analysis class. ® a Always consider architecture - ‘S/W architecture is the skeleton of the system to be - built. Only after the architecture is built, the ‘component-level issues should be considered. oe. Focus on the design of data as it is as Important as adesign. ~ Data design is an esseatial clement of the architectural design, + 4. Interfaces (both user and internal) must be designed ~ A well designed interface makes integration easier and | 4, assists the tester in validating ‘component functions. > 5. User Interface design should be tuned to the needs of the end-user 3 “Ease of use.” > 6 Component-level design should exhibit ‘functional independence. 4 ~The functionality that is delivered by a component should be cohesive- that is, it should focus on one and only one function. > 7. Components should be loosely coupled to one ‘another and to the externsl environment. ~ Coupling is achieved in many ways ~ via a component interface, by messaging through global data. — Coupling should be kept as low as is reasonable, As the level of coupling increases, error propagation also increases and the overall maintainability of the system decreases. > 8 Design representation (models) should be easily understood. ~The design model should be developed iteratively. ‘With each iteration the designer should strive for Proparation Principles Before writing even one line of code, be sure of : 2a. ‘Software Requiroment Engineg 28 (SBE - Som 4 — Comp\ IT) —— ra Design must be traceable to the analysis mode! | ‘Syllabus Top! 2.6 Construction Practices / Principles In this text “construction” is defined as being compos, of both coding and testing. The purpose of testing itty uncover defects. Exhaustive testing is mot possible yy processing a few test cases successfully does ng ‘guarantee that you have bug free program. ‘Although testing has received increased attention ove, the past decade, itis the weakest part of softwir ‘engineering practice for most of the organizations. 2.6.1 Coding Principles and Concepts ‘Understand the problem you are trying to solve, ‘Understand the basic design principles. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate, Select a programming environment that provides too that will make your work easier. Create a set of unit tests that will be applied once the component you code is completed. Coding Principles ‘As you begin writing code, be sure you 1. Constrain your algorithm by following structured Programming practice. Select the proper data structure, Understand the software architecture. Keep conditional logic as simple as possible. Create easily tested nested loops, ‘Write code tha is self-documenting. Create a visual layout. Now ee eeSotware U1 (MSDTE - Som dation Principlos ‘Afier you'vo ‘comploted your first coding. pass, be sure you Lo oto walk throng 2. Doeform unit toxt and correct errors. 3. Refactor the code, 2.6.2 Testing Princip! 1, Testing ix n process of executing « program with the intent of finding errors, 2. A good test in one that has a high probability of fin an as-yet undiscovered enor, ‘A successful test in one that uncovers an as-yet ‘undiscovered error, —_—_——________ ‘Syllabus Topic : Software Deployment (Statement and Meaning of each Principle for each Practice) —_—_——_—_SSaaeL 2.7 Software Deployment (Statement and Meaning of each Principle for each Practice) > (MSBTE - 5-15, W-15, S-16, 5-17, W-17) sbe tha piinenlon the prineiplea’ — Installing the software at client side is known as deployment. — There are three important actions in the process of deployment: delivery, support, and feedback. Since the nature of modem software process models is evolutionary or incremental, deployment process ‘happens not only once, but several times as software moves toward completion. = Bach delivery cycle offers the end users with an operational software increment which can give usable functions and features. Bon Rloqgacennann E = Al of the deployment cycle gives document well as h n assistance for several functions and Features provided through deployment cycles up tilt now. ~The software ter important guidance from the feedback cycle which leads to mexlifications ta the functions, features, and approach decided for the next increment. = Por any software project an important milestone is represented by the delivery of a software increment. = Following are the important principles which must be followed ax the team gets ready to deliver an increment : principles for software deployment 1, Gustomor oxpoctalione for tho eoftware must bo managod 2. A compioto dolivery package should bo ‘ansomblod and toatod ‘2. A cupport rogimo must bo established before the software Is dollvorod “4, Appropriaio ineiructonal materials must bo Drovided to ond usar ‘5. Bugay eoltwara should bo fixed first, dolivored lator Fig. 2.7.1 : Principles for software deployment > Principle 1. Customer expectations for the software must be managed — Mostly, the expectations of customer are more than the team has promised to deliver, and there is always possibility of disappointment. — This leads 10 bad feedback which is obviously not productive and may ruin team morale. = Inher book on managing expectations, Naomi Karten states: “The starting point for managing expectations ix to become more conscientious about what you ‘communicate and how.” = She recommends that it is responsibility of a software engineer to be careful regarding sending the customer conflicting messages (¢.g.. promising more than what is possible practically in the time frame given or> Principle 2. complete delivery package should be > Principle 3. A support regime must be established > Principle 4. Appropriate instructional materials > Principle 5. Buggy software should be fixed first, (MSBTE - Som 4 — Como\ IT _ 2:10 Gelivering more than the promise regarding one Software increment and less in the next software increment), assembled and tested Any media such as a CD-ROM or Web-based Gownloads which contains all executable software, Supported data files as well as documents, and other elated information must be assembled and ‘comprehensively beta-tested with actual users. All the scripts regarding installation and other Operational features must be completely exercised in all the possible computing configurations (i.c., hardware, OSs, peripheral devices, networking arrangements. before the software is delivered ‘There is expectation of Fesponsiveness and precise information by end user when any question or issue arises. A support should not be ad hoc, or worse, nonexistent, Otherwise customer will not be satisfied. ‘There should be systematic planning in support, well Preparation of support materials, ‘and setting of appropriate recordkeeping mechanisms so that the software team will be able to conduct a categorical assessment of the sort of support requested. must be provided to end users ‘There is delivery of more than the software itself by the software team. Suitable training aids (if necessary) must be developed; guidelines. regarding troubleshooting should be provided. delivered later 5 ‘Because of time constraint, some IT firms deliver low- quality increments by giving a waming to the end user ‘that bugs “will be fixed in the next release.” This is completely wrong. One important thing the provider should keep it in mind that: “After some time 28 o > customers will forget that the delivered product was Software Requirement Enginoe, high‘quality, but they will always remember the issue, that a low-quality product caused them. The softwar, reminds them every day.” “Syllabus Tople : Requirement Engineering Requirement Engineering D> (MSBTE- Wag Requirement The information which describes the user's expectation about the system performance ix called as requirement. ‘The requirement must be clear and unambiguous. Some requirement definition has to face problem of lack of clarity. Characteristics of requirements ‘There are various characteristic of requirements, They are as follows = 1. Requirements should be unambiguous ‘2. Requirements should be testable (verifiable) ‘3. Requirements should be clear (concise, simple, precise) eee aS 5. Requirements should be feasible ees Fig. 2.8.1 : Characteristics of requirements 1, Requirements should be unambiguous Ambiguous means the ‘single word or statement has more than one meaning. If requirements contain ambiguity then it is difficult to fulfill the requirement correctly.‘Sonwaro, (MSDTE - Som 4 — Comp\ ‘Therefor the requirements should be unambiguous means non confusing, > 2 Requirements should be testable (veriflable) ‘Tho requirements should be testable means tester should be able to easily test the requirement whether they are implemented successfully or not, For easy test, the requirement should be clear and unambiguous. <> 3. Requirements should be clear (concise, simple, precise) The requirements should be clear. They should not contain any unnecessary information. Wf thero is any unnecessary information then it becomes. Aifficult to achieve the appropriate fulfillment of the requirement, 4. Requirements should be understandable ‘The requirements should be understandable means when anyone read it then it should be easily understood by that person, To make it understandable proper conventions are used. It should be grammatically correct. > 5. Requirements should be feasible (realistic, possible) ‘The requirement should be completed within the given time and budget. Specified requirement said to be feasible if it can be. implemented using existing technology, with estimated budget and time. > 6 Requirements should be Consistent ~ Consistency is an important feature of requirements. It ‘means that all inputs must be processed similarly, It should not happen that processes produce different ‘outputs for same inputs coming from different sources. ‘7 Requirement Engineering ‘The procedure which colllects the software requirements from customer, analyze and document them is called as requirement engineering. & ee ‘The aim of requirement engineering is to create and maintain ‘System Requirements Specification™ document. Requirements engineering is the process of ‘understanding and defining which services are required ‘and identifying the constraints on these services. Requirement engineering processes ensures your software will meet the user expectations and ending up with high quality software. It's a critical stage of the software process as errors at this stage will reflect later on in the next stages. which igher costs. definitely will cause you At the end of this stage, a requirement document that specifies the requirements will be produced and validated with the stakeholders. 28.1 Activities Involved in Requirements Engineering D> (MSBTE - W-15, S-17, W-17, 5-18) ‘The activitles/tasks involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved.