Software Configuration Management and Trends

Formal Methods Recent Trends Formal Methods Recent Trends In Software Engineering In Software Engineering (Unit-VI)

Software Configuration Management (SCM) Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team. The goal is to maximize productivity by minimizing mistakes. Software configuration management (SCM) is an umbrella activity that is applied throughout the software process. Because change can occur at any time, SCM activities are developed to (1) identify change, (2) control change, (3) ensure that change is being properly implemented, and (4) report changes to others who may have an interest. It is important to make a clear distinction between software support and software configuration management. Support is a set of software engineering activities that occur after software has been delivered to the customer and put into operation. Software configuration management is a set of tracking and control activities that are initiated when a software engineering project begins and terminates only when the software is taken out of operation. 7/4/2025 2

software configuration The output of the software process is information that may be divided into three broad categories: (1) computer programs (both source level and executable forms), (2) work products that describe the computer programs (targeted at various stakeholders), and (3) data or content (contained within the program/external to it). The items that comprise all information produced as part of the software process are collectively called a software configuration. 7/4/2025 3

SCM Scenario: A typical CM operational scenario involves: 1) A project manager who is in charge of a software group: The goal is to ensure that the product is developed within a certain time frame. 2) A configuration manager who is in charge of the CM procedures & policies: The goals of the configuration manager are to ensure that procedures and policies for creating, changing, and testing of code are followed, as well as to make information about the project accessible. 3) The software engineers who are responsible for developing and maintaining the software product: The goal is to work effectively. 4) The customer who uses the product: The customer uses the product. Since the product is under CM control, the customer follows formal procedures for requesting changes and for indicating bugs in the product. 7/4/2025 4

Elements of a Configuration Management System: Four important elements that should exist when a configuration management system is developed: 1) Component elements a set of tools coupled within a file management system (e.g., a database) that enables access to and management of each software configuration item. 2) Process elements a collection of actions and tasks that define an effective approach to change management (and related activities) for all constituencies involved in the management, engineering, and use of computer software. 3) Construction elements a set of tools that automate the construction of software by ensuring that the proper set of validated components (i.e., the correct version) have been assembled. 4) Human elements a set of tools and process features (encompassing other CM elements) used by the software team to implement effective SCM. 7/4/2025 5

Baselines Change is a fact of life in software development. Customers want to modify requirements. Developers want to modify the technical approach. Managers want to modify the project strategy. Why all this modification? The answer is really quite simple. As time passes, all constituencies know more (about what they need, which approach would be best, and how to get it done and still make money). This additional knowledge is the driving force behind most changes and leads to a statement of fact that is difficult for many software engineering practitioners to accept: Most changes are justified! A baseline is a software configuration management concept that helps you to control change without seriously impeding justifiable change. A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. 7/4/2025 6

Risk Management: Risk analysis and management are actions that help a software team to understand and manage uncertainty. A risk is a potential problem it might happen, it might not. But, regardless of the outcome, it s a really good idea to identify it, assess its probability of occurrence, estimate its impact, and establish a contingency plan should the problem actually occur. The primary objective is to avoid risk, but because not all risks can be avoided, the team works to develop a contingency plan that will enable it to respond in a controlled and effective manner. A Reactive risk management tries to reduce the damage of potential threats and speed an organization s recovery from them, but assumes that those threats will happen eventually. A considerably more intelligent strategy for risk management is to be proactive. A proactive strategy begins long before technical work is initiated. Potential risks are identified, their probability and impact are assessed, and they are ranked by importance. 7/4/2025 7

Risk always involves two characteristics: uncertainty the risk may or may not happen; means there are no 100% probable risks. loss if the risk becomes a reality, unwanted consequences or losses will occur. Hence, it is important to quantify the level of uncertainty and the degree of loss associated with each risk. CATEGORY: Project risks threaten the project plan. That is, if project risks become real, it is likely that the project schedule will slip and that costs will increase. Project risks identify potential budgetary, schedule, personnel (staffing and organization), resource, stakeholder, and requirements problems and their impact on a software project. 7/4/2025 8

Technical risks threaten the quality and timeliness of the software to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible. Technical risks identify potential design, implementation, interface, verification, specification ambiguity, technical uncertaintyand maintenance problems. Technical risks occur because the problem is harder to solve than you thought it would be. Business risks threaten the viability of the software to be built and often jeopardize the project or the product. Top five business risks are 1) building an excellent product or system that no one really wants (market risk), 2) building a product that no longer fits into the overall business strategy for the company (strategic risk), 3) building a product that the sales force doesn t understand how to sell (sales risk), 4) losing the support of senior management due to a change in focus or a change in people (management risk), 5) losing budgetary or personnel commitment (budget risks). 7/4/2025 9

