Introduction to Software Engineering.

PRACTICAL-1Aim: Introduction to Software Engineering.Software Engineering: Software Engineering is an engineering discipline that consists of three key elements methods, tools and procedure that enables the manager to control the process of software development and provide the developer with a foundation for building high quality software in a productive manner .Software Engineering is an application of engineering to software system implementation, operation and maintenance, which uses systematic approach, methods, tools and procedure.Application of engineering to software system implementation, operation and maintenance .It uses systematic approach, methods, tools and procedure. Software Engineering is the study and application of engineering to the design, development and maintenance of software.The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software. An engineering discipline that is concerned with all aspects of software production .The establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machine Term Software Engineering was first introduces in the first NATO conference 1968. The term was defined as follows: The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machinesHistory: The first commercial software was built as early as 1951, in England. The company behind the software was J. Lyons Company. In the early days software building was straightforward and uncontrolled. Still, even at 50s software could be relatively versatile.When the first digital computers appeared in the early 1940s, the instructions to make them operate were wired into the machine. Practitioners quickly realized that this design was not flexible and came up with the "stored program architecture" or von Neumann architecture. Thus the division between "hardware" and "software" began with abstraction being used to deal with the complexity of computing.When the first digital computers appeared in the early 1940s, the instructions to make them operate were wired into the machine. Practitioners quickly realized that this design was not flexible and came up with the "stored program architecture" or von Neumann architecture. Thus the division between "hardware" and "software" began with abstraction being used to deal with the complexity of computing.In 1984, the Software Engineering Institute (SEI) was established as a federally funded research and development center headquartered on the campus of Carnegie Mellon University in Pittsburgh, Pennsylvania, United States. Watts Humphrey founded the SEI Software Process Program, aimed at understanding and managing the software engineering process. His 1989 book, Managing the Software Process, asserts that the Software Development Process can and should be controlled, measured, and improved. The Process Maturity Levels introduced would become the Capability Maturity Model Integration for Development (CMMi-DEV), which has defined how the US Government evaluates the abilities of a software development team.Features of software engineering: The definition was very modern since it is still valid. Software engineering is disciplined engineering work, offers means to build high-quality efficient software at affordable prices, and offers task allocation and tools for all.The emergence of software engineering: The task description and the requirements frequently change even during the program design phase, and continue to change even after the software system has long since been in use. The major problems encountered in development of large software systems were: correctness efficiency mastery of complexity interface specification reliability documentation maintainability project organizationPhases of software engineering:Theanalysis phasedefines therequirementsof the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details. The analysis team develops the requirement document, which talks about things and actions on things. This document should also include states, events, typical scenarios of usage, and typical scenarios of usageThe Design Phase: In the design phase the architecture is established.This phase starts with the requirement document delivered by the requirement phase and maps the requirements into architecture. The architecture defines the components, their interfaces and behaviors. The deliverable design document is the architecture. The design document describes a plan to implement the requirements. This phase represents the ``how'' phase. Details on computer programming languages and environments, machines, packages, application architecture, distributed architecture layering, memory size, platform, algorithms, data structures, global type definitions, interfaces, and many other engineering details are established. The design may include the usage of existing components.The Implementation Phase: In the implementation phase, the team builds the components either from scratch or by composition.Given the architecture document from the design phase and the requirement document from the analysis phase, the team should build exactly what has been requested, though there is still room for innovation and flexibility. For example, a component may be narrowly designed for this particular system, or the component may be made more general to satisfy a reusability guideline. The architecture document should give guidance. Sometimes, this guidance is found in the requirement document. The implementation phase deals with issues of quality, performance, baselines, libraries, and debugging. The end deliverable is the product itself.The Testing Phase: Simply stated, quality is very important. Many companies have not learned that quality is important and deliver more claimed functionality but at a lower quality level.It is much easier to explain to a customer why there is a missing feature than to explain to a customer why the product lacks quality. A customer satisfied with the quality of a product will remain loyal and wait for new functionality in the next version The testing technique is from the perspective of the system provider. Because it is nearly impossible to duplicate every possible customer's environment and because systems are released with yet-to-be-discovered errors, the customer plays an important, though reluctant, role in testing.Introduction to SDLC: SDLC stands for Software development life cycle. It is a process that describes how to develop, design and maintain the software project ensuring that all the functional & user requirement, goals and objective are met. This methodology improves the quality of the software project and over all process of software development.

