Software Engineering 1 Software Engineering 2 Software Engineering 3

■■■■■■■■■■■■(CHAPTER-1 introduction to software Engineering)■■■■■ ■■■■■■■■■ SDLC Phases:(8M-2012)(7M-2013)(15M-2014) WATERFALL MODEL: (8M-2011)(10M-2013)(10M-2016)

SOFTWARE: (2Marks-2013)(2M-2014)  The SDLC framework consists of series of phases (or steps) that are intended to be followed in  This model is also referred as Linear Sequential Model or Classical Life Cycle Model.
sequence by software or system designers and develops.  Waterfall Model is a software life-cycle or product life-cycle model, in which development is
 Software is the collection of computer programs, procedure rules and associated documentation
 The entire software development life cycle can be classified into seven phases supposed to proceed linearly through requirements analysis, design, implementation, testing
and data.
(validation), integration and maintenance.
 Software is a set of instructions used to acquire inputs and to manipulate them to produce the
1. Feasibility study: in this phase the design and development team becomes clear with the project
desired output in terms of functions and performance as determined by the user of the
objectives and their work preview
software.
2. Requirement Analysis: In this stage, the requirements are studied and analyzed. The technical
development team works with customers and system end users to identify the application domain,
♥ SOFTWARE ENGINEERING: (2M-2011)(2M-2012)(2M-2013)(2M-2015)
functions, services performance capabilities, hardware constraints related to the system to be
 Software engineering is the systematic approach to the development, operation and maintenance
developed
of a software product.
 Software engineering is systematic development, management and evaluation of software 3. System Design: In this phase, a new system is designed according to the needs of users
systems. It is concerned with the application of engineering concepts, techniques and methods to 4. Development: This is the phase where the system is actually developed
the development of software.
5. Testing: this is most important phase under all kinds of situations and environment to test its
Goals of software Engineering: (2M-2012) performance, During this phase entire project functionally is tested

 The goal of software engineering is to create practical software systems that have social and /or 6. Implementation: This is the process in which the developed system is handed over to the client.
economic value using a systematic software development process. And all the end users are trained to manage and maintain the new systems
 To improve the efficacy and quality of software product. 7. Software Maintenance: this is the phase wherein the development team maintains the system
 The get the ability to develop and maintain software becoming more and more complex. for the client.

♥ SOFTWARE PRODUCT: (5M-2012)(5M-2013)(2M-2015)(2M-2016)

 Software products are software systems that are delivered to a customer with a documentations 1. Requirement Definition: The system‟s services established by consultation with system users.
which describes how to install and use the system. Then defined in a manner which is understandable by both users and development team.

2. System and Software Design: Software design representing the software system functions in a
There are two types of software products:
form that may be transformed into one or more executable programs.
1. Generic products
3. Implementation and Unit Testing: The system is divided in modules/ units. Each unit is
2. Bespoke (or customized ) products
developed and tested for its functionality, this is referred to as unit testing.

Generic Product Customized Product 4. Integration and system Testing: The system is first divided into units which are developed and
Generic Products are developed for anonymous The customized products are developed for tested for their functions. These units are integrated into a complete system and tested to
customers. specific customers. check if all modules/units coordinate with each other, and the system behaves as per the
For the generic products, the organization which For custom products, the specification is usually specifications. After successfully testing the software, it is delivered to the customer.
develops the software product controls the developed and controlled by the organizations
5. Operations and Maintenance: Maintenance involves correcting errors which were not discovered
software specification. who are buying the software.
in earlier stages of the life cycle, improving the implementation of system.
The target is generally the entire world and The specific product is designed and developed
many copies are expected to be sold. as per customer requirements.
Examples: operating systems, compilers, Examples: Payroll System, Inventory Systems
Advantages of the Waterfall Model:
analyzers, word processors. etc. Different types of SDLC Models:  Easy to understand and implement.
 Widely used and known (in theory).
1. Waterfall model 2. Spiral model  It allows for communication between customer and developer and specifies what will be
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC): (2M-2014)(10M-2015)
3. Prototype model 4. Iterative mode delivered when and at what cost
 SDLC describes a process used by engineers and analysts to develop and deploy all aspects of an
5. Component based software engineering 6. Incremental mode
information system. Disadvantages of the Waterfall Model:
7. Rapid application development model (RAD) 8. Evolutionary development
 SDLC is sequence of activities carried out by analyst, designer, and user to develop and  The waterfall model requires the user to define system requirements early in the project.
implement an information system. These activities are carried out in different stages.

Software Engineering 4 Software Engineering 5 Software Engineering 6

♥ SPIRAL MODEL: (8M-2011)(8M-2013)(15M-2015)(15M-2016) Disadvantage of spiral Model: ■■■■■■■■■■■■■■■■■■■(CHAPTER-2: System Engineering)■■■■■■■■■■■■■■■■■■■■■
 Spiral model is also known, as spiral life cycle model is a System Development Life Cycle (SDLC)
 Cost involved in this model is usually high System: (2M-2011)(2M-2013)
model used in Information Technology (IT) this model of development combines the features of
 Risk analysis requires highly specific expertise  A system is a collection of inter related components that work together to achieve some
prototyping model and waterfall model. The spiral model is used for large, expensive and complicated
 Doesn‟t work well for smaller projects objective
project
 It is a complicated approach especially for projects with a clear SRS. System engineering: (2M-2015)
 It is not suitable for low risk projects.  System engineering is the activity of specifying designing, implementing, validating,
Installing and maintaining systems as a whole.

SOFTWARE ENGINEERING CHALLENGES: (5M-2015)(5M-2016)

SYSTEM PROCUREMENT: (7M-2011)(2M-2014)(5M-2015)
1. The legacy challenge: The majority of software systems which are in use today were developed
many years ago yet they perform critical business functions. The legacy challenge is the  System procurement is the process of acquiring a system for an organization to meet some
challenge of maintaining and updating this software in such a way that excessive costs are identified need.
avoided and essential business services continue to be delivered.  The system may be brought as a whole, may be brought as separate parts then integrated or may
2. The heterogeneity challenge: systems are required to operate as distrusted systems across be specially designed and developed.
networks that include different types of computers and with different kinds of support systems.  There are two main reason for this
The heterogeneity challenge is the challenge of developing techniques to build dependable 1. To buy or let a contractor to design and built a system a high level specification of what that
software which is flexible enough to cope with this heterogeneity. system should do must be completed.
3. The delivery challenge: Many traditional software engineering techniques are time-consuming to 2. The specification may allow you to buy a commercial off the shelf (COTS) system. It is always
deliver quality software. However business operation today change very frequently, so supporting almost cheaper to buy a system rather than developing a system from scratch.
software must also change rapidly. Software time should be reduced without change on quality of
a software product.
4. Changing requirement: Unfortunately, requirements changes come from many sources. It is SYSTEM ENGINEERING PROCESS: (7M-2012)(10M-2013)(10M-2014)
often very hard for customers to express exactly what they want in a product. The product It is process that ensures that the customer‟s needs are satisfied throughout a system‟s entire life
domain can be constantly changing during the course of a product development cycle. cycle.
5. Schedule Optimism: Software engineers are an optimistic crew. In most organizations, it is the
software engineers who estimate how long it will take to develop a product.