Another general categorization of risks. Known risks are those that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date, lack of documented requirements or software scope, poor development environment). Predictable risks are extrapolated from past project experience (e.g., staff turnover, poor communication with the customer, dilution of staff effort as ongoing maintenance requests are serviced). Unpredictable risks are the joker in the deck. They can and do occur, but they are extremely difficult to identify in advance. 7/4/2025 10

RISK IDENTIFICATION: Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). Generic risks are a potential threat to every software project. Product-specific risks can be identified only by those with a clear understanding of the technology, the people, and the environment that is specific to the software that is to be built. To identify product- specific risks, the project plan and the software statement of scope are examined. The checklist can be used for risk identification. Product size risks associated with the overall size of the software to be built or modified. Business impact risks associated with constraints imposed by management or the marketplace. 7/4/2025 11

Stakeholder characteristicsrisks associated with the sophistication of the stakeholders and the developer s ability to communicate with stakeholders in a timely manner. Process definition risks associated with the degree to which the software process has been defined and is followed by the development organization. Development environment risks associated with the availability and quality of the tools to be used to build the product. Technology to be built risks associated with the complexity of the system to be built and the newness of the technology that is packaged by the system. Staff size and experience risks associated with the overall technical and project experience of the software engineers who will do the work. 7/4/2025 12

Risk Components and Drivers: The risk components are defined in the following manner: Performance risk the degree of uncertainty that the product will meet its requirements and be fit for its intended use. Cost risk the degree of uncertainty that the project budget will be maintained. Support risk the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance. Schedule risk the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time. The impact of each risk driver on the risk component is divided into one of four impact categories negligible, marginal, critical, or catastrophic. 7/4/2025 13

Risk Projection, RMMM Plan: Risk projection (risk estimation) attempts to rate each risk in two ways The likelihood or probability that the risk is real, The consequences of the problems associated with the risk, should it occur. An effective strategy must consider three issues: risk avoidance, risk monitoring, and risk management and contingency planning. To mitigate: Develop a strategy for reducing turnover; Meet with current staff to determine causes for turnover; causes that are under your control before the project starts. risk-monitoring: The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. (Quote Real time example) It is important to note that risk mitigation, monitoring, and management (RMMM) steps incur additional project cost. 7/4/2025 14

Why Risk Management is Important? There are absolutely no cons to risk management if you have the correct strategy. Benefits of a successful risk management strategy include: Prevention of Losses Decreased magnitude of losses. Resources are utilized more effectively to combat risk. Reduced number of reactive situations. Reassures stakeholders, partners, and clients that their data, investments, etc is safeguarded. Identify and promptly grasp new opportunities. Promote continuous improvement. 7/4/2025 15

Technology evolution: Technological evolution is similar to biological evolution, but occurs at a rate that is orders of magnitude faster. Evolution (whether biological or technological) occurs as a result of positive feedback. "The more capable methods resulting from one stage of evolutionary progress are used to create the next stage". When a successful new technology is introduced, the initial concept moves through a reasonably predictable innovation life cycle , In the breakthrough phase, a problem is recognized and repeated attempts at a viable solution are attempted. At some point, a solution shows promise. The initial breakthrough work is reproduced in the replicator phase and gains wider usage. Empiricism leads to the creation of empirical rules that govern the use of the technology, and repeated success leads to a broader theory of usage that is followed by the creation of automated tools during the automation phase. Finally, the technology matures and is used widely. 7/4/2025 16

A technology innovation life cycle; Figure 31.1 (Chapter 31, Pressman Page 810) 7/4/2025 17

process trends: A software procurer s goal is to select the best contractor objectively and rationally. A software company s goal is to survive and grow in a competitive market. An end user s goal is to acquire the software product that can solve the right problem, at the right time, at an acceptable price. We cannot expect the same SPI (software process improvement ) approach and consequent effort to accommodate all these view points, so need changes . As SPI frameworks evolve, they will emphasize strategies that focus on goal orientation and product innovation . Because software engineers have a good sense of where the process is weak, process changes should generally be driven by their needs and should start form the bottom up. Automated software process technology (SPT) will move away from global process management (broad-based support of the entire software process) to focus on those aspects of the software process that can best benefit from automation. Greater emphasis will be placed on the return on investment of SPI activities. 7/4/2025 18

Collaborative Development: Today, software engineers collaborate across time zones and international boundaries, and every one of them must share information. The same holds for open-source projects in which hundreds or thousands of software developers work to build an open- source app. Again, information must be disseminated so that open collaboration can occur. The challenge over the next decade is to develop methods and tools that facilitate that collaboration. A lack of comprehensive collaborative tools is only one part of the challenge faced by those who must develop software collaboratively. Real time example for collaborative development may be design of syllabus by a committee consisting of 10 members. They Physically meet & Discuss?; Share their proposals through documents ? Emails?; share google drive document and all members go on add with different color to identify and finally conduct a online meeting and finalize. 7/4/2025 19