The figure shows various stages of typical SDLC

Different Stages Of SDLC: Requirement Gathering & Analysis phase: - 1st and important phase of SDLC for the success of software. This phase includes communication between project stakeholders, end users and project team, as requirements (both Functional & non functional) are being gathered from clients. This phase of SDLC includes:-Functionally and financially feasibility analysis. Identify and capture requirements from stakeholder through client interviews, surveys etcClearly defining and documenting requirements in SRS (software requirement specification document) which consist of all the product requirements to be developed.Creating prototypes of project, to show end user that how will project look like. Performed with the help of tools like Azure etc.Design Phase:- In design phase of SDLC, based on requirement captured in SRS, architecture design is proposed for project and captured in design document. This phase of SDLC includes:-Partition of requirements into hardware & software system.Designing system architectureCreating UML diagrams (Use cases, class diagram, sequence diagrams and Activity diagram)Developments Phase: - This is the longest phase of SDLC as in this phase of SDLC actual project is developed and build. This phase of SDLC includes:-Actual code gets written.Demonstration of work accomplished to Business analyst for future modification as per requirement.Unit testing is performed i.e. verification of code as per requirements.Testing phase: The testing strategy is involved in almost all stages of SDLC. However this phase of SDLC refers to the only testing of system where bugs/defect of the system are reported, tracked and fixed. The system/project is migrated to a test environment and different type of testing is performed like functional, integration, system and acceptance. This is performed until the project reaches the quality standards as specified in SRS. This phase of SDLC includes:-System is tested as a wholeDifferent type of testing to report & fix bugs.Deploy & Maintenance phase: - In this phase of SDLC, once the system is tested, it is ready to go live. The system may be first released for limited user, and tested in real business environment for UAT (user acceptance testing).This phase of SDLC includes:-System is ready to be delivered.System is installed and put into use..Correction of errors that were not caught before.

PRACTICAL-2

Aim: Introduction to Project and the feasibility study.Introduction: In todays life software is become an integral part in almost all the applications involving computer-based systems. This is the software project .In this project, we have to create a website. Name of this website is Railway Reservation system .This website is basically designed for providing online information regarding the Trains. In this project some basic functions have to fulfill recommended by Administrator. Such functions include information regarding the Trains, online registration or reservation of seat, time schedules, and all relevant information available there, feedback information etc. provided on website.

Project planning objectiveThe objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost and schedule .These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progressesScope: The first activity on software project planning is the determine of software scope. Function and performance allocated to software during system engineering should be assessed to establish a project scope that is unambiguous and understandable at the management and technical levels.Following information is collected during estimating scope of this project: This software project that is website of tutorial RRS is requested by Admin of this website. The developed project is used by many visitors who want to get information regarding trains. This project should be web-based project. According to requirement, required changes should be possible to made.

Feasibility study: Once scope has been identified, it is reasonable to identify feasibility of the project .Feasibility study acquires the information of economic, technical or operation requirements of project. Putnam and Myers address this issue when they write:Not everything imaginable is feasible ,not even in software, evanescent as it may appear to outsiders.On the contrary software feasibility has four dimensions:Technology-is a project technically feasible? -is it within the state of the art?Finance-is it financially feasible? -can development be completed at a cost the software organization ,its client, or the market?Resources-Does the organization has the resources needed to succeed?