1. Objective Setting: Specific objective for that phase of the project are defined. Constraints on
♥ RISK MANAGEMENT:(2M–2012)(2M-2013)(2M-2014)(5M-2015)(5M-2016)
the process and product are identified and a detailed management plan is drawn up.
 Risk management is to expect risks that might affect the project schedule or the quality of the
2. Risk Assessment and risk reduction: For each of the identified project risks, a detailed analysis software being developed and taking action to avoid these risks.
is carried out. Steps are taken to reduce the risk  Risk Management is a process that is used to minimize risk before it can harm the productivity
3. Development and validation: After risk evaluation, a development model for the system is of a software project.
chosen.  There are several types of risk that can occur during a software development project. These
include
4. Planning: The project is reviewed and a decision made whether to continue with a further loop of
the spiral. If it is decided to continue, plans are drawn up for the next phase of the project. Risk Type Description
Generic threats across all projects, For example, requirements change,
Generic Risks
Advantage of Spiral model: loss of team members, loss of funding.
High level risks associated with the type of product being developed. For The phases of the system engineering process are:
 High amount of risk analysis Product-Specific Risks
 Good for large and mission – critical projects example: Availability of testing resources.  System requirement definition.  System design process.
 Spiral Life Cycle Model is one of the most flexible SDLC models in place. Project Risks Affect project schedule of resource  Sub-system development.  System integration.
 Project monitoring is very easy and effective. Each phase and each loop requires a review from Product Risks Affect quality or performance of software  System installation.  System evolution.
concerned people. Business Risk Affect the viability of the software.  System decommissioning.  System operation.
 It is suitable for high risk projects, where business needs may be unstable.
 There are also specific risks associated with team members, customers, tools, technology, time
 A highly customized product can be developed using this
estimation and team size.

Software Engineering 7 Software Engineering 8 Software Engineering 9

(-1-) System requirement definition: (-4-) System integration: (2M-2012)(2M-2014) ■■■■■■■(CHAPTER-3 Software Requirement Analysis and Specification)■ ■■■■■■■■
 Creating system requirement definition includes consultation with system customers and end  System integration involves taking independently developed sub-systems and putting them SOFTWARE REQUIREMENT: (2M-2011)(2M-2014)
users. together to make up a complete system.
 A software requirement is description of the feature of a software product, its information flow,
 This requirements definition usually concentrates on three types of requirements.  integration can be done in two ways:
its behavior, and its attributes. Generally, a software requirement provides a blueprint for the
1) Big bang method: All the sub-system are integrated at the same time
development of a software product.
 Abstract functional requirements: The basic functions that the system must provide are 2) Incremental integration: Sub systems are integrated one at a time. Incremental integration
 It should only specify the external behavior of the system. The definition should be written in
defined at an abstract level. is the best approach for two reasons.
such a way that it is understandable by customers without knowledge of specialized notations.
 System properties: These are non-functional emergent system properties such as availability
(a) It is usually impossible to schedule the development of all the sub-systems so that they are
performance and security. These non functional system properties affect the requirement
all finished at the same time. FUNCTIONAL REQUIREMENT: (5M-2011)(2M-2015)
for all sub-system.
(b) Incremental integration reduces the cost of error location.  the functional requirements for a system describe what the system should do, these
 Characteristic that the system might not exhibit: It is sometimes as important to specify
what the system must not do as it to specify what the system should do. requirements depend on the type of software being developed, the expected user of the
(-5-) System installation:
software and the general approach taken by the organization when writing requirements
(-2-) System design process: (5M-2013) System installation is the activity of installing the system in the environment in which it is intended to  A functional requirement is Statements of services that the system should provide, how the
operate. system should react to particular inputs and how the system should behave in particular
 System design is concerned with how the system functionality is to be provided by the
components of the system. Some of the problems that can arise during system installation are: situations.
 The activities involved in this process are
 Environment assumption may be incorrect.
 May be human resistance to the introduction of new system. SOFLWARE REQUIREMENT SPECIFICATION DOCUMENT (SRS): (2M-2012)(2M-2013)
 There may be physical installation problem.
 Software requirements pacification (SRS) is a perfect detailed description of the behavior of
 Operator training has to be identified.
the system to be developed. The SRS document is a formal agreement between the developer and
(-6-) System evolution: the customer covering the functional and nonfunctional requirements of the software to be
developed
Evolution is inherently very costly for a number of reasons.  An SRS minimizes the time requirement by developers to achieve goals and also minimizes the
 Proposed changes have to be analyzed from a technical development cost.
 Because sub-systems are never independent, changes to one sub-system may affect the  It‟s a two-way insurance policy that assures that both the client and the organization understand
performance of another sub-system. the other‟s requirements.
 As systems age, their structure typically becomes corrupted by changes. So the costs of  The SRS functions as a blueprint for completing a project with as little cost growth as possible.
additional changes increase.
1. Partition requirements: Analyze the requirement and organize them into related groups.
(-7-) System decommissioning: (2M-2015)
2. Identify sub-systems: Groups of requirements are usually related to sub-systems so this
activity and requirement may be carried out together.  System decommissioning means taking the stems out of service after the end of its useful
operational lifetime
3. Assign requirement to sub-system: Assign the requirement to each identified sub-systems.
 For hardware systems this may involves recycling materials. But software systems has no physical
4. Specify sub-system functionality: The specific functions provided by each sub-system are decommissioning problems
specified. _________________________________________________________________________
5. Define sub-system interface: Define the interfaces that are provided and expected by each
SYSTEM RELIABILITY ENGINEERING: (5M-2016)
sub-system.
1. Hardware reliability: What is the probability of a hardware component failing and how long does
(-3-) Sub-system development: it take to replace/repair that component.
 The sub-system development activity involves developing each of the sub-systems identified 2. Software reliability: How software component will produce an incorrect output? Software
during system design. failure is usually distinct from hardware failure. In that software does not ware out. It can
 Generally, the development process will develop all sub-systems from scratch. continue to work even after an incorrect result has been produced.
 It is cheaper to buy existing products rather than develop special purpose components 3. Operator reliability: How the operator of a system will make an error?
 Software Engineering 10 Software Engineering 11 Software Engineering 12
Structure of SRS document:(An Outline of SRS Document): (7M-2013)(5M-2014)(10M-2015) REQUIREMENT ENGINEERING PROCESS: (8M-2011)(15M-2014) (-3-) Requirement Validation: (5M-2011)
Software specification or requirement engineering is Process of establishing the services that the
IEEE (Institute of Electrical & Electronics Engineering) suggests the following structure for Requirement validation is concerned with showing that the requirements actually define the system that
customer requires from a system and the constraint is called Requirement Engineering Process.
requirements document. the customer wants.
 The activities involved in the requirement engineering include:
