SOFTWARE ENGINEERING @ COGNIZANT LESSON 1: WHAT IS SOFTWARE ENGG? At the end of this session, you will be able to: Understand software engineering as an engineering discipline Understand the importance of framework in Software Engineering Before you delve deeper into software engineering, you must first understand what software is. Software or a software product is set of computer programs performing specific process and the documentation associated with the computer programs (3). Software products can be developed for defined market of customers. An example would be an accounting package, applicable across industries. On the other hand, software products can also be customized and developed for one particular customer. An example would be a customer banking system for a specific bank. Engineering is a science. Software Engineering involves art, craft, and science. It is an amalgam of artistry, craftsmanship, and scientific thought (4). You will now move on to the development of software product. In most engineering disciplines, specifications are the first step in the development of a product. Consider the case of house construction. One starts with specifications, goes on to design, and finally building and finishing the product. Similarly in software development, one starts with product requirements, followed by architectural details, and then proceeds to building, that is, developing the code. It is then followed by reviewing and installing the product. (5) Coding and development is one of the major activities in Software Engineering. But software engineering goes much beyond coding. It consists of various activities to encompass all aspects of software production, such as requirements, specifications, design, coding, testing, integration, documentation, deployment, and maintenance. Coding would occupy as little as 5 percent of the total work involved in a Software Engineering Project. Although artistic and scientific in its scope, it has to adhere to several time-tested processes pertaining to the different aspects.
Now that you know the processes involved in software development, take a look at the number of people involved. They are spread across the managerial, technical, and end user cadre. And like any other industry, software is linked to peripheral issues, such as business, Contractual, Legal, and Environmental. Hence, remember, Software is "Not Just Some Pretty Code".
As mentioned, the process of creating software is more than coding -- involving people, processes, and time-tested activities. Developing software involves opportunity of individual expression, but it needs to be brilliance encapsulated in a framework. Small programs can be written in an ad hoc manner by a single bright individual. However, complex software solutions are seldom developed by armchair programmers. For complicated systems to be successfully built, one has to be innovative and good while sticking to rules, methods, processes, and teamwork.
Software development can be compared to art. Imagine building the Sistine Chapel alone and without a blueprint. The best works of art require discipline, teamwork and planning. Art requires blue print and team work. In this session, you have learned that: Software engineering is the art, craft, and science of building large, important software systems. It is an amalgam of artistry, craftsmanship, and scientific thought While being a major aspect, software engineering goes much beyond coding Software engineering is akin to art, which cannot succeed without a blueprint and teamwork ===================================================================== === LESSON 2: SOFTWARE PROJECT STAGES Consider this scenario (10). Doing things using a development methodology, and in a step by step manner, ensures successful product, regardless of which industry the product belongs to. At the end of this session, you will be able to: Explain the concept of a Software Development Lifecycle (SDLC) Describe the various stages in a Software Application Development Project, and Identify the Elements of a Software Application Development Stage Software Engineering is not just Code Construction. Each Software Application that is created follows a well defined set of activities, and has a well defined Life Cycle from initiation to the retirement of the Software Application. Similar to a car manufacture, a software application development project has well defined stages that are implemented in a predefined fashion to create the software application.
The Various Stages in a Software Development Life Cycle are Requirement, analysis, design, coding, testing, Implementation, and Maintenance/Post Implementation. In the next few pages, you will learn about each of these stages in detail (12, 13). In the Software Requirements Stage, the required functionality or behavior of the software is identified by the Software Engineer. These Requirements are documented in the Software
Requirements Specifications Document. The Analysis and Design stage, translates requirements into a representation of the software that can be assessed for quality before coding begins. In this stage, typical documents that get created are the functional specifications document, design documents, and the program specifications. In the coding stage, the executable that can be read by the computer is created. Individual modules of programs are assembled together to create the final executable of the software application. Once Code has been generated, program testing begins during the Testing stage. Testing process focuses on the logical internals of the software, ensuring all statements have been checked for correctness. It also focuses on the functional externals, that is, conducting tests to uncover errors and ensure that defined input will produce actual results that agree with the actual results. At the implementation stage, after all tests have shown that the completed software works as intended, it is deployed in its production environment. Implementation is a planned activity and steps pertaining to it are documented as part of the Roll-Out Plan. A series of checks and reviews are conducted in this stage to ensure that all components of the completed software have been installed correctly. Software undergoes change after it has been deployed and delivered to the customer. Change will occur because errors may be encountered, or because the software needs to be adapted to meet changes in its external or operating environment, or because the customer requires functional or performance enhancements. These are issues that are resolved during the Maintenance or Post Implementation stage. You will now learn about the basic building block of any stage. Basic building blocks of a Stage are Tasks. Activities explain how a task needs to be performed. See what each of them signifies. In the next few pages, you will learn in detail about elements of any software development stage. You will now learn about the various elements of a stage. The Entry Criteria provides inputs which can be documents or tasks. It is then followed by the Task or list of activities that are implemented to complete the process. The Verification consists of reviews and approvals that confirms adequacy of the activities done during the Task period. The stage ends with an Exit criteria which consists of work products or documents that may serve as an Entry Criteria for the next Stage.
Here is an example that describes the Elements of the Requirements Stage. The Entry Criteria for Requirements Stage is the Business Need. For example, the client requires a system that will automate the process of banking according to his needs. Tasks of the Stage would include activities like requirement capture, requirement analysis, and requirements documentation. Work Products created in this stage could be completed requirements gathering checklists and Software Requirements Specifications. As part of Verification the completed SRS document will be reviewed by the Project Manager and approved by the Client Representative. Signed off SRS will be Exit Criteria for this stage, which would become the Entry Criteria for the next Stage, Analysis and Design.
In this session, you have learned that: The SDLC is a sequence of steps that organizes the development of a software product The various stages in the SDLC are Requirement, Analysis, Design, Coding, Testing, Implementation, and Maintenance or Post implementation The building blocks of any stage are Activities and Tasks.
The elements of a stage include Entry criteria, Task, Verification, and Exit criteria.
===================================================================== ===LESSON 3: REQUIREMENT DEVELOPMENT AND MANAGEMENT What is needed is what is often stated in the requirement specifications. What is wanted is not what is often stated but is inherent to business and so it is called implied requirements. Collecting the requirements is very difficult.
Software requirement is a necessary feature or an environment needed in the software.(17)
LESSON 4: SOFTWARE ANALYSIS AND DESIGN At the end of this session, you will be able to: Explain the concept of software analysis Explain the concept of software design
Describe the types of analysis and design techniques
In the analysis and design stage of software development, the focus gradually shifts from "What to build" to "How to build". Over the next few pages, you will learn about the analysis and design stage in detail. You must be aware that the Requirement Specifications Document acts as the exit criteria of the Requirement Stage. This same document is the entry criteria for the Analysis Stage. Functional Specifications Document is the exit criteria for the Analysis Stage and in turn the entry criteria
for the Design Stage. In the Design Stage, the Detailed Design Document is the most important document that gets created and is used as the basis of Code Construction in the Code Construction Stage.
Analysis and Design are one of the foremost stages in software development cycle. (23, 24) Analysis is the software engineering task that bridges the gap between the software requirements stage and software design. The objective of software analysis is to state precisely what the system will do to provide a solution to the client's need at a functional level. This is captured in the Functional Specification Document. Design creates a detailed Design Document that acts as the "blue-print" for the developers or the team that will construct the code to create the system. The typical elements of software design include Program Architectural Design, Data Design, Interface Design, and Component Design. To understand each element of Software Design, here is an example of a Travel Booking System called the SmartBook System. This is to be used by the Travel Agents to book Airline Tickets or Railway Tickets. This is the overall Architecture Design for the SmartBook System. It defines the relationship between the structural elements of the Software Application being built. Architecture for the system needs to be built as part of Software Analysis and Design Stage. The Data Design specifies the data structures needed to implement the solution. It includes the Database or File System Space Requirements. It also includes Table or Layout details, such as Table or Record name, Column or Field names and description,Type of Column or Field the length, Default values, Edit or validation conditions associated to a Column or Field, and Details of all Keys or Indexes of a Table or Record. These are the interface designs which describe how the software communicates within itself, with the systems that interoperate with it and the Humans who use it. Interface Design for the system needs to be built as part of Software Analysis and Design
Stage. The Component level design transforms the structural elements of software into procedural description of the Software Component. It includes Program specifications, that is, the Functions or Algorithms that define the procedural design. (25, 27)
Here is a case study to understand the concept of software analysis and design better. Mercury Travels is a premier Travel Agency of the country. Mercury wants to automate its business processes. Requirement Analysis reveals that the specific requirement of Mercury is to create an Air or Rail Ticket Booking System for the Travel Agents. Other business processes will not be included in the current automation initiative. (Refer page 8 and 9). To begin with, the software requirement specifications document is put in place. The business need is the basis for creation of the software requirement specification document. This activity is completed in the Requirements Stage of an Application Development Project. Each of the Requirements is then decomposed further to create the Software Functional Specifications. The Functional Specifications express the system to be built in a language that designers of the system understand. The problem presented by the Requirements is analyzed using Analysis Models. Creation of the Analysis Models and the Functional Specifications often take place simultaneously. (31) Here, you can see an Analysis Model that is used to express the problem. Such a diagram is called a Data Flow Diagram, in which each bubble indicates the activity taking place. The box on the other hand, is used to denote an external source or sink of information. The parallel bars denote data store or file while an arc is used to denote the flow of components among the other 3 components. Note that SRS 01.1 has been expressed using processes 2a and 2b. (32)
The bubble 1 which denotes the activity, "Determine form of travel" has been factored further to a lower level of D F D. (33) The Analysis Models form the basis of the Program Specifications which is an essential component of the Design Document. (34) In addition to Program Specifications the Design Document includes other details like Data Design and Program Architecture Design. Data design involves the overall data model design for the application. Program hierarchy and program-level interfaces are addressed in the program architecture design.
Look closely at the examples here. There are two ways you can visualize the building or construction of a house. Builder may appoint a bricklayer to create the walls and carpenter to create windows, fit windows into the walls etc and slowly create the house. Alternatively, the builder may fit the standard models of doors, windows, roofs, walls, and rooms available in the market to create the house. This is how most buildings get built now. (37) There are two approaches to creating the Design Specifications in a project. One is the Structured Analysis and Design Technique that can be traced to the 1970s. The other is a newer concept called the Object Oriented approach which as a concept was developed from 1990s. (38) SSAD makes a heavy use of functional decomposition. System behavior takes a secondary role here. Like in the case of building a house brick by brick.(39) The object-oriented technique on the other hand focuses on the system behavior. In the recent years OOAD technique has become very popular with software engineers. Objects represent a sample expected system behavior and they are called upon to function as a whole. Re-usable and
common objects help in achieving greater modularity and are manageable from the project management perspective. (40) In this session, you have learned that: In analysis and design the focus is on "HOW to Build" a solution and not on "WHAT to Build" Analysis is the software engineering stage that bridges the gap between the software requirements stage and software design stage Functional Analysis Document is the most important document that is created in this phase In the software design stage, detailed design document is the most important document that is created This acts as a "blue-print" to be used by the eventual implementers of the system
The elements of software design are Program architectural design, Data design, Interface
design, Component design. There are two ways in which software engineers visualize "HOW to build" a solution during analysis and design stage, namely, Structured Analysis and Design (SSAD) technique and object-oriented technique ===================================================================== === LESSON 5: CODE CONSTRUCTION-V1 Your builder has taken your house requirements and has given you the building plan and the prototype of your house. So in your mind, you have the picture of your dream house ready. What do you think is the activity that the builder has to engage in now? Yes. You guessed it right. The builder will need to construct the house now. At the end of this session, you will be able to: Explain what code construction is and in which part of the software development lifecycle code is constructed Illustrate the process of code construction Describe good programming practices You will now learn how code is constructed. Design provides the basis for code construction. A unit test helps a developer to consider what needs to be done as requirements are nailed down firmly by tests. There is a rhythm to developing software unit tests. First, you create one test to define some small aspect of the problem at hand. Then, you create the simplest code that will make that test pass. Then, you create a second test. Now, you add to the code you just created to make this new test pass, but do not write any more code until you have created a third test. You continue until there is nothing left to test. The next page holds an activity for you. You have to
connect the numbers in a series beginning with number one. For example, click number two to connect number one and number two. (42) Now, you know that any unstructured piece of work is difficult to understand and comprehend and that code is no exception. You should remember that even though completed code is an important deliverable that is given to the customer, software engineering is not just coding. Coding (shifting of focus from “what to build” to “how to build” a solution) is a stage within the software development life cycle. The subsequent page explains the coding process in detail. Design documents and unit test cases that are updated with test cases are important inputs for the coding stage. Code construction using language-specific coding standards, peer review of code, and updating code based on review comments are major tasks in this phase. Peer-reviewed code is the output of the coding stage. (43) This page delves into details of the tasks and activities of the coding stage. It must be noted here that peer review of code is a very important task in the code construction stage. (44)
Before we move forward, let us take a look at the benefits of peer review. (45) Here you will see what happens if you do not use proper coding standards. (48) A coding standards document tells developers how they must write their code. Instead of each developer coding in their own preferred style, they will write all code to the standards outlined in the document. This makes sure that a large project is coded in a consistent style, that is, parts are not written differently by different programmers. Not only does this solution make the code easier to understand, it also ensures that any developer who looks at the code will know what to expect throughout the entire application. (49) This section outlines concepts that are generic in nature and applicable to most software tools and platforms. Platform-specific conventions and guidelines are covered under the relevant
company standard. The relevant language-specific standard must be referred to when constructing code in a specific language.
CODE LAYOUT AND PRESENTATION ASPECTS: It is necessary to have a good coding layout structure. Good coding structure improves the readability and maintainability of code. A good layout brings out the logical program structure through appropriate use of blank lines, spaces, and indentation. Let us take the example of an essay written by two young students of class five. Student A has used a clean paper with the necessary punctuation marks, spaces, paragraph settings, used uniform fonts, and cases. This is much easier to read than the one written by Student B, which has not been written neatly and clearly. These were the basic tenets of sentence construction that we had learned when we were in school. This is true even when you write your first program. This page deals with the good practices on code layout and programming. Code layout deals with the structure of the code and the way it is laid out. It affects readability and ease of modification of code. (51) Here are the guidelines to be followed for maintaining presentation
This page outlines the concepts pertaining to sentence construction that are generic in nature and applicable to most software tools and platforms. Platform-specific conventions and guidelines are covered under the relevant company standard.
Code-level readability is not about using comments only. The main contributor to code-level readability is not comments, but good programming style. Check the first example of code provided. This reflects bad programming style. Check the second example. Even though this code does not use any comment, it is much more readable. It takes us toward the goal of "selfdocumenting code". (54) When commenting a source code, always use comments judiciously so that we can ensure our code is readable and clear. (55) Use of headers in a program will not add to its functionality. It is of immense help during maintenance of a program. (56) Naming conventions for a language should be as per the recommended convention documented in the coding checklist. The benefits of adhering to naming conventions is that somebody going through the program can get an idea about the purpose of various entities from their names, thus enhancing program readability. Conventions bring about uniformity in the way program entities like variables, symbolic constants, procedures, and functions are named. Teams can develop their specific naming conventions for identification of programs. (57) In this page, you will learn about the declarations standards in a piece of code: • • • • • A program consists of two basic entities, data and instructions. Data elements or structures should be declared and initialized before (executable) instructions. All header files and libraries used in the program (whether standard or user defined) should be declared. All global variables need to be declared and the number of global declarations used should be minimized so as to reduce coupling between modules. All unique or complex variables or data structures should be described through appropriate comments, clarifying the reason for such complexity. Functions and their parameters should be declared taking care to ensure that no type mismatches occur during runtime between the calling and called module or function or procedure. When using arrays, remember it is cumbersome to handle arrays having more than three dimensions. Such arrays should be avoided.(59)
You will now learn what defensive programming is. As a programmer, you should be able to envisage areas in your programs that can initiate errors in the behavior of the software application. Hence, appropriate methods should be used to prevent the occurrence of errors. (60) Continuing with defensive programming ensures that your program is secure and prevents unauthorized access. (61) Expectations change and hence requirements change, and so it is but natural that programs have to be modified in order to suit the new specifications. This means that the program should be flexible enough to be modified with little or no effort. This page identifies some practices that help in creating modifiable or flexible programs. (62)
ON-SCREEN ERROR AND HELP MESSAGES: Now, you will learn the importance of On-Screen Error and Help Messages. In this example, the customer inserts his debit card in the ATM machine. But the machine does not accept the card and ejects it immediately, without showing any error message. This makes the customer frustrated. The next page provides some good practices that should be followed in case of textbased error and help messages. Design of the On-Screen Error and Help Messages have a strong bearing on user-friendliness. This page puts forward some of the guidelines that could be followed by the developer.
Before we conclude, remember the following points whenever you are constructing any code. (66) In this session, you have learned that:
Coding is a stage within the software development lifecycle. The inputs for the code construction include design document and the unit test cases
The process of code construction involves using design document and coding standards
to create code, aligning code to the unit test cases, and peer reviewing code before delivery. It is a good programming practice to follow some platform-specific conventions and guidelines that have been documented. This will help the developer to write legible codes.
===================================================================== === LESSON 6: TESTING Testing is an activity that is used to discover errors and correct them, so that we are able to create a defect-free product for our customer. Let us take the example of a house. The client had specified requirements of the house she wants. The tester tested the house to find out if all requirements of the client had been met after delivery. The tester created the test execution details document, which detailed the scenarios or test cases. The tester also created the results of the test execution, which are referred to as the test log. (67) At the end of this session, you will be able to: Learn about the testing stage and its process in software development Explain the various types of testing Study the important test case design methods Testing is an important stage which follows the Coding stage in the software development life cycle. The objective of testing is to evaluate if we have created the system correctly. During the earlier stages, the focus was to check what is being built but in testing when we have the end product ready, our focus shifts to validate whether the product that has been built has been built correctly or not. Hence, the focus shifts from building the product right to building the right product. Now, an attempt to define software testing is made. Testing is a systematic activity where records of test execution need to be maintained. (68) Testing is the process of executing a program with the specific intent of finding an error. Success of a test is determined by the number of errors it has uncovered. Tests can be conducted by the developer or by an independent testing team. What one should remember is that the role of a good tester is to show the presence of the defects or errors of that software. This page explains the major activities and tasks of the testing stage. Creation of the test strategy is the first step. It is based on the Requirements Document, the Functional Specifications Document, and the Design Document. The test strategy describes the overall plan and approach to be taken for testing, the deliverables, and the process for test reporting. The next step is to create the test cases, containing the individual scenarios, which would be tested with their expected outcomes. Test cases are executed by the tester and results of the tests are documented in the test log. The defects of testing are recorded in defect-tracking tools such as the internal tool Prolite or the external tool called Test Director, depending on the requirement of a project. The owner of the application being tested then updates the application, closes the defects, and updates Prolite with the defect status in the tools. Re-testing may be conducted to verify closure of defects.
In this page, you will know the people who are responsible for testing a software application: • • • Software testing can be conducted by the developers of the system or an independent testing group who are part of the organization that has built the system. Software testing can also be conducted by the client or the ultimate users of the system. The team responsible for the different types of testing needs to be decided upon during the planning stage.
Here, you will learn about the various stages in testing: Software testing is usually performed at different levels of abstraction of the application along the software development process by the builders of the system. There are three testing stages: Unit testing, integration testing, and system testing. The objective and the abstraction levels of the application to which these tests are performed are different. Unit tests are performed on the smallest individual units of the application, the integration tests on a group of modules and their interfaces while the system tests are for the entire system and the interfacing external systems. In this illustration, you can see where the three major types of testing fit into the software development life cycle. There is one more stage in testing that is done by the end user of the system. This is referred to as the user acceptance test. This is to verify the functionality of the system from the end user's perspective. Here we can see where the user acceptance testing fits into the software development life cycle. (72) You will now learn about each of the testing stages in detail. First you will know about unit testing. In this page, we see a small child building a doll house. She checks each building block to ensure that it is in line with the design of the doll house as she creates them. Similarly, unit testing concentrates on each unit or component of the software as implemented in the code and
checks that it is in line with the program specification and the detailed design. The primary focus of unit testing is to validate the logic, the structure, and the flows of the concerned program. It is often performed by the software developer. Moving on to integration testing, you see that the builders of the doll house now begin to put the individually tested blocks of the house together, that is, they integrate the unit tested units. The primary intent is to uncover errors associated with interfaces when the unit-tested components are integrated as a module. The next page talks about system testing. (73) After the doll house has been completed, it is checked fully by the builders of house to ensure that it is complete and ready for habitation. Additionally, builders check if the house is secure and can withstand rain or thunder or lightning and other environmental factors, so that it can easily be placed in its intended environment. System testing in software checks the performance and functionality of the complete system after all unit tested units have been integrated as per the build plan. It also evaluates functionality with interfacing systems. Non functional requirements like speed and reliability are also verified during system testing. (74) Finally, looking at the acceptance testing, you see that the doll house has been placed in a children's park. The acceptance test verifies whether the system created is in conformance with user requirements when placed in its 'real' environment. Acceptance tests are often conducted by the client or by the end users. Developers are not often involved in this type of testing activity. Now, you will learn about an important concept of testing called regression testing. Regression testing will be done to ensure that the actions taken to rectify the defect have not produced any unexpected effects. Regression testing should be done at all levels of testing, such as unit, integration, system, and acceptance testing. The following page gives you an example that will help you learn the concept of regression testing. (75) As seen in the previous example of a client stating her requirement for her house, it was observed by the tester that the location of the door was incorrect and a defect ID was allocated to it. When correcting this defect, the constructors may remove the door and move it to the rear side. In this process, other sections of the building may get damaged. So when correcting the defect of incorrect door location, care must be taken to ensure that unintended defects like cracks in the walls are not introduced in the building. Regression testing takes care of such unexpected issues that occur as a result of fixing defects. This page explains what the focus is for each type of testing: Unit testing uses code and detailed design as an input to check correctness of individual units. Integration testing uses the system design and the functional specification document as an input. System testing uses the overall functionality of the system as given in the functional specifications and software requirements. It also evaluates the non- functional requirements.
Acceptance testing is the test conducted periodically by client representatives to check if client requirements have been met adequately. Regression testing, on the other hand, retests the tested sections of the software to ensure no unintended error has been introduced.(76)
Here is another very important concept of software testing, that is, the test case. Test cases are scenarios that are executed by the testers on the completed application to determine if the application meets a specific requirement. One or more test cases may be required to determine if a requirement is satisfied. A good test case is one that uncovers errors in a complete manner with minimum time and effort. Considering the earlier example of the completed house, the analysis, 'check if the color of chimney is red' is a test case. If for the same example, when the test case is written as 'check if the door does not open with a wrong key', becomes a negative test case. Hence, we learn that a test case is a statement specifying an input, an action, or an event and expects a specific response after execution. (78) This page explains the two approaches to test case design. The white box approach which is based on the internal workings of the system and black box or behavioral approach which deals with the external functionality of the application or its part being tested irrespective of the internal details. The following pages will give more details on these two types of approaches. The white box approach is used to create test cases to check if 'all gears mesh', that is, to check if the internal operations are performed according to specifications. This tests all the logical paths within the unit being tested and verifies if these are functioning as required in the design.
Black box test case design approach does not consider the internal workings of the application. It focuses on the functional requirements alone, and it is designed to verify if the inputs are given correctly the output generated is also correct. It should be noted that black box testing and white box testing are not alternative approaches to test case design. On the other hand, they complement each other. Here are the activities performed in the testing stage for the SMARTBOOK System. The test scenarios or test cases are logged and tracked in a tool with the detailed information about the test case execution. Individual program units are tested as part of unit testing and the results are logged in the tool. Subsequently, each functional module is considered and integration tested for its functioning and logic. All interface-related tests between program units are covered under integration testing. The system testing follows where all the functional modules are taken together and the application is tested as a whole incorporating the interfacing issues between the functional modules. Finally, User Acceptance Testing is conducted by the users of the system and the resulting errors are corrected prior to staging the system into production. (81) This page explains the salient points you should remember about testing. Test execution activity starts after code has been constructed with unit testing of individual modules. This will be
followed by integration testing and system testing. However, it should be noted that test planning activity occurs much earlier in the software development life cycle. In fact, user acceptance test plans and cases are prepared along with the requirements document. To improve the quality of the code being delivered, it is a good practice to 'Test before you code'. The model shown is also called the V-Model where each stage is associated with the corresponding review and a specific test case is prepared for testing at a later stage.
In this session, you have learned that:
Testing is an important stage within the software development life cycle. The objective of a good test is to show the presence of errors and not the absence of
A good tester should attempt to break the system to uncover undiscovered errors. The stages important in testing are unit testing, which targets a single module, integration
testing targeting a group of modules, system testing that targets the whole system, and acceptance testing targeting the overall system and conducted by users. There are two important approaches that are used to design test cases, namely, the black box approach focuses on the functional requirements of the software, and the white box approach focuses on internal workings of the software. ===================================================================== === LESSON 7: IMPLEMENTATION AND POST IMPLEMENTATION
At the end of this session, you will be able to: Explain what software implementation and post implementation are Illustrate the activities involved in the implementation and post implementation stages First, you will learn about the implementation stage in software development. In this example, you see a statue of a jockey being built. This statue is created in the sculpture workshop. It is being built as per the requirements provided by Company 123.Company 123 wants the statue to be installed in a park that they own. The installation team of the sculptures transfers the statue to its intended environment. They prepare the site for installation of the statue. After the site is ready, workers install the statue in the park for public viewing. We can see here that there is a communication activity associated with the unveiling of the new statue. Similarly, in case of software application development, after the software is constructed and tested, it needs to be installed or implemented in its working environment for the intended users to make use of it. After the system is tested completely, it is delivered to the onsite team. The onsite team implements the tested application in the client environment. Software implementation or the deployment stage starts after user acceptance testing is completed. It involves all the activities needed to make the software operational for its users. Here, the focus is to verify that the software or the product that has been delivered is meeting the need, that is, whether the product has been rightly built. Shifting of focus from “have we built the right product” to “have we installed the right product correctly” The main activities in the implementation stage are planning and defining the process for rollout, to deploy the new application, train users on the new system after the rollout has been implemented, and communicate the details of deployment to relevant people. (83) Now you will learn about the post implementation stage in software development. After the statue has been installed, as you saw in the earlier illustration, any complication can arise. A part of the statue may get damaged and may need to be mended. In that case a complaint is lodged with the sculpture company. Stakeholders of Company123, who own the statue, may want a new feature to be added, or one of the stakeholders may want to change an existing feature of the statue they had purchased. Thus, the activities involved in the post-implementation stage are support necessary to sustain, modify, and improve a deployed system. Similarly, in software application development, after a software has been implemented in its intended environment, support may be needed because of the discovery of a bug or defect; the need for enhancing the existing functionality of the software, or the need to change the existing features or functionality of the software application. Post implementation activity may be the regular warranty support. This includes providing the support necessary to sustain, modify, and improve the operational software of a deployed system to meet user requirements. Shifting of focus from “have we installed the right product” to “does the product function correctly”. Post Implementation is the final stage in an application development project. This page gives you some details on the post implementation stage.
A process document describing the post-implementation process guides the activities performed in the post-implementation phase, which generally consists of the warranty period as per the contract signed by the client. It also includes helpdesk support, fixing the bugs, and planning for release of the reworked application and all other activities pertaining to the overall support of the system in action.
Here is an illustration of the activities performed in the post implementation stage of an application development project. The requests given by the users are first classified as bugs or production support tasks and subsequently logged in a tool like e-tracker, for tracking followed by analysis for resolution of the request. The resolution is then implemented and delivered to the client for implementation. Production support issues are similarly analyzed and fixed in the application prior to their closure. (85) Application maintenance projects have a well-defined life cycle consisting of stages like Requirements, Knowledge Transition, and Steady Stage. If the post-implementation activities are continued over a sustained period, the project is converted to an application maintenance project and the contract is revised accordingly. (86) In this session, you have learned that: Software implementation or deployment is an activity that makes a software application available for use A new application is deployed as per the roll-out plan Post-implementation is a support activity required to sustain, modify, and improve a deployed system This stage generally refers to the two to six month warranty contract that may be signed with the client The main activities in the implementation stage are, to roll out or deploy the new application, and train users on the new system
Post-implementation activities are implemented as per the post-implementation process document
The process tool used to manage post implementation activities is e-tracker.
===================================================================== === LESSON 8: THE MAINTANENCE MODEL (APPLICATION VALUE MANAGEMENT) Software maintenance is the process of enhancing and optimizing deployed software as well as remedying defects in the software. Here is an example of a constructed house. Due to wear and tear, the delivered house would require continuous maintenance. This would include any of the following: Quickfixes, such as repairing faulty electricity or plumbing appliances. Additional requirements to be added with the changing needs, such as adding an extra floor to the house. Major repairs, which also require in-depth analysis and designing of the solution prior to its execution, such as relaying the air-conditioning for the entire house.
At the end of this session, you will be able to: Learn about the fundamentals of software maintenance Study the different stages and activities of the maintenance process Know the service-level agreements and their relevance Identify the key issues in software maintenance Learn about the tool, eTracker When in operation, defects are uncovered, operating environments change, and new user requirements surface. Software maintenance is defined as the totality of activities required to provide cost-effective support to software. This includes modification of a software product after delivery to correct faults or defects, adapt the product to a modified environment, and incorporate additional features in the application to cater to the new requirements. Software maintenance can be categorized as: Corrective maintenance: Is a reactive modification of a software product performed after delivery to correct discovered problems and it is also termed as bugfix. Adaptive maintenance: Is the modification performed on a software product after delivery to keep a software product usable in a changed or changing environment. It is also termed as enhancement. Perfective maintenance: Is the modification of a software product after delivery to improve performance or maintainability. It is also called performance tuning.
Preventive maintenance: Is the modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults. This is also termed as bugfix.
Here is an example of a house built earlier and which requires maintenance at a future point in time. The maintenance person has to initially plan as to how the contract of maintenance would be executed and which areas would be in the scope of the maintenance. He might exclude the electrical maintenance from the contract and he would decide on the team that would be responsible for maintenance and other business issues. After the contract is signed, the architect responsible for the maintenance studies the building plan in detail, including the plumbing layout. Then, the architect passes on the details to the maintenance team. This stage is for developing an understanding of the existing building. Now, based on the request of the customer the house is maintained over a period of time. As discussed earlier, the maintenance can be of the nature of quick fixes or minor repairs, such as electrical or plumbing repairs, a major change, such as repainting the house and incorporation of additional requirements, such as designing the plumbing system or incorporation of air-conditioning in the house. When the software is in operation, defects are uncovered, operating environments change, and new user requirements surface. The principal stages of an application maintenance project consist of planning, knowledge transition, and finally the steady state maintenance activities. (89) You have seen what an application maintenance process involves. Now, you will know about the model followed by the application maintenance process. The application maintenance model consists of planning, knowledge transition, and service steady state. The planning phase primarily involves understanding the need of the customer in terms of what is expected from the maintenance team. This involves a detailed discussion with the client to identify the requirements and finalizing the contract. The activities in this stage are: Business planning at the organizational level: This includes proposal development, estimating for resources and cost, and defining the escalation mechanism. Maintenance planning at transition level: This includes scope definition and the execution process adaptation. And finally knowledge transfer planning, which involves defining the entire methodology to be adopted during the knowledge transfer phase and a detailed schedule of the KT phase. (91) For maintaining the existing application developed by another vendor, the maintenance team needs to understand the functionalities and the technical details of the system. Hence, a knowledge transition phase is required prior to the commencement of the maintenance activities. The knowledge transition phase primarily consists of obtaining: The knowledge about the application, considered for maintenance, from the client. Guided support under the supervision of the client, and finally a plan defined for transitioning the obtained knowledge to the team for future support. Initially, the application identified for
maintenance has to be thoroughly studied by the K T team. This includes a detailed understanding about the business processes that the application caters to and the functions served by the application. This also includes understanding of the technical details about the application, the environment in which the application is operating along with the details of interaction with the interfacing systems. Finally, the application inventory is collected by the K T team for providing support in future. After obtaining an understanding of the entire maintenance scenario, the K T team performs the support activities under the supervision of the client's team. This helps in getting familiar with the support activities and also in defining a detailed plan for transitioning the knowledge obtained and subsequently transferring the knowledge obtained about the system to the entire maintenance team primarily at the offshore centre. The infrastructure required to perform the support is also built during the stage and a knowledge repository containing the details of the maintenance project is also built to capture the entire information, learning, and mistakes committed during the execution of the project. This helps in easy transitioning of resources down the project timelines. (92,93) The steady state support involves resolving the service requests sent by the client, optimizing the processes continuously over time. This involves measuring and analyzing the metrics to identify the weaknesses in the process as well as the application being maintained and defining the corrective measures to eradicate the weaknesses. Finally, offering the client value additions identified and obtained over the maintenance period. This includes proactive root-cause analysis of the recurring problems and the necessary measures for improvement. SLA-based measurement also helps in tracking the performance strictly on a defined interval at every level. (94) The steady state requests can be classified based on the type of request or the level of support and the size of the request. The requests can be of the following types: FIRST LEVEL-Production support, SECOND LEVEL-Bugfix and THIRD LEVELEnhancements Similarly the bugfix and the enhancements are further classified into Minor, Major, and Super major, based on their size. Software maintenance sustains the software product throughout its operational life cycle. Modification requests are logged and tracked, the impact of proposed changes is determined, code and other software artifacts are modified, testing is conducted, and a new version of the software product is released. It also includes training and daily support through: helpdesks that are provided to users, or any documentation regarding the application. The enhancement bugfix request, popularly called the EBR, primarily consists of the enhancement or bug description, technical details, the proposed resolution for incorporating the request, and the results of testing done after the change.
The set of activities performed for software maintenance in the steady state can be sequentially classified into: Modification request, Classification and Identification, Analysis, Design, Implementation of the change in the necessary places, System Testing, Acceptance Testing, and Delivery. Based on the size, type, and complexity of the request, one or more of these phases are integrated or eliminated from the execution cycle.
The workflow shown here actually illustrates the functioning of the onsite and offshore team in a typical maintenance scenario, describing the activities performed for the various levels and type of support.
Here is a description of different measurement areas and the areas where improvement can be identified over a period of time. (99) Here, you will know the term service-level agreement and will see its importance in the maintenance projects. A service-level agreement is a contractual service commitment that describes the minimum performance criteria a provider promises to meet while delivering a service. This is usually in measurable terms. It typically also sets out the remedial action and any penalties that will take effect if performance falls below the promised standard. It is an essential component of the legal contract between a service consumer and the provider. (100) Finally, looking into the value additions offered to the client includes implementing an S L Abased management, which keeps a constant eye on the health of the project and gives a measure of the performances. This subsequently leads to the improvement in the areas of productivity, schedule, and finally the cost involved. The root-cause analysis done at intervals helps in identifying the pain areas of the application and hence focuses on correcting them.
You will now learn about some key issues and challenges faced during application maintenance. The key issues that should be adeptly dealt with for maintaining the software effectively can be classified as: • • • • Technical issues, which includes limited understanding, extent of testing possible, and the maintainability or is it maintenance of code. Management issues that include staffing and process-related issues. Cost estimation that adapts the right methodology as parametric or judgmental. Measures with respect to Analysis, Changeability, Stability, and the Testability of the software.
Here is an overview of eTracker. eTracker is a tool used for managing the maintenance projects in Cognizant. It is a request management tool where individual requests can be planned and tracked to closure. It also has features like automated metrics management, defect management, and risk management. The tool represents the information stored in the form of various types of reports and charts. In this session, you have learned that: The maintenance process fundamentally includes correction of defects, adaptation to modified environment, and incorporation of additional requirements. They are termed as production support, enhancements, or bug fixes Maintenance can be categorized into proactive, reactive, correction, and enhancement. The combination of these categories result in what are termed as Preventive Maintenance, Perfective Maintenance, Corrective Maintenance, and Adaptive Maintenance The three primary stages of maintenance include Planning for transition, Knowledge transition, and Steady state The classification of requests is based on a combination of their size and type A service-level agreement is a contractual service commitment that describes the minimum performance criteria a provider promises to meet while delivering a service. This is usually in measurable terms The key issues that should be adeptly dealt with for maintaining the software effectively can be classified as:
a) Technical issues, which include limited understanding, extent of testing possible, and
maintainability of code
b) Management issues that include staffing and process-related issues c) Cost Estimation that adapts the right methodology as parametric or judgmental d) Measures with respect to Analysis, Changeability, Stability and the Testability of the software eTracker is used for tracking requests for a maintenance project
===================================================================== === LESSON 9: UMBRELLA ACTIVITIES Any standard software process model would primarily consist of two types of activities: A set of framework activities, which are always applicable, regardless of the project type, and a set of umbrella activities, which are the non SDLC activities that span across the entire software development life cycle. At the end of this session, you will be able to: Define umbrella activities in a software life cycle Explain the usage and importance of the following umbrella activities: a) Traceability Matrix-its definition, usage, and relevance in the SDLC b) Peer Reviews, Forms of reviews, Planning and execution of peer reviews Umbrella activities span all the stages of the SDLC. They are not specific to any particular life cycle stage. The umbrella activities in a software development life cycle process include the following: 1. Software Project Management 2. Formal Technical Reviews 3. Software Quality Assurance 4. Software Configuration Management 5. Re-usability Management 6. Risk Management 7. Measurement and Metrics 8. Document Preparation and Production The following pages would focus on the requirement traceability matrix and formal technical reviews. Managing traceability is required to ensure the requirements are carried through properly to design, development, and delivery. The following animation will show the pitfalls of poor traceability. Now, let us try to understand the concept of traceability and its importance in software development. For example, in an organization, the activities are departmentalized on the basis of the functionality to be served and employees are allocated to each department. A requirement traceability can be defined as a method for tracing each requirement from its point of origin, through each development phase and work product, to the delivered product. Thus, it helps in indicating, for each work product, the requirements this work product satisfies.
When there is absence of traceability: The product gets compromised since the development cannot be prioritized based on the order of criticality of the component, ultimately leading to missed functionality in the delivered software. Project management is compromised due to the lack of visibility of the components of the application being developed and their interconnections causing a major hindrance to continuous planning. Testing is compromised as the coverage is not verified at every stage of the life cycle. It becomes difficult to demonstrate that the product is ready. Finally, maintenance becomes difficult as identification and analysis of the impacted work products and requirements becomes tedious. This ultimately increases the complexity during testing. Some benefits are that its availability ensures correct implementation of requirements as traceability gives a clear visibility of the interactions among the components within the system. The forward and backward visibility into the system actually helps in estimating the tasks and activities of the project with greater accuracy through a detailed impact analysis for the changes. This leads to effective project management and planning. Since traceability provides a highly visual view of the interrelationships between the various components, it can be used to identify the requirements that have not been covered and hence analyze the gaps between them. Traceability gives a complete idea about the dependencies and relationships of and between components. For any change in requirement that is requested by the customer, it facilitates impact analysis and simplifies the maintenance activities. Finally, traceability also helps to ensure that all the work is against current requirements and that the requirements are completely satisfied. (103) The roles and responsibilities with respect to the traceability matrix are explained in this page. Project manager ensures all required information is provided as needed, reviews the traceability matrix for completeness. Requirement analyst updates requirements traceability matrix as needed, support analysis as needed. Designer provides mapping of requirements to design products. Developer provides mapping of requirements to development products. Tester provides mapping of requirements to test products.
This page details the concept of Peer Review in software projects and identifies the importance and need of Peer Reviews. In software development, Peer Review refers to a type of Software Review in which a work product (any software deliverable, design, or document) is examined by its author and/or one or more colleagues of the author, in order to evaluate its technical content and quality. Management representatives should not be involved in conducting a peer review except when included because of specific technical expertise, or when the work product under review is a management-level document. Managers participating in a peer review should not be line managers of any other participants in the review. (106) Peer Review has to be planned at the start of the project where the PM or PL identifies the artifacts to be reviewed and the Peer Reviewers. The Review schedule of the individual items to be reviewed along with associated reviewer needs to be planned by the PL during the project execution. The Peer Review needs to be conducted by the assigned Reviewers. The Review comments need to be logged in a Review tool such as eTracker or Prolite. The developer needs to incorporate the review comments.
In this session, you have learned that: Umbrella activities span all the stages of the SDLC The concept of umbrella activities focuses on Requirement Traceability Matrix Requirement traceability matrix is needed to be maintained by projects to ensure that the requirements are adequately addressed Not maintaining a requirement traceability matrix results in problems including unsatisfied requirements, problems during delivery and maintenance Software Peer Review needs to be planned, performed, and logged.
===================================================================== === LESSON 10: CONFIGURATION MANAGEMENT Here, we are presenting the scenario on the day version 3.0 of Far Flung Personnel Planner to be released. We see here that the current problem that the far flung company was facing could be reverted if they could roll back to the earlier release. They are unable to identify the changes incorporated in the previous version and check whether all the changes suggested have been incorporated in the latest version. There is no formal communication about the status of the changes either. (109) At the end of this session, you will be able to: Learn what software configuration management is Study the important terminologies used in software configuration management Explain the tasks involved in software configuration management FIRST LAW OF SYSTEM ENGINEERING: Change management is a life cycle activity, not just a maintenance activity. Change is inevitable and it can occur at any stage of software development. Here, we will illustrate a few basic reasons why we encounter change in software application development. If the business need is not clear to the customers, then the way it is communicated often doesn't address the actual need which, at a later point of time, might result in a change. Secondly, if there is a change in the operating environment in which the system functions. Thirdly, a change might result from the errors committed due to other reasons during requirement gathering, design, and the testing phase of the life cycle. Since you now know the fact that change is inevitable in software application development, the next basic question that arises is how are we going to manage these changes? To manage changes in software application development, we use the discipline of software configuration management, which operates throughout the life cycle of an application development. Here is an illustration of configuration management. Configuration management is a discipline that involves a set of activities that need to be performed to manage and control the changes that arise during the software development life cycle. The discipline of configuration management is applied across the life cycle of the project. SCM is that aspect of project management that focuses exclusively on systematically controlling the changes that occur during the project by using a defined process. SCM is a support activity that makes technical and managerial activities more effective with the basic objectives of delivery of high-quality software product to the client. It involves identifying and documenting the physical and functional characteristics and managing the security and protection of a software artifact.
Now, here is an illustration of the basic questions a configuration management system helps us to answer about any document or code that is created or used in software development or maintenance. Typical questions that any SCM process should address are: • • • • What are the artifacts to be developed within the life cycle? What is the status of an item? How do I identify a work product uniquely, every time I make a change and how do I record its effect on other items? How do I inform everyone else of the changes I have made to an existing document or code?
Now it is essential to get familiarized with some of the commonly used terminologies in configuration management and understand their significance in detail. Software Configurable Item or an S C I, Baseline, Version Control, and Access Control. You will learn about these terminologies in the following pages. The most important concept of software configuration management is a software configurable item or SCI. Software configurable items are the basic building blocks of any software product. Changes to the software configurable items need to be managed in order to control change of the software product. Here is an example of a house that relates to an SCI. The building plan, the floor design, the doors, windows, and chimney of the completed house can be identified to be the configurable items of a house. In case of a software application requirements document, the design document, code, test strategy document, and the delivered application itself can be considered to be examples of SCI. A baseline is a specification or product that has been formally reviewed and agreed upon. Examples of baselines are reviewed design document, approved project plans, and accepted product. Baselines are well-defined points in the evolution of a software application. Hence, the baselining criteria and the person responsible for meeting the criteria need to be defined prior to planning configuration management. (111) Using version control of a configurable item, we are able to identify multiple instances of the same configurable item, uniquely. Assume that we have completed building a house using the Base-lined project plan: House_Project_Plan_Version_1.0, and Base-lined Floor Design Document: House_Floor_Design_Version_1.0. Now, there is a need to change the pattern of windows of the house. To change the window pattern of the house, we would need to re-plan the project and recreate the floor design. The version number of the initial project plan is incremented by 1.0 and the new plan is named: House_Project_Plan_Version_2.0. The floor design is also updated and the version number of the initial floor plan is incremented by 1.0 and the new floor design is named: House_Floor_Design_Version_2.0. Based on the new baselined configurable items House_Project_Plan_Version_2.0 and House_Floor_Design_Version_2.0, an updated version of the house is created. The following page will give you details on Access control. Access control is used to maintain integrity of configurable items. Not all associates working in a software company are allowed to access the documents pertaining to a particular project. Only core members of a project are allowed to gain access to documents of a project. Again, within the project, different user groups are defined and access rights are defined for each user group.
Separate work areas are defined for each team and access is controlled within each work area. (112,113) The first task for initiating the discipline of software configuration management, referred to as SCM, is to create the configuration management plan. The next step is to form the SCM team as per the roles identified in the SCM plan. The third step is to set up a library or project repository structure as per the SCM plan. Along with this task, access rights of each team member to each repository are also defined and implemented. Changes implemented in all items are then implemented as per the methodology documented in the SCM plan. The status of items changed is maintained by the SCM coordinator. All activities of SCM are subject to configuration audits conducted by the quality reviewer.
The software configuration management plan documents the processes and methodologies that will be used to manage change in the project. It also identifies the roles of the team members who will be responsible for implementing change control in a project. (115) The SCM plan identifies the names of the SCM team and the roles of each member, that is, the names of the reviewers, approvers, SCM coordinator, and other team members who will be responsible for implementing a change. (116) Libraries or repositories are areas where a project stores and maintains the documents and executables. This page illustrates the repository structure for version controlled items. The development area contains all items documents that are in development while review or test area contains items that are ready for testing. The baseline area contains all the approved items that
are ready for project use and deliverable to the next step or stage. Old items that are no longer in use are stored in the archival area. Here you will see how user access rights are defined for each of the area or repository and how read or write access is controlled in a project. To maintain integrity of the work products, access rights to each of the folders is defined.
A software project has both version controlled and non version controlled items. All the items that will undergo changes throughout the life cycle are version controlled and called documents, such as design document, code etc., There are many other items, which reflect the status at the given point of time and that individual item will not undergo changes. Only a new instance will be created. These are typically non-version controlled and called as records. Examples are Status reports, review records.
This naming conventions of configurable items have been described here. The qualifier can be a project or a module or a sub project name or any combination of them identified as appropriate to a project.
To manage changes in a software configuration item, it is necessary to identify the multiple instances of a configurable item uniquely. We use the concept of a naming convention and a version number to identify a configurable item. After a configurable item is baselined, a version number is given to the configurable item, generally starting at 1.0. As already described earlier, a baselined configurable item is either reviewed or approved based on the criteria set for baselining the item.
Here you can see how non-configurable items like quality records are named. The example is that of a review sheet for a design document. In this case, a qualifier can be a project or a module or a sub project name or any combination of them identified as appropriate to a project.
The naming convention of other non configurable items like status reports is illustrated here. In this case, the qualifier can be a project or a module or a sub project name or any combination of them identified as appropriate to a project.
Change control is a procedural activity that ensures quality and consistency as changes are made to configurable items. Change control is the means by which changes are accepted into a project in a controlled manner without causing great instability. Manages the process for initiating and making changes to baselined software configurable items.
Status Accounting keeps track of changes made to Configurable Items and its current status by maintaining a history and a continuous status over the period of time. The status can be WIP, baselined, under review, or change etc. This helps in identifying the list of changes required, the changes incorporated, and the changes pending. (125) The quality reviewer or SCM coordinator of the project audits all activities pertaining to configuration management. There are two types of audit that a quality reviewer performs, functional configuration audit and physical configuration audit. Functional configuration audit verifies that the system satisfies the specifications and this is typically verified by auditing the traceability matrix. The traceability matrix traces each requirement through the design, code, and test case, whereas the physical configuration audit verifies the typical SCM question of the status accounting of all SCIs.
In this page, you will learn about the modes of configuration management. SCM can be either tool-based or manual or a combination of the two. Manual management essentially involves configuring a folder structure in a file server with controlled access rights for various areas. Tool-based management covers automatic version control mechanism for both source code and documents, and access control. Since the process is automatic, the chances of committing manual errors are eliminated. Examples of SCM tools are: VSS, Clearcase, CVS, etc. SCM can be performed as a combination of these two mechanisms.
Currently, VSS from Microsoft is most widely used across projects. We will learn the various features of configuration management by using VSS as the source control tool. VSS allows automatic version management eliminating the version naming conventions. Instead, it keeps a history of the previous versions of the same file through frequent check-ins or check-outs. Apart from that, the details of the check-ins and check-outs can be stored by labeling each version of
an item. The labeling can also be used for automatic build management of the software at defined intervals by improving the tool using add-ins to VSS. VSS allows multiple degrees of folder level access control mechanisms to a group or at individual level. Parallel development is also possible through the usage of branching and merging of the main chain. Here are the SCM best practices that are followed at Cognizant: 1. Addressing workflow and the responsibility for change
2. Conditions for initiating CRs (Eg- Rec Change, UI Stds Change, delay in sign-offs)
3. Highlighting and planning for controlling dependencies affecting the critical path or SLA 4. Handling signoff delays 5. Handling scope and responsibility change apart from the requirement change 6. A defined branching and merging strategy 7. Defining and enforcing the frequency of check-ins of development code 8. Addressing tagging or labeling frequency or nomenclature for the builds SCM practices and other details followed at Cognizant can be accessed from Cognizant's quality management system-the Qview. The demo will help you to reach out for necessary documentation regarding the SCM practice at Cognizant. (129) In this session, you have learned that: Software configuration management is a discipline used to manage and control change across the project software development life cycle The terminologies used in SCM are: Software Configurable Item, These are the components of a product that are to be controlled for managing change in a product. They are identified using naming conventions and version numbering Baseline, Is the formally agreed upon project plan Version Control, Identifies multiple instances of the same configurable item, uniquely Access Control, Is used to maintain integrity of configurable items
software configuration management plan documents the processes and methodologies that will be used to manage change in the project. It also identifies the roles of the team members who will be responsible for implementing change control in a project.
The SCM plan includes Names of the SCM team members, Roles of each SCM team member, Name and location of project libraries, User access right for project libraries, Names of configurable items, Names of non version controlled items, Process for change control, and Process for status accounting.
===================================================================== === LESSON 11: DEFECT MANAGEMENT “Some maladies at their beginning are easy to cure but difficult to recognize. In course of time, when they have not been at first recognized and treated, they become easy to recognize and difficult to cure” (Niccolo Machiavelli). This necessitates defect prevention and defect detection to be a part of the defect management process. This is true for software projects as much as medical science. At the end of this session, you will be able to: Study the defect-tracking mechanism and Learn about the defect prevention and causal analysis A defect can be defined as a flaw in a system or system component that causes the system or component to fail in performing its required function. A defect can be of two types: Process defect and Product defect. Prolite or eTracker needs to be used for tracking, reporting, and resolution purposes. Here, you can see the diagram of the workflow for internal defect. You will now learn what defect reporting involves. Defects are reported using Prolite, eTracker, or other defect tracking tools. A defect report must include: Defect Id, Test case reference, Defect description, Defect priority and severity, Tester name, and Test date and time. After the defect is assigned to a developer and fixed, the final report will include the Defect fixer's name, Date and time, and Defect fix verification. In the next page, you can see how defects are classified. Defects are classified in terms of severity. Severity is indicative of how severe the defect is. This can be very high or critical, high, medium, or low. Priority is an indicator of how soon the defect needs to be fixed and this can be high, medium, or low. Now, you will learn how defects can be prevented. Every project prepares a defect-prevention plan. Using the plan, the common/special causes of defects are sought, identified, prioritized and systematically eliminated. Defect-prevention tasks include: analyzing defects encountered in the past and taking specific actions to prevent the occurrence of the same in future. This diagram depicts the defect-prevention flow. The causal analysis meetings are planned in the defect-prevention plan. You will learn more about causal analysis in the next few pages.
Causal analysis primarily focuses on: fixing problems as they occur(before they happen), finding what, in the process, has permitted the defect to occur, and finding what needs to be corrected to prevent it from occurring again. The outcome of the causal analysis meeting: • • Determines the root causes and special/common causes. Proposes action plans and draws up implementation plans.
Root causes for defects may occur during: o Coding and testing stage because of lack of programming skills, insufficient adherence to standards, lack of environment knowledge, lack of testing skills, and oversight of design requirements. o Implementation due to: Lack of implementation skills, and lack of availability of the proper environment. The responsibilities involved in managing a defect begin with: Creating a team to coordinate defect-prevention activities for the organization. This team is either part of SQAG or its activities are closely coordinated with that group. Building a team to coordinate defect-prevention activities for the software project. This team is closely tied to the team responsible for developing and maintaining the projects with defined process. SEPG is such a team.
Here are the roles and responsibilities for defect management in a project: Follow defect-prevention checklist from database Adopt DP activities suggested in the kick-off meeting Collect defect data Conduct causal analysis Identify the special or common root causes for defects Identify action proposals for each root cause Identify the action proposals for preventing the special or common defects Review causal analysis and select action proposals to be addressed Implement the action items and track them to closure Review the success or failure of the past action items Entering the data in the repository Conduct phase-wise review of defect-prevention activities Some of the defect prevention (statistical) techniques commonly used are Root-cause analysis, Defect metrics analysis, and Defect prediction.(133) In this session, you have learned that: A defect can be defined as a flaw in a system or system component that causes the system or component to fail in performing its required function A defect can be of two types, namely, process defect and product defect Every project prepares a defect-prevention plan. Using the plan, the common causes of defects are identified and eliminated The causal analysis meetings are planned in the defect prevention plan. The causal analysis focus on fixing problems as they occur, finding what, in the process, has permitted the defect to occur, and finding what needs to be corrected to prevent it from occurring again The outcome of the causal analysis meeting: Determines the root causes and common causes, and proposes action plans and draws up implementation plans