Information gathered during feasibility study: Project is economically feasible as all cost estimation techniques are applied to guessing the cost on project and customer is satisfied by it. This software project needs software that is available in market easily. Systems required, hardware required etc., everything is possible as required by customer. This project is operationally possible to develop.Resources: The development environment-hardware and software tolls-sits at the foundation of the resources pyramid and provides the infrastructure to support the development effort.At a higher level we encounter reusable software components-software building blocks that can dramatically reduce development costs and accelerate delivery.1. Human Resources: The planner begins by evaluating scope and selecting the skills required to complete development. Both organization position(eg. manager, senior software engineer)and specialty(eg. Telecommunications, database, client/server) are specified .For relatively small projects a single individual may perform all software engineering tasks. As this is very small project so in this project two persons are efficient for developing project and one for collecting information.Reusable Resources: Component based software engineering emphasizes reusability that is the creation and reuse of software building blocks. In this projects all modules are created by the developer, some interacting media or images are downloaded from internet.

Figure 1: Resources PyramidTOOLS/TECHNOLOGIES: The project "Railway Reservation System" has been prepared by using the following versions of software and hardware. Hence to use and modify the package at any other installation the hardware and software requirements would be follows: Minimum Software Requirement: The software requirements of project to develop are Any Windows OS such as xp,7etc.. Application software to code website such as Notpad application ,PHP environment Any Browser such as Internet Explorer, Firefox etc. Database system such as MS Access, MYSQL.Minimum Hardware Requirement: Hardware requirements used to develop this project are given below .Here those requirements are mentioned that are under use by developer. These are basic requirements. But as website is web based so this website can be visit from any environment where internet possible. The hardware requirement of project to be develop are: Processor i3 Minimum 2 Gb RAM Hard Disk Space ( 200Gb ) Keyboard

PRACTICAL-3Aim: To study the system requirement analysis and specification phase of project development and develop SRS.Requirement analysis:A requirement analysis is the principle affected process in a feedbacks system that produces description of the behavior and non-behavior feature of the system. It is the term used to describe all tasks that go into the instigation, scooping and definition of a new or altered computer system.Elements of Requirement: Physical Environment: Means the target environment in which a system should have to operate. User: User means who will use the system. Functionality: Functionality means what the proposed system will do and several modes of operation. Documentation: Documentation means how much documentation is required for the proposed system. Security: Security includes the different security issues of the proposed system.

In this phase following information is gathered: As this project is web based software project. It runs on internet at any machine as computer, mobile devices etc. Users of this project will be those who want to travel in train and may be any web site visitor. Functionality of project will be described in SRS development. Documentation is done with each phase completion. Security is maintained by using different security mechanisms.Software Requirement SpecificationA SRS is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all the interaction the users will have the software.Important parts of SRS: Functional Requirements: This part discusses the functionalities required from the system. This software project is considered to perform a set of high level functionalities.

i1o1Fi

i2o2i3o3

inon

Figure 1: View of system performing a set of functions

Basic Functionalities of project:1. You have to register yourself and then Enter the PNR for your booking to get the current status. You will find it on the top left corner of the ticket. This information will be stored on database of system. 2. Second function is to provide information regarding the timing schedules of train between important stations. This information will be updated timely when changes have to be done. 3. Seat availability information is also available through this website.4. Fare enquiry can be done.

Non-Functional Requirements:- Non-functional requirements deal with the characteristics of the system which cannot be expressed as functions such as the maintainability of the system, portability of the system, usability of the system, etc.Basic functionalities of project:1. Accuracy of results: This project will be able to provide full accuracy. Each link of web pages will be efficiently coded. There may be some issues of overload on server if it leads to slow speed of page loading. 2. Human-computer interface: This website will provide simple interaction between the website and visitor.3. Constraints on the system: Each user visit will be catched by inbuilt implementation as anyone visit website any time. It will be the wish of maintainer to upload comments or feedback given by visitor.Goals of implementation: In this, future requirements of project such as updation needed and other facts completely possible to implement.