Chapter Description 1. Feasibility study 3. Requirement validation 5. Requirement documents Requirement validity checks:(5M-2012)(5M-2013)
Preface: It describes its version history, including a rationale for the creation of a new version and 2. Requirement elicitation and analysis 4. Requirement management
During the equipment validation process, check should be carried out on the requirement in the
a summary of the changes made in each version.
(-1-) Feasibility Study: (2M-2012)(2M-2014)(2M-2016) requirement document. These checks includes.
1.1 Purpose– identify the purpose of this SRS and its intended audience
1.2 Scope of the System Specified – describe the origin of the need for this  The first step in the requirement engineering process is the feasibility study. For all new
Requirement
system; explain what the software product(s) will, And, if necessary, will not do; systems, the requirement engineering should start with a feasibility study Description
validity checks
describe the customer‟s goals for the proposed system.  A Feasibility study looks at the viability of an idea and identifying problems and attempts to
1- These checks aims to ensure that the system meets all functional, behavioral and
1.3 Definitions, Acronyms, and Abbreviations – Provide the definitions of all answer one main question: will the idea work and should we process with it? Validity Checks
Introduction performance requirements
terms, acronyms, and abbreviations required to properly interpret the SRS.  The purpose of feasibility study is not to solve the problem, but to determine whether the
Consistency Requirement collected must be consistent and there should not be contradictory
1.4 References to Supporting Documents problem is worth solving Checks constraints or different descriptions of the same system function.
1.5 Overview of rest of SRS– describe the rest of the SRS and how it is  Feasibility study should make a recommendation about whether or not the system development Using knowledge of existing technology the requirement should be checked to
organized. should continue. Realism Checks
ensure that they can actually be implemented
2.1 Product Perspective – describe the relationship of software to its environment  The feasibility study report affects and changes the overall objective of the organization. At the completion of the system, it must be possible to demonstrate that the
2.2 Product Functions- provide a summary of all functions of the software Verifiability
♥ (-2-) Requirement Elicitation & Analysis:(3M-2012)(8M-2013)(10M-2014)(8M-2015)(5M-2016) delivery system meets all the requirement.
2.3 User Characteristics– provide general characteristics of eventual users
2-General
2.4 General Constraints– provide a general description of any other items that will  After an initial feasibility study, the next stage of the requirements engineering process is
Description
limit the developer‟s options for designing the system. requirements elicitation and analysis. In this activity, software engineers work with customers Requirement Validation Techniques: (5M-2014)(9M-2016)
2.5 Assumptions and Dependencies– List and describe each of the factors that and system end-users to find out about the application domain, what services the system should A number of requirement validation techniques can be used
affect the requirements the SRS. provide, the required performance of the system, hardware constraints, and so on. 1) Requirement Review:
3-Functional Functional requirement is a statement of services that the system should provide  The activities involved in requirement elicitation and analysis include The requirements are analyzed systematically by a team of reviews. It is a manual process that involves
Requirement .Each requirement is something that the system SHALL do.
people from both client and contractor organization
4-Non- Non-functional requirement is a statement of how system must behave. Non-
2) Prototyping:
functional functional requirements specify all the remaining requirements that is not covered
In this approach an executable model of the system is demonstrated to end – users and customers. They
Requirement by functional requirements
can experiment with this model to see if it meets their real needs.
This section presents a high-level overview of the system architecture using a class
5-System 3) Test Case Generation:
diagram. It shows the fundamental objects/ classes that must be modeled with the
Architecture The requirements engineers may need to generate specific test case to identify certain errors which
system to satisfy its requirements.
This section presents the use case diagram for the system under development. The other validation techniques may not detect.
6-System
use case diagram should be a complete version containing all the use cases needed to
Model
describe the functionality to be developed. (-4-) REQUIREMENT MANAGEMENT:
7.1 Appendix A. Data dictionary:  Requirements management involves establishing and maintaining agreement between customer and
 Completely defined entries for all of the actors and use cases in the use case developer on both technical and non-technical requirements.
diagram.
 Completely defined entries for all of the attributes in the class diagram. 1. Requirements discovery: This is the process of interacting with stakeholders of the system to Requirement management skills:
7.2 Appendix B. Raw use case point Analysis: discover their requirements. Domain requirements from stakeholders and documentation are also  Planning the requirements phase.  Establishing the requirements process.
This appendix contains the actor summary table and use case summary table for the discovered during this activity.  Tracking progress.  Controlling requirements changes.
7- raw use case point analysis for use case diagram.
2. Requirements classification and organization: This activity takes the unstructured collection of  Minimizing the addition of new requirements.  Resolving issues with customers and developers.
Appendices 7.3 Appendix C. Screens and reports with navigation matrix:
requirements, groups related requirements, and organizes them into coherent clusters.  Holding requirements reviews.
This appendix contains the screens and reports with their navigation matrix for each
3. Requirements prioritization and negotiation: This activity is concerned with prioritizing
use case in the use case diagram.  Requirement Management is the process of understanding and controlling changes to system
7.4 Appendix D. Scenario analysis tables: requirements and finding and resolving requirements conflicts through negotiation. Usually,
requirements.
This appendix contains the scenario analysis table for each use case in the use case stakeholders have to meet to resolve differences and agree on compromise requirements.
 Establishing a formal process for making change and linking this to system requirement.
diagram. The template for scenario analysis table is provided. 4. Requirement specification: The requirements are documented and input into the next round of
 The process of requirement management should start as soon as a draft version of the
7.5 Appendix E. Screens/reports list the spiral. The process cycle starts with requirements discovery and ends with the requirements
requirement document is available.
documentation. The cycle ends when the requirement document is complete.

Software Engineering 13 Software Engineering 14 Software Engineering 15

Data-flow Models: (5M-2012)(2M-2014) ■■■■■■■■■■■■■■■■■■■(CHAPTER-4 Software Prototyping)■■■■■■■■■■■■■■■■■■■ Disadvantages of the Prototyping Model:

 Data flow models shows how data is processed through a sequence as it moves through the SOFTWARE PROTOTYPING:  Leads to implementing and then repairing way of building systems.
system. Data Flow Diagrams (DFDs) may be used to model the system‟s data processing.  Practically, this methodology may increase the complexity of the system
 Prototyping is important technique to reduce the cost and risk in developing complex software
 Data Flow Diagram (DFD) is a representation of a system functions. Data flow diagrams (also  Too much involvement of client is not always preferred by the developer
system  Too many changes can disturb the rhythm of the development team.
called data flow graphs) are commonly used during problem analysis.
 Prototyping is a technique for providing a reduced functionality or a limited performance version
 Data flow diagram is graphical representation of flow of data in an information system.  Sometimes leads to incomplete documentation.
of software system early in its development
 Types of DFD: Data Flow Diagrams are either Logical or Physical. ♥ PROTOTYPING MODEL: (2M-2012)(2M-2013)(2M-2014)(5M-2015)
 ♥ TYPES OF PROTOTYPING Approach: (7M-2011)(8M-2012)(5M-2013)(5M-2014)
 Logical DFD – This type of DFD concentrates on the system process and flow of data in the Prototyping begins with requirements gathering. Developer and customers meet and define the
system. For example in a Banking Software system, how data is moved between different overall objectives of the software.
entities.  This model an attempt to increase the flexibility of the development process by allowing the 1) Evolutionary Prototyping: (6M-2016)
 Physical DFD – This type of DFD shows how the data flow is actually implemented in the client to interact with a working representation of the product  Evolutionary Prototyping is a life cycle model in which the system is developed in increments and