Software Reuse: Reuse-based software engineering is a software engineering strategy where the development process is geared to reusing existing software. The move to reuse-based development has been in response to demands for lower software production and maintenance costs, faster delivery of systems, and increased software quality. More and more companies see their software as a valuable asset. They are promoting reuse to increase their return on software investments. A commercial-off-the-shelf (COTS) product is a software system that can be adapted to the needs of different customers without changing the source code of the system. Virtually all desktop software and a wide variety of server products are COTS software. 7/4/2025 20

Reuse-based software engineering is an approach to development that tries to maximize the reuse of existing software. The software units that are reused may be of radically different sizes. For example: Application system reuse The whole of an application system may be reused by incorporating it without changing into other systems or by configuring the application for different customers. Alternatively, application families that have a common architecture, but which are tailored for specific customers, may be developed. Component reuse Components of an application, ranging in size from subsystems to single objects, may be reused. Object and function reuse Software components that implement a single function, such as a mathematical function, or an object class may be reused. This form of reuse, based around standard libraries, has been common for the past 40 years. 7/4/2025 21

Test-Driven Development: In test-driven development (TDD), requirements for a software component serve as the basis for the creation of a series of test cases that exercise the interface and attempt to find errors in the data structures and functionality delivered by the component. TDD is not really a new technology but rather a trend that emphasizes the design of test cases before the creation of source code. During TDD, code is developed in very small increments (one sub function at a time), and no code is written until a test exists to exercise it. You should note that each iteration results in one or more new tests that are added to a regression test suite that is run with every change. This is done to ensure that the new code has not generated side effects that cause errors in the older code. 7/4/2025 22

The TDD process follows the simple procedural flow illustrated in Figure. Before the first small segment of code is created, a software engineer creates a test to exercise the code (to try to make the code fail). The code is then written to satisfy the test. If it passes, a new test is created for the next segment of code to be developed. The process continues until the component is fully coded and all tests execute without error. However, if any test succeeds in finding an error, the existing code is refactored (corrected) and all tests created to that point are re- executed. This iterative flow continues until there are no tests left to be created, implying that the component meets all requirements defined for it. 7/4/2025 23

Global Software Development Challenges: Global Software Development (GSD) is carried out by teams of knowledge workers located in various parts of the globe developing commercially viable software for a company. Often, centralized software development is moved from home locations to dispersed teams or/and external organizations in remote locations. Challenges: Rapid technology advancement Increasing customer demands Conflicts with software testing teams Limited Time / infrastructure/resources Temporal distance can be caused by time zone difference or time shifting work patterns and can be seen as reducing opportunities for real-time collaboration, as response time increases when working hours at remote locations do not overlap. 7/4/2025 24

Culture can have a huge effect on how people interpret a certain situation, and how they react to it. It is a complex dimension, involving organizational culture, national culture and language, politics, and individual motivations and work ethics. However, the cultural distance can be great even with low geographical distribution. Similarly, a huge geographical distance does not automatically mean huge cultural difference. Geographical distance is best measured in ease of relocating rather than in kilometres. Two locations with a direct air link and regular flights can be considered close even if separated by great distance, but the same cannot be said of two locations which are geographically close but with little transport infrastructure. 7/4/2025 25

CASE (Computer-aided software engineering): Tools of Software Development: Two types of tools used by software engineers: 1. Analytical tools Stepwise refinement. Cost-benefit analysis. Software metrics. 2. CASE tools (Computer-aided software engineering): Software that is used to support software process activities. Provides software process support by automating some process activities. providing information about the software being developed. Currently used in every phase/workflow of life cycle. 7/4/2025 26

Categories of CASE Tools- 'Tools' Tools: Support individual process tasks; Examples: Checking the consistency of a design; Compiling a program; Comparing test results 1. Upper-CASE tools (front-end tools) 2. Lower-CASE tools (back-end tools) 3. Integrated CASE tools (I-CASE) Upper CASE Tool: UpperCASE Tool is a CASE software tool which supports the software development activities upstream from implementation. Upper case tool focuses on the analysis phase but sometimes also on the design phase of the software development lifecycle. For example, diagramming tools, report and form generators, and analysis tools are upper case tools. 7/4/2025 27

LowerCASE Tool: LowerCASE Tool is a CASE software tool that directly supports the implementation (programming) and integration tasks. Lower CASE tools support database schema generation, program generation, implementation, testing, and configuration management. Integration dimension: There are three main CASE Integration dimensions which are as follows : (a) CASE Framework (b) ICASE Tools: Tools that integrate both upper and lower CASE. An automated system development environment that provides numerous tools to create diagrams, forms and reports. It also offers analysis, reporting, and code generation facilities and seamlessly shares and integrates data across and between tools. (c) Integrated Project Support Environment(IPSE) 7/4/2025 28