PRACTICAL-4Aim:-Introduction to System Design.Software design is both a process and a model. The design process is a sequence of steps that enable the designer to describe all aspects of the software to be built. It is important to note however, that the design process is not simply a cookbook. Creative skill, past experience, a sense of what makes good software and an overall commitment to quality are critical success factors for a competent design. The design model is the equivalent of an architects plans for a house. It begins by representing the totality of the thing to be built (e.g., a three-dimensional rendering of the house) and slowly renes the thing to provide guidance for constructing each detail (e.g., the plumbing layout). Similarly, the design model that is created for soft- ware provides a variety of different views of the computer software. Basic design principles enable the software engineer to navigate the design process. During the design phase the design document is produced, based on the customer requirements as documented in SRS document. Design ConceptsThe design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are:Abstraction:- Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.Refinement:- It is the process of elaboration. A hierarchy is developed by decomposing macroscopic statement of function in a step-wise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts.Modularity:- Software architecture is divided into components called modules.Software Architecture:- It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Good software architecture will yield a good return on investment with respect to the desired outcome of the project, e.g. in terms of performance, quality, schedule and cost.Control Hierarchy:- A program structure that represents the organization of a program component and implies a hierarchy of control.Structural Partitioning:- The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure.Data Structure:- It is a representation of the logical relationship among individual elements of data.Software Procedure:- It focuses on the processing of each module individually.Structure Analysis:During Structure analysis, the major processing tasks of system are analyzed, and the data flow among these processing tasks is represented graphically. During Structure analysis, the SRS document is transformed into a DFD model.The structure analysis technique is based on the following underlying principles: Top-down decomposition approach. Application of divide and conquer principle. Graphical representation of analysis result using Data Flow Diagram.Data Flow Diagram:Data Flow Diagram (DFD) is graphical representation of flow of data/info. It is used to show how data is moved between different processes. Data flow diagrams (also called data flow graphs) are commonly used during problem analysis. Data flow diagrams (DFDs) are quite general and are not limited to problem analysis for software requirements specification. They were in use long before the software engineering discipline began. DFDs are very useful in understanding a system and can be effectively used during analysis.Primitive symbols used for constructing DFDs: Function symbol: A function is represented using a circle. This symbol is called process or a bubble.

Process External entity symbol: It is represented by a rectangle.

External entity Data flow symbol: A directed arc is used as data flow symbol. Data store symbol: It is represented using parallel lines. Output symbol: It is used when hard copy is produced.Developing a DFD model of a system:To develop the data flow model of a system, first the most abstract representation of the problem is to be worked out. Subsequently, the lower level DFDs are developed.Context Diagram: The Context level DFD is most abstract data flow of a system. It represents the entire system as a single bubble. It is often referred to as Level 0 DFD, it is a data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system; strictly there is however some distinction.Context Diagram in software engineering and systems engineering is a diagram that represents the actors outside a system that could interact with that system. This diagram is the highest level view of a system. It is similar to a Block diagram.The context diagram of our project Railway reservation system shows that how the data flow is managed by the clerk of the railway and how passengers get all information about trains and their fare.

Level 1 DFD: The level 1 DFD usually contains between 3 to 7 bubbles. That is, the system is represented as performing 3 to 7 functions. To develop the level 1 DFD, examine the high-level functional requirements in the SRS document. If there are between 3 to 7 high-level functions then each of these can be directly represented as a bubble in the level 1 DFD. If there are more than 7 bubbles, then some of them have to be combined. If there are less than 3 bubbles, then some of these have to be split.In our website Railway reservation system, there are 3 high-level functions which define the DFD level 1 represented as bubble. The 3 functions are process of verification seats, preparing reports, cost and issuing tickets. The data is flowed among these three functions as they perform different functions.