system. It is more specific and close to the implementation.  The Prototyping Model is a Systems Development Method (SDM) in which a Prototype is built, frequently modified and add new features as per to end-user and customer feedback.
tested, and then reworked as necessary unit  The evolutionary approach aims to develop a system through a series of prototype iterations.
Symbol Functions  By using prototyping, the client can get better understand the requirements of the system
Entities - Entities are source and destination of information data.
Entities are represented by a rectangle with their respective name.

Process - Activities and action taken on the data are represented by

Circle or Round-edged rectangles

Data Storage- There are two variants of data storage it can be

either be represented as a rectangle with absence of both smaller
sides or as an open-side rectangle with only one side missing
 The users thoroughly evaluate the first prototype, what needs to be added, and what should to
Data Flow – Movement of data is shown by pointed arrows. Data  The client and end-users can become closely involved the development, playing a key role as each
be removed. The developer collects and analyzes the remarks from the users. iteration moves further from prototype and closer to a usable solution that does what it is
movement is shown from the base of arrow as its source towards head
of the arrow as destination.  The first prototype is modified, based on the comments supplied by the users, and a second needed to do, and does it well.
prototype of the new system is constructed.  Must be used for systems where the specification cannot be developed in advance.
 The second prototype is evaluated in the same manner as was the first prototype.  Based on techniques which allow rapid system iterations.
 The previous steps are repeated as many times as necessary, until the users are satisfied that  The system is developed as a series of increments that are delivered to the customer.
Advantages of Data Flow Models Example
the prototype represents the final prototype.  Techniques for rapid system development are used such as CASE tools and 4GLs.
 A simple graphical technique which is easy to
 The final system is constructed, based on the final product desired.  User interfaces are usually developed using a GUI development toolkit.
understand.
 It is useful for communicating current system  The final system is thoroughly evaluated and tested.
knowledge to the users.
Disadvantage: Evolutionary prototyping
Advantages of the Prototyping Model:
 It is used as the part of system documentation file.  Existing management processes assume a waterfall model of development
 It explains the logic behind the data flow within the  Users are actively involved in the development  Specialist skills are required which may not be available in all development teams
system.  The user get better understanding of the system being developed  Continual change tends to corrupt system structure so long-team maintenance is expensive
 Errors can be detected much earlier  Contractual problems
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified
 Results in higher user satisfaction

Software Engineering 16 Software Engineering 17 Software Engineering 18

2) Throw-Away Prototyping: ■■■■■■■■■■■■■■■■■■■■(CHAPTER-5 Software Design)■■■■■■■■■■■■■■■■■■■■■ ♥ DESIGN PRINCIPLES:(5M-2011)(8M-2013)(5M-2014)(5M-2015)
 Software design is both a process and a model. The design process is a sequence of steps that
 Throw-away prototypes are useful way of exploring ideas, and gaining feedback from the client DESIGN PROCESS: (8M-2011)(5M-2014) enable the designer to describe all aspects of the software to be built.
and end-user
 The design process is a sequence of steps that enable the designer to describe all aspects of the  Design principles enable the software engineer to navigate the design process. Following are some
 The speed at throw-away prototypes can be generated and modified
software to be built. of the design principles
 They also provide a useful way for a developer to walk the client and/or end-user through the
 Problem partitioning  Abstraction
system requirements as interpreted by the developer, Feedback from the client and/or end-user
 Modularity  Top-Down or Bottom-Up
should aid in allowing be picking up and addressing at an early stage.
 The speed of development and to catch missing feature at an early stage can help to make the 1-) PROBLEM PARTITIONING:
throw-away prototype a cost effective approach.  Complex problems can be divided into small sub-program. Each program can be handled
 Used to reduce requirement risk independently. Problem partitioning is a method of adopting the principle of divide to get the
 The throw-away prototype should NOT be considered as a final system. solution to the problem
 Some system characteristics may have been left out.
 There is no specification for long-term maintenance.
 The system will be poorly structured and difficult to maintain.

Differences between Evolutionary and Throw-Away Prototyping:

Evolutionary Prototyping Throw-Away Prototyping

 The diagram suggests that the stages of the design process are sequential. In fact design
Evolutionary Prototyping is a life cycle model A prototype which is usually a practical
process activities proceed in parallel.
in which the system is developed in implementation of the system is produced to help
increments and frequently modified and add discover requirements problems and then  These design activities include:
new features as per to end-user and customer discarded. The system is then developed using
 Architectural Design: The sub-systems making up the system and their relationships are
feedback some other development process
identified and documented.
The objective of evolutionary prototyping is The objective of throw-away prototyping is to 2-) ABSTRACTION
to deliver a working system to end-users. The derive the system requirements. The prototyping
 Abstract Specification: For each sub-system, an abstract specification of the services and the  Abstraction is the method of describing a program function. High level of abstraction states the
development starts with those requirements process starts with those requirements which are
which are best understood. poorly understood. constraints under which it much operate is produced. solution of the problem. Low level abstraction deals with procedural details.
Must be used for systems where the Must be used to reduce requirements risk  Different levels of abstraction:
specification cannot be developed in advance  Interface Design: For each sub-system, its interface with other sub-systems is designed and 1. Data Abstraction: It refers to collection of data describes data types, objects, operations on
Evolutionary Prototypes are built from basic Throwaway prototyping is developed from an documented. objects
requirements gathered from end-users. The outline of a specification; a various prototypes are  interface design focus on 3 important areas: 2. Procedural Abstraction: It refers functional abstraction. It is a sequence of instructions that
prototype is modified based on the feedback delivered and modified until the client is satisfied o The design of interface between software modules. has specificity and relates to a particular function
until the client is satisfied. with its functionality. o The design of interface between software and other external modules. 3. Control Abstraction: It controls the program without specifying internal details
o The design of interface between the user and the computer.
3-) MODULARITY:
USER INTERFACE PROTOTYPING: (2M-2016)  Modularity is a logical partitioning of the software design that allows complex software to be
 Component Design: Services are allocated to different components and interfaces of these
 The user interface prototype is built early, before the whole systems is analyzed, designed and components are designed. managed for purpose of implementation and maintenance
implemented.  Modularity has five important criteria:
 The main purpose of creating a user-interface prototype is to be able to expose and test both  Data Structure Design: The data structure used in the system implementation are designed in
1. Modular Decomposition: It is a systematic method for decomposing a problem into sub-problems.
the functionality and the usability of the system before the real design and development starts. detail and specified.
2. Modular compensability: If a module can be understood as a single unit without referring to
 This way, we can ensure that we are building the right system, before we spend too much time
 Algorithm Design: The algorithm used to provide services are designed in detail and specified. other modules.
and resource on development.
3. Modular Understandability: If a module can be understood, It will be easier to build and easier
to change.
4. Modular Continuity: If there is any small change to the system requirements is applied, it results
in changes to individual module.
5. Modular Protection: If a condition occurs within a module and its effects that module, it will be
minimum, thus module can be protected.
 Software Engineering 19 Software Engineering 20 Software Engineering 21