Categories of CASE Tools- 'Workbenches' Workbenches: Collection of tools that together support, workbenches integrate two or more CASE tools and support specific software- process activities. Hence they achieve: A homogeneous and consistent interface (presentation integration). Seamless integration of tools and toolchains (control and data integration). An example workbench is Microsoft's Visual Basic programming environment. It incorporates several development tools: a GUI builder, a smart code editor, debugger, etc. Most commercial CASE products tended to be such workbenches that seamlessly integrated two or more tools. Process workflows (requirements, design, etc.); One or two activities where an activity is a related collection of tasks. Commercial examples: Power Builder; Software Through Pictures; Software Architect 7/4/2025 29

Categories of CASE Tools- 'Environments' Environments: An environment is a collection of CASE tools or workbenches that attempts to support the complete software process. This contrasts with tools that focus on one specific task or a specific part of the life-cycle. CASE environments are classified as: Toolkits. Loosely coupled collections of tools. Fourth generation. Language-centered Environments. Integrated Environments. Process-centered. 7/4/2025 30

Taxonomy of CASE Tools: 7/4/2025 31

Components of CASE: Design Generator Analysis tool Drawing Tool Code Generator Database Generator CASE repository Document Generator Prototyping Tool Error-checking tool Screen and Report Generator Security and Version Control

CASE repository Centralized database Allows easy sharing of information between tools and SDLC activities Used to store graphical diagrams and prototype forms and reports during analysis and design workflows Provides wealth of information to project manager and allows control over project Facilitates reusability Information repository Combines information about organization s business information and application portfolio Provides automated tools to manage and control access Data dictionary Used to manage and control access to information repository Facilities for recording, storing and processing resources Useful for cross-referencing 7/4/2025 33

An analysis and design workbench Structured diagramming tools Repor t gener ation facilities Data dictionary Centr al information repository Query langua ge facilities Code gener ato r Forms cr ea ti on tools Design, anal ysis and checking tools Impor t/export facilities

Functional Tools Classification: 7/4/2025 35

CASE technolo gy W orkbenches Environments T ools File Integ rated en vironments Process-centr ed en vironments Editors Compilers compar ators Anal ysis and design Programming T esting Multi-method workbenches Single-method workbenches Gener al-purpose workbenches Langua ge-specif ic workbenches 7/4/2025 36

Introduction to AGILE Tool JIRA: JIRAis a tool developed by Australian Company Atlassian. This software is used for bug tracking, issue tracking, and project management. JIRA is based on the Agile methodology and the current version of the Jira is 6. JIRA tool is used because of the following reasons: Plan, Track and Work Faster - JIRA is a bug-tracking tool mainly used to track, organize, and prioritize the bugs, newly added features, improvements for certain software releases. The main source of information - JIRA is the primary source of information for the next software release. Organize the documentation tasks - JIRA tool is used to organize the documentation tasks. Track the progress of our documentation - JIRA tool provides a very important feature, i.e., pie chart macro. In the pie chart macro, you can view tasks such as Open tasks, Closed tasks, Resolved tasks. Helps to meet the deadlines of a documentation release. - You can define the specific due date or deadline for the release of documentation, and even you can configure the JIRA tool with the notifications so that you can finish your documentation in time. Measures the time spent on documentation - JIRA tool is bundled with the Tempo Timesheets, which measures how much time has been spent on the documentation. Provides feedback faster - JIRA tool provides the Confluence pages where you can connect to the issues in just a few clicks. 7/4/2025 37

Introduction to agile tools Kanban: The Japanese word kanban , meaning visualboard or a sign , has been used in the sense of a process definition since the 1960s. Kanban is a workflow management method for defining, managing, and improving services that deliver knowledge work. It aims to help you visualize your work, maximize efficiency, & improve continuously. Originating from manufacturing, it later became a territory claimed by Agile software development teams. 7/4/2025 38

Kanban Principles and Practices: Management Principles Start With What You Do Now Agree to Pursue Incremental, Evolutionary Change Encourage Acts of Leadership at All Levels Service Delivery Principles Focus on Customer s Needs and Expectations Manage the Work Regularly Review the Network of Services The benefits of Kanban 1. Planning flexibility 2. Shortened time cycles 3. Fewer bottlenecks 4. Visual metrics 5. Continuous Delivery 7/4/2025 39

Kanban Practices: 2. Limit Work in Progress (WIP) 6. Feedback Loops 1. Visualize the Workflow 3. Manage Flow 4. Make Process Policies Explicit 5. Improve Collaboratively (using models & the scientific method) 7/4/2025 40

Unit-VI Concludes! Thanks for your patience listening.. 7/4/2025 41