The function process of verification seat checks the passenger status and verifies their seats and then stores the processed data into reservation file. The preparing report function prepares the reservation chart and it is processed by the conductor of the railway. The function cost and issue ticket, issues the ticket to passengers and maintain the cost. PRACTICAL-5Aim: Introduction to UML and its Diagrams. UML:TheUnified Modeling Language(UML) is a general-purposemodeling languagein the field ofsoftware engineering. The basic level provides a set of graphic notation techniques to createvisual modelsofobject-oriented software-intensive systems. Higher levels cover process-oriented views of a system. UML was accepted by the Industrial Organization for Standardization (ISO) as a standard for modeling software-intensive systems. It can be used with all processes, throughout thesoftware development life cycle, and across different implementation technologies.[2]The Unified Modeling Language (UML) offers a standard way to visualize a system's architectural blueprints, including elements such as: activities actors business processes databaseschemas (logical)components programming languagestatements reusablesoftware components.Uml Diagrams:Class Diagram: The class diagram is the main building block ofobject orientedmodeling. It is used both for generalconceptual modelingof the systematic of the application, and for detailed modeling translating the models intoprogramming code. Class diagrams can also be used fordata modeling.The classes in a class diagram represent both the main objects, interactions in the application and the classes to be programmed.In the diagram, classes are represented with boxes which contain three parts: The top part contains the name of the class. It is printed in Bold, centered and the first letter capitalized. The middle part contains the attributes of the class. They are left aligned and the first letter is lower case. The bottom part gives the methods or operations the class can take or undertake. They are also left aligned and the first letter is lower case.In the design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modeling, the classes of the conceptual design are often split into a number of subclasses.

Class Diagram

Use case: A Use Case is typically defined with text which describes the scenario. You can enter the text in theDescriptionfield within the Use Case definition. You can also choose to describe the scenario in terms of its steps, using theUse Case Stepsfield within the Use Case definition. Other properties are provided as a default for defining a Use Case, such as pre- and post-conditions.

Use caseActivity Diagram: Activity diagramsare graphical representations ofworkflowsof stepwise activities and actionwith support for choice, iteration and concurrency. In theUnified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows).Activity diagrams show the overall flow of control.Activity diagrams are constructed from a limited number of shapes, connected with arrows.The most important shape types: rounded rectanglesrepresentations; diamondsrepresentdecisions; barsrepresent the start (split) or end (join) of concurrent activities; ablack circlerepresents the start (initial state) of the workflow; anencircled black circle represents the end (final state).

Activity DiagramSequence Diagram: Asequence diagramis an interaction diagramthat shows how processes operate with one another and in what order. It is a construct of aMessage Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes calledevent diagrams,event scenarios. A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner

Sequence DiagramCollaboration Diagram: The UML Collaboration diagram is used to model how objects involved in a scenario interact, with each object instantiating a particular class in the system. Objects are connected by links, each link representing an instance of an association between the respective classes involved. The link shows messages sent between the objects, and the type of message passed (synchronous, asynchronous, simple, balking, and timeout). Collaboration diagrams offer a better view of a scenario than a Sequence diagram when the modeler is trying to understand all of the effects on a given object and are therefore good for procedural design.Objects: Objects are depicted on a Collaboration diagram as rectangles. The object name is provided first, with the class name to the right; the two names are separated by a colon. You may specify the multiple occurrence of an object by opening its definition dialog, selecting itsSymboltab, and toggling on themultiplechoices. You may also select theMultiple Objecttool from the toolbar.Links: Messages passed between objects are specified within theLinkdrawn between objects.

Collaboration Diagram

PRACTICAL-6Aim: Introduction to Coding and Unit testing.Coding: Coding is undertaken once design phase is complete and the design documents have been successfully reviewed. The input to the coding phase is the design document produced at the end of design phase. The objective of the coding phase is to transform the design of a system into code in a high-level language, and then to unit test this code.Coding conventions are only applicable to the human maintainers andpeer reviewersof a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced bycompilers. As a result, not following some or all of the rules has no impact on the executable programs created from the source code.Characteristics of coding: Simplicity Readability Good documentation Transportability