4) TOP-DOWN and BOTTOM-UP STRATEGIES: (b) Loose Coupling: Loosely Coupled systems are made up of components which are independent or ■■■■■■■(CHAPTER-6 Object Oriented Design and Function Oriented Design)■■■■■■
almost independent. Loose coupling is achieved by ensuring that details of the data
 Top-down design: starts with a generalized model of system and keeps on defining the more ♥ OBJECT ORIENTED DESIGN: (5M-2011)(7M-2012)(7M-2013)(5M-2015)
representation are held within a component.
specific part of it  Object oriented design processes include designing object classes and the relationships between
 Top-down design is more suitable when the software needs to be designed from scratch these classes. These classes define the objects in the system and their interactions.
 Bottom-up Design: The bottom up design model starts with most specific and basic components  Design can be developed using objects that have been created in previous designs. This reduces
 Bottom-up design is more suitable when a system needs to be created from some existing system. design, Programming and validation costs.

DESIGN QUALITY: (8M-2012)(5M-2013)

 A good design might be a design that allows efficient code to be produced

Following are some of the design quality characteristics

1) COHESION: (2M-2014) (2M-2015) (9M-2016)

 The cohesion of a component is measure of the closeness of the relationship between its
components. A component should implement a single logical function or should implement a single
logical entity.
3) UNDERSTANDABILITY:
 Seven levels of cohesion can be identified in necessary order of strength,
 The understandability of a design is important because anyone changing the design must first
(a) Coincidental Cohesion: The part of a component are not related but simply bundled into a single
understand it. These are a number of component characteristics that affect understandability
component
including
(b) Logical Cohesion [Association]: Components that perform similar functions such as input, error  Object – oriented systems are easier to maintain as the objects are independents. Changing of an
handling and so on are put together in a single document. a) Cohesion and Coupling: Can the component be understood without reference used to other
object should not affect other system objects.
(c) Temporal Cohesion : A temporally cohesive module is one whose elements are functions that are component?
related in time b) Naming: Are the names used in the components meaningful? THE CHARACTERISTICS OF AN OBJECT ORIENTED DESIGN (OOD):
(d) Communicational Cohesion: All of the elements of a component operate on the same input data or c) Documentation: Is the mapping between the real-world entities and components is clear?
 Objects are abstractions of real world entries which are responsible for managing their own
produce the same output data d) Complexity: How complex are the algorithms used to implement the component?
(e) Procedural Cohesion: A procedurally cohesive module is one whose elements are involved in private state and offering services to other objects.
different activities but the activities are sequential  Objects are independent entities that may easier to change because state and representation
(f) Functional Cohesion: Each part of the component is necessary for the execution of a single 4) ADAPTABILITY: information is held within the object
function  The Adaptability of a design is a general estimate of how easy it is to change the design and  System functionality is expressed in terms of operations or services associated with each object.
component documentation should be easily understand  Shared data area is eliminated objects communication by calling on services offered by other
2) COUPLING: (2M-2011)(2M-2013)(2M-2016) ___________________________________________________________________________________________________________________________________________________________________________ objects rather than sharing variables
 Coupling is a property of a collection of modules. Coupling measures the strength of all DOMAIN SPECIFIC ARCHITECTURE:
OBJECT-ORIENTED DEVELOPMENT: (2M-2012)(2M-2016)
relationship between functional units  There are two types of domain specific architectural model, they are:
 There are two types of coupling (1) Generic Model (2) Reference Model Object oriented analysis (OOA)
 It is concerned with developing an object oriented model of the application domain. The
(a) Tight Coupling: Tight coupled systems have strong interconnections with program units
Differences between Generic and Reference Model:(2M-2012) identified objects may or may not map directly into the system objects.
dependent on each other Generic Model Reference Model
Generic model may be reused directly in Reference models are normally used to communicate Object Oriented Design (OOD)
a design. domain concepts and compare possible architecture.  It is concerned with developing an object oriented model of a software system to
Generic models are usually derived Reference models are derived from „top-down‟. implement the identified requirements
„bottom-up‟ from existing systems.
Generic models are abstract system Reference models do not necessarily reflect the Object Oriented Programming (OOP)
representation actual architecture of existing system in domain.  Object oriented programming is widely used in software Engineering now days. Object
oriented Programming provides greater flexibility, modularity and reusability.

Software Engineering 22 Software Engineering 23 Software Engineering 24

Objects, Object Classes and Inheritance:(5M-2012)(2M-2013) FUNCTION ORIENTED DESIGN: (6M-2016) Advantages of GUI:

Object: A function-oriented design strategy relies on decomposing the system into a set of interacting functions  They are easy to learn and use. Users without experience can learn to use the system.
 An object is an entity that has a state and a defined set of operations that operate on with a centralized system state shared by these functions as shown in below figure.  The user may switch quickly from one task to another and can interact with several different
that state. The state is represented as a set of object attributes. The operations applications.
associated with the object provide services to other objects (clients) that request these  Fast, full-screen interaction is possible anywhere on the screen.
services when some computation is required.

Object class: ♥ USER SYSTEM INTERACTION: (7M-2012)(7M-2013)(5M-2015)(8M-2016)

 Objects are created according to an object class definition. An object class definition is  User system interaction refers to all the ways the user can communicate or interact with the
both a type specification and a template for creating objects. It includes declarations of computer system.
all the attributes and operations that should be associated with an object of that class.  The user can interact with the system in four different styles,
 Command language.
Inheritance:  From fill-in
 It is process of acquiring properties of one object to another object. The child class  Menu selection
object acquires or inherits properties of parent class object.  Direct manipulation
 It is a reuse mechanism at both the design and programming level FUNCTION ORIENTED DESIGN PROCESS:
(-1-) Command Language (Or Command Entry)
1. Data-flow design: Model the system design using data-flow diagrams. This should show how data
 Command language is the earliest form of interaction style and is still being used mainly on
AN OBJECT – ORIENTED DESIGN PROCESS:(7M-2011)(7M-2015) passes through the system and is transformed by each system function.
Linux/Unix operating systems.
2. Structural decomposition: Model how functions are decomposed into sub-functions using
Following are essential steps required during the designing of a project using object oriented designing  These “Command prompts” are used by (usually) expert users who type in commands and know
graphical structure charts.
concepts. some parameters that will affect the way the command is executed.
3. Detailed design description: Describe the entities in the design and their interfaces. These
 Example: The command “Is-al” („Is‟ stands for „list‟ and the parameters „-al‟ specify that the list
Step -1 Analyze the project completely. This includes defining its context and various modes descriptions may be recorded in a data dictionary.
command should display a detailed list of files).
of usage of the given system
Step -2 It deals with the designing of the architecture of the system to be developed (-2-) Form fill-in:
Step – 3 Recognize the essential objects accommodating the system ■■■■■■■■■■■■■■■■■■(CHAPTER-7 User Interface Design)■■■■■■■■■■■■■■■■■■■■
Step – 4 Generate the equivalent design model  The form fill-in interaction style (also called “fill in the blanks”) is used for non-experts users.
 Interface design or user interface engineering is the design of computers, software
Step – 5 End up the task by suitable interfaces between objects  The TAB-key used to switch between the fields and ENTER to submit the form.
applications and web sites with the focus on the user‟s experience and interaction.
 Form fill-in interfaces are especially useful for routine work or for tasks that require a great
 The goal of user interface design is to make the user‟s interaction as simple and as efficient as
deal of data entry.
Example: Following is a layered architecture depicting the weather mapping system developed by possible.
following above mentioned criteria. (-3-) Menu Selection:
USER INTERFACE DESIGN: (4M-2011)(5M-2016)
Weather Mapping System:  A menu is a set of options displayed on the screen where the selection and execution of the
 System users often judge a system by its interface rather than its functionality.
options results in a state change of the interface.
Weather Mapping System is an effective system for generating weather reports. Usually the data is  The poor user interface design is the reason why many software systems are never used. Most
 Using menu-selection, the user selects a command from a predefined selection of commands
essential in generating these reports which is collected from various sources such as, users of business systems interact with these systems through Graphical user interface (GUIs)
arranged in menus and observes the effect.
♥ GUI characteristics: (2M-2011)(2M-2012)(2M-2014)(2M-2015)  To save screen space, menu items are often clustered in pull-down or pop-up menus.
 Satellite
 Local Weather Reporting Stations Characteristic Description (-4-) Direct Manipulation:
 Weather Observes etc., Windows Multiple window allow different information to be displayed simultaneously
on the user‟s screen  A direct manipulation interface presents the user with a model of their information space which
Further this information is passed to a special area computer which accepts them only after they had is modified by direct action.
Icons Icons represent different types of information. On some systems, icons
passed through validation procedures. Moreover, this entire data is integrated and backed. Later, using  GUI‟s provide some direct manipulation e.g. files can be deleted by moving icons to a Recycle Bin.
represent files; on others, icons represent processes.
suitable digital map data base, various maps are developed through a special map printer.  Users get immediate feedback on their actions so mistakes can be quickly detected and
Menus Commands are selected from a menu rather than typed in command language.
Pointing A pointing device such as a mouse is used for selecting choices from a menu corrected.
or indicating items of interest in a window
Graphics Graphical elements can be mixed with text on the same display

Software Engineering 25 Software Engineering 26 Software Engineering 27

■■■■■■■■■■■■■■■(CHAPTER-8 Reliability and Reusability)■■■■■■■■■■■■■■■■■ ♥ RELIABILITY GROWTH MODELING [RGM]: (2M-2012)(8M-2012)(2M-2013)(7M- ■■■■■■■■■■■■■■■■■■■■■■■■■■(CHAPTER-9 Testing)■■■■■■■■■■■■■■■■■■■■■■■
♥ SOFTWARE RELIABILITY METRICS: (5M-2011)(5M-2012)(8M-2013)(2M-2014)(8M- 2014)(5M-2016)
Software Testing:
2014)(5M-2015)(7M-2016)  A RGM is a mathematical model. It explains how software reliability improves as the errors are
 Software reliability metrics are units of measure for system reliability. System reliability is detected and repaired. The model can be used to predict when a particular level of reliability  Software Testing is the process of executing a program or system with the intent of finding
measured by counting the number of operational failures and relating these to demands made on can‟t be attainted. errors.
the system at the time of failure. There are six metrics for reliability which may be used for There are two types of step function model as follows:  Software testing is more than just error detection. Testing software is operating the software
both hardware and software. The metrics are: under controlled conditions to:
1. Equal step function: The model has been 2. Random step Function: This model has been
Rate of Occurrence of Failure (ROCOF)  Verification:
designed by Jelinski and Moranda. In this designed by Little wood and Verall. The model
 This is a measure of the frequency of occurrence in which unexpected behavior is likely to It is the checking or testing of items including software, for performance.
model it is assumed that the reliabilities allows for negative reliability growth to reflect
occur. For instance a ROCOF of 2/100 means 2 failures are likely to occur in each 100  Error Detection:
increases by a constant – increment each the fact that when a repair is carried out it
operational time units. Testing should intentionally attempt to make things go wrong to determine when things happen
time an error is detected and repaired. may introduce additional errors.
Example: Operating system, Transaction processing system etc. they shouldn‟t or things don‟t happen when they should.
 Validation:
Mean Time of Failure [MTTF]
Validation looks at the system corrections, i.e. is the process of checking that what has been
 MTTF is the average time between two successive failures observed over a large number of
failures. In other words, this is the measure of the time between observed systems failures. For specified is what the user actually wanted.
instance an MTTF of 500 means that one failure can be expected every 500 units of time.
Example: The systems with CAD transactions such as CAD system can be subjected to MTTF. ♥ Testing Fundamentals: (2M-2011)(2M-2012)(2M-2013)(2M-2014)(2M-2016)

Mean Time To Repair [MTTR] Mistake: it is a human action that produces an incorrect result
 Once the failure occurs, some time is required to fix the error that is nothing but mean time to
Error: an error is mistake, misunderstanding on the part of a software developer
repair. Metrics measured the average time is takes to track the error, causing the failure and
then fix it.  there are 3 types of errors:
Example: When power supply suddenly goes, the computer is off by aborting the current Syntactical error: it is deviation from the syntax of program.
operation. Since the current process is managed by operating systems. Therefore next-time Logical error: it is deviation from logic of the program.
The model explains that as the errors are repaired
when the computer is on the operating system may show the problems during loading. Such Executional error: this occurs during execution of the program.
the average improvement in reliability per repair
problems of operating system can be measured by MTTR metrics.
decreases. Failures:
Mean Time Between Failure: (MTBF)
 This metrics is the combination of MTTF and MTTR. Thus as MTBF of 300 Hours indicates that  During execution of a software component or system, a tester, developer, or user observes
PROGRAMMING FOR RELIABILITY: (2M-2011)(2M-2015)
once the failure occurs the next failure is expected to occur only after 300 hours. In this case that it does not produce the expected results.
the time measure is real time and not as indicated in MTTF. Reliability in a software system can be achieved using three strategies:  In some cases a particular type of misbehavior indicates a certain type of fault is present.
Example: An operating system after its installation in computer has caused the problem after 1  Fault avoidance: This is the most important strategy, which is applicable to all types of system.  Incorrect behavior can include producing incorrect values for output variables, an incorrect
year of its usage. It means the mean time between failure may be seen again in the next year. The design and implementation process should be organized with the objective of producing response on the part of a device, or an incorrect image on a screen.
fault-free systems.  During development failures are usually observed by testers, and faults are located and
Probability of Failure on Demand [POFOD]
 Fault tolerance: This strategy assumes that residual faults remain in the system. Facilities are repaired by developers.
 Unlike the other metrics explained above this metrics does not explicitly involved in the time
measurements. POFOD metrics measures the likelihood of the system failing when a service provided in the software to allow operation to continue when these faults cause system failures.
Faults:
request is made. For instance a POFOD of 0.001 more than one (1) out of every 1000 service  Fault detection and recovery: Faults are detected before the software is put into operation.
requests would result in a failure. The software validation process uses static and dynamic methods to discover any faults, which  A fault (defect) is introduced into the software as the result of an error.
Example: It can be understood by a simple example of copy process from a CD. If a file in a CD remain in a system after implementation.  Faults or defects are sometimes called “bugs.” Use of the term “defect” is also associated
is copied to hard disk for 10 times. It may yield a problem during any one of these attempts. with software artifacts such as requirements and design documents.
Application System Reuse: There are two types: 1) COTS Product Reuse 2) Software product lines  Defects occurring in these artifacts are also caused by errors and usually detected in the
AVAIL: (Availability)
review process.
 The availability of systems is a measure of how well the system is available for the use over a COST Product Reuse: (2M-2016)