NAMING CONVENTIONS Names of variables in mixed case, beginning with lowercase. Function names and type names (classes, structs, enum, and typedef) in mixed case, beginning with Uppercase. Names of #defines, constants, and enum values in all uppercase, separated with underscores. Global variables start with g. Class member variables start with m.Avoid having too many parameters in functions: Functions that take too many parameters often indicate poor code design and poor usage of data structures. If classes are used properly, then there is no need to pass many parameters to member functions. Think of a class as a storage place that stores data between function calls. In this way, its member functions should be able to find inside the class most of the data they need. Too many parameters may also indicate limited/poor usage of data structures.Never use goto: This rule has been established long ago, when the structured programming paradigm replaced the Spaghetti code style that was prominent in old programs. However, even today there are programmers that still use it. It is extremely rare that using goto improves code readability; therefore, its use should be completely avoided. Code reviewis systematic examination (often known aspeer review) of computersource code. It is intended to find and fixmistakesoverlooked in theinitial development phase, improving both the overallquality of software and the developers' skills. Reviews are done in various forms such aspair programming, informal walkthroughs, and formalinspections.Unit testing:Incomputer programming,unit testingis a method by which individual units ofsource code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use.Intuitively, one can view a unit as the smallest testable part of an application. Inprocedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. Inobject-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method. Unit tests are short code fragmentscreated by programmers or occasionally bywhite box testersduring the development process.Ideally, eachtest caseis independent from the others. Substitutes such asmethod stubs,mock objects,fakes, andtest harnessescan be used to assist testing a module in isolation. Unit tests are typically written and run bysoftware developersto ensure that code meets its design and behaves as intended.

OBJECTIVES OF SOFTWARE TESTINGThe software testing is usually performed for the following objectives:-SOFTWARE QUALITY IMPROVEMENT:- The computer and the software are mainly used for complex and critical applications and a bug or fault in software causes severe losses. So a great consideration is required for checking for quality of software.VERIFICATION AND VALIDATION:-Verification means to test that we are building the product in right way .i.e. are we using the correct procedure for the development of software so that it can meet the user requirements.Validation means to check whether we are building the right product or not.SOFTWARE RELIABILTY ESTIMATION:- The objective is to discover the residual designing errors before delivery to the customer. The failure data during process

PRACTICAL-7Aim: introduction to integration and system testing.Integration Testing:Integration testing(sometimes calledintegration and testing, abbreviatedI&T) is the phase insoftware testingin which individual software modules are combined and tested as a group. It occurs afterunit testingand beforevalidation testing. Integration testing takes as its inputmodulesthat have beenunit tested, groups them in larger aggregates, applies tests defined in an integrationtest planto those aggregates, and delivers as its output the integrated system ready forsystem testing.The purpose of integration testing is to verify functional, performance and reliabilityrequirementsplaced on major design items. These "design items", i.e. assemblages (or groups of units), are exercised through their interfaces usingblack box testing, success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas andinter-process communicationis tested and individualsubsystemsare exercised through their input interface.Test casesare constructed to test whether all the components within assemblages interact correctly, for example across procedure calls or process activations, and this is done after testing individual modules, i.e. unit testing. The overall idea is a "building block" approach, in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages.Some different types of integration testing are: Big bang Top-down, and Bottom-upBig bang: In this approach, all or most of the developed modules are coupled together to forms a complete software system or major part of the system and then used for integration testing. The Big Bang method is very effective for saving time in the integration testing process. However, if the test cases and their results are not recorded properly, the entire integration process will be more complicated and may prevent the testing team from achieving the goal of integration testing.A type of Big Bang Integration testing is calledUsage Model testing. Usage Model Testing can be used in both software and hardware integration testing. The basis behind this type of integration testing is to run user-like workloads in integrated user-like environments. In doing the testing in this manner, the environment is proofed, while the individual components are proofed indirectly through their use. Usage Model testing takes an optimistic approach to testing, because it expects to have few problems with the individual components. The strategy relies heavily on the component developers to do the isolated unit testing for their product. The goal of the strategy is to avoid redoing the testing done by the developers, and instead flesh-out problems caused by the interaction of the components in the environment. For integration testing, Usage Model testing can be more efficient and provides better test coverage than traditional focused functional integration testing.Top-down and Bottom-upBottom Up Testingis an approach to integrated testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.All the bottom or low-level modules, procedures or functions are integrated and then tested. After the integration testing of lower level integrated modules, the next level of modules will be formed and can be used for integration testing. This approach is helpful only when all or most of the modules of the same development level are ready. This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage.Top Down Testingis an approach to integrated testing where the top integrated modules are tested and the branch of the module is tested step by step until the end of the related module.System testing:System testingof software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specifiedrequirements. System testing falls within the scope ofblack box testing, and as such, should require no knowledge of the inner design of the code or logic. As a rule, system testing takes, as its input, all of the "integrated" software components that have passed integrationand also the software system itself integrated with any applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together (calledassemblages) or between any of theassemblagesand the hardware. System testing is a more limited type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole.Testing as a wholeSystem testing is performed on the entire system as a context of a functional Requirement Specification and/or a System Requirement Specification (SRS). System testing tests not only the design, but also the behavior and even the believed expectations of the customer.