given time. AVAIL metrics not only consider the number of failure occurring during a time. It Defect:
A commercial-off-the-shelf (COTS) Product is a software system that can be used without change by
also takes into account the repair time of the systems when the failure occurs.
its buyer. Virtually all desktop software and a wide variety of server products are COTS software.  Mismatch between the requirements. If something is happening with the functionality that is
Example: This metrics is important for the systems such as telecommunication and operating
systems which are supposed to be never down and where repair and restart time are significant Because this software is designed for general use, it usually includes many feature and functions so has not mentioned in any document to be followed during implementation or testing then it is a
and loss of that service time is important. the potential to be reused in different applications and environments. defect.
 Software Engineering 28 Software Engineering 29 Software Engineering 30
TEST PROCESS: (5M-2011)(6M-2014)(7M-2015) ♥ TEST PLAN ( TEST PLAN TEMPLATE ): (7M-2011)(8M-2012)(6M-2013)(9M-2014)(8M-2015) Test Environment:
 The test plan is the document which is created before the testing process. it includes the type  Specify the properties of test environment: hardware, software, network etc.
of testing that will be performed, high level scope of the project, the environmental  List any testing or related tools.
requirements of the testing process, what automated testing tools will be used (if available), the Estimate:
 Provide a summary of test estimates (cost or effort) and/or provide a like to the detailed
schedule of each test, when it will start and end etc.
estimation.
TEST PLAN TEMPLATE Schedule:
The format and content of a software test plan vary depending on the processes, standards, and  Provide a summary of the schedule, Specifying key test milestones, and/or provide a link to
test management tools being implemented. Nevertheless, the following format, which is based on the detailed schedule.
IEEE (Institute of Electrical & Electronics Engineering) standard for software test documentation, Staffing and Training Need:
provides a summary of what a test plan can/should contain.  Specify staffing needs by role and required skills.
 Identify training that is necessary to provide those skills, if not already acquired.
Test Plan Identifier: Responsibilities:
 Provide a unique identifier for the document. (Adhere to the configuration management  List the responsibilities of each team/role/individual.
system if we have one) Risks:
Introduction:  List the risks that have been identified.
 Provide an overview of the test plan.  Specify the mitigation plan and the contingency plan for each risk.
 Specify the goals/objective. Assumptions and Dependencies:
 The stages in testing process are:
 Specify any constraints.  List the assumptions that have been made during the preparation of this plan.
1. Unit Testing:  List the dependencies.
References:
Individual components are tested to ensure that they operate correctly. Each component is  List the related documents, with links to them if available, including the following. Approvals:
tested independently, without referring other system components. o project plan  Specify the names and roles of all persons who must approve the plan.
o configuration Management plan  Provide space for signatures and dates. (if the document is to be printed.)
2. Module Testing: Test items:
A module is a collection of dependent components such as an object class, an abstract data type  List the test item (software/products) and their versions. TVERIFICATION AND VALIDATION: (2M-2011)(2M-2013)
or some collection of procedures and functions. A module encapsulates related components so Features to be Tested:
that it can be tested without referring other system modules.  List the features of the software/product to be tested. Criteria Verification Validation
 Provide references to the Requirements and/or Design specifications of the features to be The process of evaluation work- The process of evaluating software during
3. Sub-system Testing [Integration Testing]: tested products (not the actual final product) or at the end of the development process to
 Testing collection of modules which have been integrated into sub-systems. Features Not to Be Tested: Definitionof a development phase to determine determine whether it satisfies specified
 List the features of the software/product which will not be tested. whether they meet the specified business requirement.
 The most common problems which arise in large software system are sub-system interface
 Specify the reasons these features won‟t be tested. requirements for that phase.
mismatches.
Approach: To ensure that the product is being To ensure that the product actually meets
 The sub-system test process should concentrate on the detection of interface errors.
 Mention the overall approach to testing. Objective built according to the requirements and the user's needs, and that thespecifications
4. System Testing:
 Specify the testing levels[if it‟s Master Test Plan], the testing types, and the testing design specification were correct in the first place.
The sub-systems are integrated to make-up the entire system. The testing process is concerned methods [Manual/Automated; White Box/Black Box/Gray Box] Question Are we building the product right? Are we building the right product?
with finding errors that result from unexpected interactions between sub-systems and system Item Pass/Fail Criteria: Evaluation Plans, Requirement Specs, Design Specs, The actual product/software
components.  Specify the criteria that will be used to determine whether each test item items Code, Test Cases
(software/product) has passed or failed testing. Activities -Reviews -Walkthroughs -Inspection -Testing
5. Acceptance Testing: Suspension Criteria and Resumption Requirements:
This is the final stage in the testing process before the system is accepted for operational use.  Specify criteria to be used to suspend the testing activity.
TEST CASE: (2M-2012)(2M-2015)
The system is tested with data supplied by the client rather than simulated test-data.  Specify testing activities which must be redone when testing is resumed.
Test Deliverables:  Test case is a scenario made up of a sequence of steps and conditions or variables, where test
 List test deliverables, and links to them if available, including the following: inputs are provided and the program is run using those inputs, to see how it performs. An
o Test Plan (this document itself) expected result is outlined and the actual result is compared to it.
o Test Cases
o Test Scripts Test case can be divided into three main parts:
o Defect/Enhancement Logs 1) Information 2) Activities 3) Results
o Test Reports ___________________________________________________________________________________________________________________________________________________________________________

Software Engineering 31 Software Engineering 32 Software Engineering 33

TYPES OF TESTING: (8M-2016) White Box Testing: ■■■■■■■■■■■■■■■■■■(CHAPTER-10: Software Management)■■■■■■■■■■■■■■■■■■
 White-box testing, sometimes called Glass-Box Testing or Structural Testing or Clear Box SOFTWARE QUALITY MANAGEMENT:
1. Black-box Testing 4. Beta Testing
2. While-Box Testing / Structural Testing 5. Clean Room Testing Testing. Software Quality Management activities are divided into three parts.
3. Alpha Testing 6. Defect Testing  White Box testing is used to test areas that cannot be reached from a black box testing. (-1-)♥ Quality Assurance: (2M-2011)(5M-2012)(2M-2013)(5M-2014)(2M-2015)(5M-2016)
 It requires programming skills to identify all paths through the software.  The Quality Assurance is a process for providing assurance that the software products and
Black Box Testing: (5M-2015)  Using white-box testing methods, the software engineer can derive test cases that: process in the product life cycle confirm to their specific requirements and established plans.
 Guarantee that all independent paths within a module have been exercised at least once.  The Purpose of software quality Assurance is to provide management with visibility into the
 Black Box Testing is a software testing method in which the internal structure /design/  Exercise all logical decisions on their true and false sides. process being used by the software project and of the products being built.
implementation of the item being tested is not known to the tester.  Execute all loops at their boundaries and within their operational bounds.  Software Quality assurance (SQA/QA) is the process of monitoring and improving all
 These tests can be functional or non-functional. It focuses on the functional requirements of the  Exercise internal data structures to assure their validity. activities associated with software development, from requirement gathering, design and