Types of System Testing Alpha testing Beta testing Acceptance testingAlpha testing: It is the system testing performed by the development team.Beta testing: It is the testing performed by the friendly set of customers.Acceptance testing: this is the testing performed by the customer himself after the product delivery to determine whether to accept the delivery product or to reject it.

PARCTICAL-8Aim: Introduction to Software Maintenance.Software maintenance:Insoftware engineeringis the modification of a software product after delivery to correct faults, to improve performance or other attributes. A common perception of maintenance is that it merely involves fixing defects. However, one study indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions.This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system. More recent studies put the bug-fixing proportion closer to 21%.The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding,impact analysis, testing, maintainability measurement.Software maintenance is a very broad activity that includes error correction, enhancements of capabilities, deletion of obsolete capabilities, and optimization. Because change is inevitable, mechanisms must be developed for evaluation, controlling and making modifications.So any work done to change the software after it is in operation is considered to be maintenance work. The purpose is to preserve the value of software over the time. The value can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, more efficient and employing newer technology. Maintenance may span for 20 years, whereas development may be 1-2 years.Types of Software maintenance:Corrective: Corrective software maintenance involves developing and deploying solutions to problems ("bugs") that arise during use of a software program. Computer users will notice performance problems with software, such as error messages coming on the screen or the program freezing or crashing, meaning corrective software maintenance is needed. Often these fixes permanently solve the problem, but not always. Some fixes act as a temporary solution while computer programmers work on a more permanent solution.

Perfective: No software program contains zero flaws or areas for improvement. Perfective software maintenance involves computer programmers working to improve the way a software program functions or how quickly it processes requests. Programmers may also engage in perfective software maintenance to improve the software's menu layouts and command interfaces. Sometimes programmers need to conduct perfective maintenance on software because of outside influences, such as new government regulations that affect how a business operates.

Adaptive: The field of technology constantly changes through both hardware and software developments. Adaptive software maintenance addresses these changes. A change in a processor's speed, for example, will affect how the software performs on a single computer. Software interacts with other software programs on a computer or network, meaning changes in one program can require changes in other programs. A user will eventually introduce new software to the computer or network, which can also affect how other software already present operates.Preventative: When computer programmers engage in preventative software maintenance they try to prevent problems with software programs before they occur. Programmers seek to prevent corrective maintenance as much as possible, while also anticipating adaptive maintenance needs before users experience problems. Computer programmers test software, as automotive companies test the vehicles they make, to make sure the software can handle high data loads and other stressful operations without problems. Computer programmers also test the software with other programs users likely will use on their computers, making sure compatibility issues do not arise.Purpose: A process is a meaningful and partially-ordered set of activities that is carried out to produce a valuable result.