software.
reviews to coding, testing and implementation.
 Black box testing is also known as” Functional Testing” or “Behavioral Testing”
 Unlike testing which is mainly a detection process, Quality Assurance aims to ensure quality in
 This method is named so because the software program, in the eyes of the tester, is like a black
the methods and processes and therefore reduce the prudence of error in the software.
box; inside which one cannot see.
 Software quality assurance activities:
 Testing either functional or non-functional without reference to the internal structure of the
o Application of Technical methods [employing proper methods and tools for developing software]
component or system is called Black box Testing.
o Testing of Software
o Measurement [Software metrics to measure the quality, Quantifiable]
o Control of charge.
o Records keeping and Recording
Advantages of White box Testing: (-2-) Quality control [QC]: (5M-2012)(8M-2015)(7M-2016)
 Testing can be commenced at an earlier stage. One need not wait for the GUI to be available.  Quality control means testing and it measures the quality of a product. The goal of quality
 Testing is more thorough with the possibility of covering most paths. control is to ensure that the products services of processes provided must specific
requirements and are dependable, satisfactory.
Disadvantages of White box Testing:
 Quality control involves the examination of a product, process for certain minimum levels of
 Since tests can be very complex, highly skilled resources are required, with thorough knowledge quality. The goal of a quality control team is to identify products or services that do not meet
of programming and implementation. a company‟s specified standards of quality.
 White Box Testing is like the work of a mechanic who examines the engine to see why the car is  Quality control concerns not just products, services and processes, but also people.
not moving. Employees are an important part of any company. If a company has employees that do not
Advantages of Black box Testing: have adequate skills or training and knowledge then quality may be severely diminished.

 Tests are done from a user‟s point of view and will help in exposing discrepancies in the DIFFERENCE BETWEEN WHITE-BOX AND BLACK-BOX TESTING: (5M-2012)(5M- The QC system is designed to:
specifications. 2013)(5M-2014) 1. Provide routine and consistent checks to ensure data integrity, correctness, and
 Tester need not know programming languages or how the software has been implemented
Black Box Testing White Box Testing Completeness;
 Test cases can be designed as soon as the specifications are complete
Black Box Testing is a software testing method White Box Testing is a software testing method 2. Identify and address errors and omissions;
 More effective on larger units of code than white box testing
in which the internal structure/design/ in which the internal structure/design/ 3. Document and archive inventory material and record all QC activities.
 Tester and programmer are independent of each other
implementation of the item being tested is implementation of the item being tested is known
Disadvantages of Black box Testing: NOT known to the tester to the tester. (-3-) Quality Planning: (2M-2016)
Mainly applicable to higher levels of testing: Mainly applicable to lower levels of testing unit:  Quality planning establishes the design of a product, service or process that will meet
 Only a small number of possible inputs can be tested and many program paths will be left customer requirements and operational needs to produce the product before it is produced.
acceptance Testing and System Testing. Testing, Integration Testing.
untested Quality planning follows a sequence of steps as follows.
Requirement Specifications Detail Design
 Without clear and concise specifications, test cases are hard to design In white box testing we can test performance In white box testing we cannot test performance 1. Identify customers and target markets.
 May leave many program paths untested of the application of the application 2. Discover hidden and unmet customer needs.
Generally black box testing will begin early in But for white box testing approach one has to 3. Translate their needs into product or service requirement:
the software development i.e. in requirement wait for the designing has to complete. 4. Develop a service on product that exceeds customers needs
gathering phase itself.

Software Engineering 34 Software Engineering 35

♥ The COCOMO model (Constructive Cost Model): (8M-2011)(9M-2013)(10M-2014)(5M- (-Model-2-): Intermediate COCOMO model:
2015)(5M-2016)  Basic COCOMO the effort and development time are function of the product size. Other project
 A number of algorithmic models have been proposed for estimating the effort, schedule and
parameter affects the project cost. Intermediate COCOMO makes use of cost drives and their
costs of a software project.
multiples to estimate the cost.
 The COCOMO model (Constructive Cost Model) is one of the best documented algorithmic cost
estimation model. (-Model-3-): Complete COCOMO:
 The COCOMO model is derived by collecting data from a large number of software projects.
 Basic and intermediary COCOMO considers software product as a single homogeneous entity.
These data were analyzed to discover formulae. These formulae link the size of the system and,
Complex systems are made up of sub-systems. Each parameter of a module must be summed up to
project and team factors to the effort to develop the system.
get complete cost estimation.
COCOMO model takes the following THREE form.
SOFTWARE MAINTENANCE: (2M-2016)
(-Model-1-): The Basic COCOMO model:
This model is a starting point for project estimation. Which computers software development effort  Software maintenance is defined as the process of modifying a software system or component
(&cost) as a function of program size expressed in estimated lines of code. after delivery to correct faults, improve performance or other attributes, or adapt to a changed
 Basic model identify three classes of software projects: environment.
(a) Organic or simple: In the organic mode, small software teams develop software. Most people  Reasons, why modifications are required
connected with the project have extensive experience in working with related systems within the  Market Conditions – Policies, which changes over the time, such as taxation and newly
organization. introduced constraints like, how to maintain bookkeeping, may trigger need for
(b) Embedded: modification.
 Software project is a need to operate within tight constraints  Client Requirements – Over the time, customer may ask for new features or functions in
 The product must operate within a strongly coupled complex of hardware, software regulations, the software.
and operational procedures, such as electronic transfer system or air traffic control system  Host Modifications – if any of the hardware and/or platform (such as operating system) of
(c) Semidetached or moderate: the target host changes, software changes are needed to keep adaptability.
 This mode of software development represents an intermediate stage between the organic and  Organization Changes – if there is any Organization change into new business, need to
embedded modes. modify in the original software may arise.
 „Intermediate‟ may mean either of two thing:
Categories of Maintenance: (5M-2011)(5M-2014)
1. An intermediate level of project characteristics
2. A mixture of the organic and embedded mode characteristics. Following are some types of maintenance based on their characteristics:
 The following Fig.1 shows a plot of estimated effort Vs size for various product size. Effort is
 Corrective Maintenance – This includes modifications and updates done in order to correct or fix
almost linearly proportional to the soft of the software produce. And fig. 2 shows the development
problems, which are either discovered by user or concluded by user error reports.
time Vs product size. Development time is sublinear function of the size of the product. If the size
 Adaptive Maintenance – This includes modifications and updates applied to keep the software
of the product increases by two times, the time to develop does not become double
product up-to date and tuned to the ever changing world of technology and business environment.
Estimation of Effort Vs Size Development Time Vs Size
 Perfective Maintenance – This includes modifications and updates done in order to keep the
software usable over long period of time. It includes new features, new user requirements for
refining the software and improve its reliability and performance.
 Preventive Maintenance – This includes modifications and updates to prevent future problems of
the software. It aims to attend problems, which are not significant at this moment but may cause
serious issues in future.

■■■■■■■■■■■■■■■■■■■■■■■( © ‫طـارق القلوب‬ ^_^ )■■■■■■■■■■■■■■■■■■■■■■■