Software Engineering and Agile

Software Development

Mrs. M.M. Meenakshi

AP / Dept. of AI & DS
SMVEC

Unit 1_Software Engineering Process 1

  UNIT I SOFTWARE ENGINEERING PROCESSES

Software engineering concepts – Development activities – Software

development lifecycle models –Software project management – Project
planning – Estimation – Scheduling – Risk management – Software
configuration management - Project Planning – Empirical Estimation
Techniques – Staffing Level Estimation – Scheduling – Organization and
Team structures – Staffing – Software Requirements specification.

Unit 1_Software Engineering Process 2

About Software Engineering

Unit 1_Software Engineering Process 3

Software:
 Software is a program or set of programs containing instructions that provide
desired functionality. And Engineering is the process of designing and building
something that serves a particular purpose and finds a cost-effective solution
to problems.
 Classification of Software:
i) System Software
ii) Application Software etc,.

Software Engineering:
 Software Engineering is a systematic, disciplined, quantifiable study and
approach to the design, development, operation, and maintenance of a
software system.

Unit 1_Software Engineering Process 4

 Objectives of Software Engineering:
1. Maintainability –
It should be feasible for the software to evolve to meet changing
requirements.
2. Efficiency –
The software should not make wasteful use of computing devices such as
memory, processor cycles, etc.
3. Correctness –
A software product is correct if the different requirements as specified in the
SRS document have been correctly implemented.
4. Reusability –
A software product has good reusability if the different modules of the
product can easily be reused to develop new products.
5. Testability –
Here software facilitates both the establishment of test criteria and the
evaluation of the software with respect to those criteria.

Unit 1_Software Engineering Process 5

Reliability –
 It is an attribute of software quality. The extent to which a program can be
expected to perform its desired function, over an arbitrary time period.
Portability –
 In this case, the software can be transferred from one computer system or
environment to another.
Adaptability –
 In this case, the software allows differing system constraints and the user
needs to be satisfied by making changes to the software.
Interoperability –
Capability of 2 or more functional units to process data cooperatively.

Unit 1_Software Engineering Process 6

Why is Software Engineering required?

 Software Engineering is required due to the following reasons:

• To manage Large software
• For more Scalability
• Cost Management
• To manage the dynamic nature of software
• For better quality Management

Unit 1_Software Engineering Process 7

Characteristics of a good software engineer
The features that good software engineers should possess are as follows:
 Exposure to systematic methods, i.e., familiarity with software engineering
principles.
 Good technical knowledge of the project range (Domain knowledge).
 Good programming abilities.
 Good communication skills. These skills comprise of oral, written, and
interpersonal skills.
 High motivation.
 Sound knowledge of fundamentals of computer science.
 Intelligence.
 Ability to work in a team
 Discipline, etc.

Unit 1_Software Engineering Process 8

Development Activities
 The term software specifies to the set of computer programs, procedures and
associated documents (Flowcharts, manuals, etc.) that describe the program
and how they are to be used.
 A software process is the set of activities and associated outcome that
produce a software product. Software engineers mostly carry out these
activities. These are four key process activities, which are common to all
software processes. These activities are:
1. Software specifications: The functionality of the software and constraints on
its operation must be defined.
2. Software development: The software to meet the requirement must be
produced.
3. Software validation: The software must be validated to ensure that it does
what the customer wants.
4. Software evolution: The software must evolve to meet changing client
needs.
Unit 1_Software Engineering Process 9
Software Process Model
 A software process model is a specified definition of a software process,
which is presented from a particular perspective.
 Models, by their nature, are a simplification, so a software process model is
an abstraction of the actual process, which is being described.
 Process models may contain activities, which are part of the software
process, software product, and the roles of people involved in software
engineering. Some examples of the types of software process models that
may be produced are:
 1. A workflow model
 2. A dataflow or activity model
 3. A role/action model

Unit 1_Software Engineering Process 10

There are several various general models or
paradigms of software development:
1. The waterfall approach: This takes the above activities and produces them as
separate process phases such as requirements specification, software design,
implementation, testing, and so on. After each stage is defined, it is "signed off"
and development goes onto the following stage.

2. Evolutionary development: This method interleaves the activities of

specification, development, and validation. An initial system is rapidly developed
from a very abstract specification.

3. Formal transformation: This method is based on producing a formal mathematical

system specification and transforming this specification, using mathematical
methods to a program. These transformations are 'correctness preserving.' This
means that you can be sure that the developed programs meet its specification.

4. System assembly from reusable components: This method assumes the parts of
the system already exist. The system development process target on integrating
theseEngineering
Unit 1_Software parts rather
Process than developing them from scratch. 11
Software Crisis
1. Size: Software is becoming more expensive and more complex with the growing
complexity and expectation out of software. For example, the code in the
consumer product is doubling every couple of years.

2. Quality: Many software products have poor quality, i.e., the software products
defects after putting into use due to ineffective testing technique. For example,
Software testing typically finds 25 errors per 1000 lines of code.

3. Cost: Software development is costly i.e. in terms of time taken to develop and
the money involved. For example, Development of the Advanced Automation
System cost over $700 per lines of code.

4. Delayed Delivery: Serious schedule overruns are common. Very often the software
takes longer than the estimated time to develop, which in turn leads to cost
shooting up. For example, one in four large-scale development projects is never
completed.
Unit 1_Software Engineering Process 12
What are the attributes of good
software?
 1. Maintainability
 2. Dependability
 3. Efficiency
 4. Usability

Unit 1_Software Engineering Process 13

Program vs. Software
 Software is more than programs. Any program is a subset of software, and it
becomes software only if documentation & operating procedures manuals are
prepared.
 There are three components of the software as shown in fig:

Unit 1_Software Engineering Process 14

 1. Program: Program is a combination of source code & object code.
 2. Documentation: Documentation consists of different types of manuals.
Examples of documentation manuals are: Data Flow Diagram, Flow Charts, ER
diagrams, etc.

Unit 1_Software Engineering Process 15

 3. Operating Procedures: Operating Procedures consist of instructions to set
up and use the software system and instructions on how react to the system
failure. Example of operating system procedures manuals is: installation
guide, Beginner's guide, reference guide, system administration guide, etc.

Unit 1_Software Engineering Process 16

Software Development Life Cycle

 Software Development Life Cycle (SDLC) is a framework that defines the steps
involved in the development of software at each phase.

 It covers the detailed plan for building, deploying and maintaining the
software.

 SDLC defines the complete cycle of development i.e. all the tasks involved in
planning, creating, testing, and deploying a Software Product.

Unit 1_Software Engineering Process 17

 SDLC Cycle
Stages of SDLC:
Stage1: Planning and requirement
analysis
Stage2: Defining Requirements
Stage3: Designing the Software
Stage4: Developing the project
Stage5: Testing
Stage6: Deployment
Stage7: Maintenance

Unit 1_Software Engineering Process 18

Stage1: Planning and requirement analysis
 Requirement Analysis is the most important and necessary stage in SDLC.
 The senior members of the team perform it with inputs from all the stakeholders
and domain experts or SMEs in the industry.
 Planning for the quality assurance requirements and identifications of the risks
associated with the projects is also done at this stage.

 For Example, A client wants to have an application which concerns money

transactions. In this method, the requirement has to be precise like what kind of
operations will be done, how it will be done, in which currency it will be done, etc.

Unit 1_Software Engineering Process 19

 Stage2: Defining Requirements
 Once the requirement analysis is done, the next stage is to certainly
represent and document the software requirements and get them accepted
from the project stakeholders.
 This is accomplished through "SRS"- Software Requirement Specification
document which contains all the product requirements to be constructed and
developed during the project life cycle.

Stage3: Designing the Software

 The next phase is about to bring down all the knowledge of requirements,
analysis, and design of the software project.
 This phase is the product of the last two, like inputs from the customer and
requirement gathering.

Unit 1_Software Engineering Process 20

Stage4: Developing the project
 In this phase of SDLC, the actual development begins, and the programming is
built.
 The implementation of design begins concerning writing code.
 Developers have to follow the coding guidelines described by their
management and programming tools like compilers, interpreters, debuggers,
etc. are used to develop and implement the code.

Stage5: Testing
 After the code is generated, it is tested against the requirements to make
sure that the products are solving the needs addressed and gathered during
the requirements stage.

 During this stage, unit testing, integration testing, system testing, acceptance
testing are done.

Unit 1_Software Engineering Process 21

Stage6: Deployment
 Once the software is certified, and no bugs or errors are stated, then it is
deployed.
 Then based on the assessment, the software may be released as it is or with
suggested enhancement in the object segment.
 After the software is deployed, then its maintenance begins.

Stage7: Maintenance
 Once when the client starts using the developed systems, then the real
issues come up and requirements to be solved from time to time.
 This procedure where the care is taken for the developed product is known
as maintenance.

Unit 1_Software Engineering Process 22

 SDLC Models
 There are different software development life cycle models specify and design, which are
followed during the software development phase. These models are also called "Software
Development Process Models." Each process model follows a series of phase unique to its
type to ensure success in the step of software development.
 Here, are some important phases of SDLC life cycle:

Unit 1_Software Engineering Process 23

Waterfall model(Linear Sequential Model)
 The waterfall is a universally accepted SDLC model. In this method, the whole
process of software development is divided into various phases.
 Winston Royce introduced the Waterfall Model in 1970.
 This model has five phases: Requirements analysis and specification, design,
implementation, and unit testing, integration and system testing, and operation
and maintenance.
 The steps always follow in this order and do not overlap.
 The developer must complete every phase before the next phase begins.
 This model is named "Waterfall Model", because its diagrammatic representation
resembles a cascade of waterfalls.

Unit 1_Software Engineering Process 24

Unit 1_Software Engineering Process 25
(OR)

Unit 1_Software Engineering Process 26

1. Requirements analysis and specification phase:

• The system's services, constraints and goals are established by

consultation with system users.

• Both the customer and the software developer work together so as to

document all the functions, performance, and interfacing requirement of
the software.

• It describes the "what" of the system to be produced and not "how.“

• In this phase, a large document called Software Requirement

Specification (SRS) document is created which contained a detailed
description of what the system will do in the common language.

Unit 1_Software Engineering Process 27

 2. Design Phase:

 This phase aims to transform the requirements gathered in the SRS into a
suitable form which permits further coding in a programming language.

 It defines the overall software architecture together with high level and
detailed design. All this work is documented as a Software Design Document
(SDD).

Unit 1_Software Engineering Process 28

 3. Implementation and unit testing:

• During this phase, design is implemented. If the SDD is complete, the

implementation or coding phase proceeds smoothly, because all the
information needed by software developers is contained in the SDD.

• During testing, the code is thoroughly examined and modified.

• Small modules are tested in isolation initially.

• After that these modules are tested by writing some overhead code to check
the interaction between these modules and the flow of intermediate
output.

Unit 1_Software Engineering Process 29

 4. Integration and System Testing:
 This phase is highly crucial as the quality of the end product is determined by
the effectiveness of the testing carried out.
 The better output will lead to satisfied customers, lower maintenance costs,
and accurate results. Unit testing determines the efficiency of individual
modules.
 However, in this phase, the modules are tested for their interactions with
each other and with the system.

 5. Operation and maintenance phase:

 Maintenance is the task performed by every user once the software has been
delivered to the customer, installed, and operational.

Unit 1_Software Engineering Process 30

When to use SDLC Waterfall Model?
 Some Circumstances where the use of the Waterfall model is most suited are:
• When the requirements are constant and not changed regularly.
• A project is short
• The situation is calm
• Where the tools and technology used is consistent and is not changing
• When resources are well prepared and are available to use.

Unit 1_Software Engineering Process 31

 Advantages of Waterfall model:
• Simple and Easy to understand and use.
• Easy to Manage.
• The start and end points for each phase is fixed, which makes it easy to cover
progress.
• Requirements are very well understand.
• Clear defined stages.
 Disadvantages of Waterfall model
• In this model, the risk factor is higher, so this model is not suitable for more
significant and complex projects.
• This model cannot accept the changes in requirements during development.
• It becomes tough to go back to the phase. For example, if the application has
now shifted to the coding phase, and there is a change in requirement, It
becomes tough to go back and change it.

Unit 1_Software Engineering Process 32

Spiral Model
 The spiral model, initially proposed by Boehm, is an evolutionary software
process model that couples the iterative feature of prototyping with the
controlled and systematic aspects of the linear sequential model.
 Using the spiral model, the software is developed in a series of incremental
releases.
 During the early iterations, the additional release may be a paper model or
prototype.
 During later iterations, more and more complete versions of the engineered
system are produced.

Unit 1_Software Engineering Process 33

Unit 1_Software Engineering Process 34
Each cycle in the spiral is divided into four parts:

 Objective setting: Each cycle in the spiral starts with the identification of
purpose for that cycle, the various alternatives that are possible for achieving
the targets, and the constraints that exists.

 Risk Assessment and reduction: The next phase in the cycle is to calculate
these various alternatives based on the goals and constraints. The focus of
evaluation in this stage is located on the risk perception for the project.

 Development and validation: The next phase is to develop strategies that

resolve uncertainties and risks. This process may include activities such as
benchmarking, simulation, and prototyping.

 Planning: Finally, the next step is planned. The project is reviewed, and a
choice made whether to continue with a further period of the spiral. If it is
determined to keep, plans are drawn up for the next step of the project.

Unit 1_Software Engineering Process 35

 When to use Spiral Model?
• When deliverance is required to be frequent.
• When the project is large
• When requirements are unclear and complex
• When changes may require at any time
• Large and high budget projects
 Advantages
• High amount of risk analysis
• Useful for large and mission-critical projects.
 Disadvantages
• Can be a costly model to use.
• Risk analysis needed highly particular expertise
• Doesn't work well for smaller projects.

Unit 1_Software Engineering Process 36

Incremental Model
 Incremental Model is a process of software development where requirements
divided into multiple standalone modules of the software development cycle.
 In this model, each module goes through the requirements, design,
implementation and testing phases. Every subsequent release of the module
adds function to the previous release. The process continues until the
complete system achieved.

Unit 1_Software Engineering Process 37

RAD (Rapid Application Development) Model
 It is an incremental model that emphysizes on extremely short development
cycle (60 to 90 days).
Phases:
 1. Communication
 2. Planning
 3. Modeling
 i)Business Modelling
 ii) Data Modelling
 Iii) Process Modelling

 4. Construction-Application Generation
 5.Deployment-Testing & Turnover

Unit 1_Software Engineering Process 38

Unit 1_Software Engineering Process 39
Agile Model
 The meaning of Agile is swift or versatile.
 "Agile process model" refers to a software development approach based on
iterative development.
 Agile methods break tasks into smaller iterations, or parts do not directly
involve long term planning.
Phases of Agile Model:
 Following are the phases in the Agile model are as follows:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

Unit 1_Software Engineering Process 40

 Agile Testing Methods:
• Scrum
• Crystal
• Dynamic Software Development Method(DSDM)
• Feature Driven Development(FDD)
• Lean Software Development
• eXtreme Programming(XP)

Unit 1_Software Engineering Process 41

 V-Model
 V-Model also referred to as the Verification and Validation Model. In this, each
phase of SDLC must complete before the next phase starts.
 It follows a sequential design process same as the waterfall model. Testing of
the device is planned in parallel with a corresponding stage of development.

Unit 1_Software Engineering Process 42

Iterative Model:

 In this Model, you can start with some of the software specifications and develop the
first version of the software.
 After the first version if there is a need to change the software, then a new version of
the software is created with a new iteration.
 Every release of the Iterative Model finishes in an exact and fixed period that is
called iteration.
Big Bang Model:
 In this model, developers do not follow any specific process. Development begins
with the necessary funds and efforts in the form of inputs. And the result may or may
not be as per the customer's requirement, because in this model, even the customer
requirements are not defined.
Prototype Model:
 The prototype model requires that before carrying out the development of actual
software, a working prototype of the system should be built.
 A prototype is a toy implementation of the system.
 A prototype usually turns out to be a very crude version of the actual system, possible
exhibiting limited functional capabilities, low reliability, and inefficient performance
as compared to actual software.
In many instances, the client only has a general view of what is expected from the43
 1_Software Engineering Process
Unit

software product.
Software project management

 Software project management is an art and discipline of planning and

supervising software projects. It is a sub-discipline of software project
management in which software projects planned, implemented, monitored
and controlled.
 It is a procedure of managing, allocating and timing resources to develop
computer software that fulfills requirements.
 In software Project Management, the client and the developers need to know
the length, period and cost of the project.

Unit 1_Software Engineering Process 44

Project Manager
 A project manager is a character who has the overall responsibility for the
planning, design, execution, monitoring, controlling and closure of a
project.
 A project manager represents an essential role in the achievement of the
projects.

Unit 1_Software Engineering Process 45

 Role of a Project Manager:
1. Leader
2. Medium
3. Mentor
Responsibilities of a Project Manager:
1. Managing risks and issues.
2. Create the project team and assigns tasks to several team members.
3. Activity planning and sequencing.
4. Monitoring and reporting progress.
5. Modifies the project plan to deal with the situation.

Unit 1_Software Engineering Process 46

Success criteria

 Deliver the software to the customer at the agreed time.

 Keep overall costs within budget.
 Deliver software that meets the customer’s expectations.
 Maintain a coherent and well-functioning development team.

Unit 1_Software Engineering Process 47

 Software management distinctions
 The product is intangible.
 Software cannot be seen or touched. Software project managers cannot see
progress by simply looking at the artefact that is being constructed.
 Many software projects are 'one-off' projects.
 Large software projects are usually different in some ways from previous projects.
Even managers who have lots of previous experience may find it difficult to
anticipate problems.
 Software processes are variable and organization specific.
 We still cannot reliably predict when a particular software process is likely to lead
to development problems.

Unit 1_Software Engineering Process 48

Factors influencing project management
 Company size
 Software customers
 Software size
 Software type
 Organizational culture
 Software development processes
 These factors mean that project managers in different organizations may
work in quite different ways.

Unit 1_Software Engineering Process 49

Universal Project management activities
 Proposal writing
 The first stage in a software project may involve writing a proposal to win a
contract to carry out an item of work. The proposal describes the objectives of the
project and how it will be carried out.
 Project planning
 Project managers are responsible for planning, estimating and scheduling project
development and assigning people to tasks.
 Risk management
Project managers assess the risks that may affect a project, monitor these
risks and take action when problems arise.

Unit 1_Software Engineering Process 50

 Project Cost:
Cost estimation is a related activity that is concerned with estimating
the resources required to accomplish the project plan.
 Project Monitoring and reviews:
Project monitoring is a continuing project activity. The manager must keep track
of the progress of the project and compare actual and planned progress and costs.
 Report writing and presentation
Project managers are usually responsible for reporting on the progress of a project
to customers and to the managers of the company developing the software.

Unit 1_Software Engineering Process 51

Project planning
 Project planning involves breaking down the work into parts and assign these
to project team members, anticipate problems that might arise and prepare
tentative solutions to those problems.
 The project plan, which is created at the start of a project, is used to
communicate how the work will be done to the project team and customers,
and to help assess progress on the project.

Unit 1_Software Engineering Process 52

Planning stages
 At the proposal stage, when you are bidding for a contract to develop or
provide a software system.
 During the project startup phase, when you have to plan who will work on the
project, how the project will be broken down into increments, how resources
will be allocated across your company, etc.
 Periodically throughout the project, when you modify your plan in the light of
experience gained and information from monitoring the progress of the work.

Unit 1_Software Engineering Process 53

Proposal planning
 Planning may be necessary with only outline software requirements.
 The aim of planning at this stage is to provide information that will be used in
setting a price for the system to customers.
 Project pricing involves estimating how much the software will cost to
develop, taking factors such as staff costs, hardware costs, software costs,
etc.

Unit 1_Software Engineering Process 54

Project startup planning
 At this stage, you know more about the system requirements but do not have
design or implementation information
 Create a plan with enough detail to make decisions about the project budget
and staffing.
 This plan is the basis for project resource allocation
 The startup plan should also define project monitoring mechanisms
 A startup plan is still needed for agile development to allow resources to be
allocated to the project

Unit 1_Software Engineering Process 55

Development planning
 The project plan should be regularly amended as the project progresses and
you know more about the software and its development
 The project schedule, cost-estimate and risks have to be regularly revised

Unit 1_Software Engineering Process 56

Project scheduling
 Project scheduling is the process of deciding how the work in a project will be
organized as separate tasks, and when and how these tasks will be executed.
 You estimate the calendar time needed to complete each task, the effort
required and who will work on the tasks that have been identified.
 You also have to estimate the resources needed to complete each task, such
as the disk space required on a server, the time required on specialized
hardware, such as a simulator, and what the travel budget will be.

Unit 1_Software Engineering Process 57

Project scheduling activities
 Split project into tasks and estimate time and resources required to complete
each task.
 Organize tasks concurrently to make optimal
use of workforce.
 Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
 Dependent on project managers intuition and experience.

Unit 1_Software Engineering Process 58

The project scheduling process

Unit 1_Software Engineering Process 59

Scheduling problems

 Estimating the difficulty of problems and hence the cost of developing a

solution is hard.
 Productivity is not proportional to the number of people working on a task.
 Adding people to a late project makes it later because of communication
overheads.
 The unexpected always happens. Always allow contingency in planning.

Unit 1_Software Engineering Process 60

Schedule presentation
 Graphical notations are normally used to illustrate the project schedule.
 These show the project breakdown into tasks. Tasks should not be too small.
They should take about a week or two.
 Calendar-based
 Bar charts are the most commonly used representation for project schedules. They
show the schedule as activities or resources against time.
 Activity networks
 Show task dependencies

Unit 1_Software Engineering Process 61

 Risk management
 Risk management is concerned with identifying risks and drawing up plans to
minimise their effect on a project.
 Software risk management is important because of the inherent uncertainties
in software development.
 These uncertainties stem from loosely defined requirements, requirements changes
due to changes in customer needs, difficulties in estimating the time and resources
required for software development, and differences in individual skills.
 You have to anticipate risks, understand the impact of these risks on the
project, the product and the business, and take steps to avoid these risks.

Unit 1_Software Engineering Process 62

Risk classification
 There are two dimensions of risk classification
 The type of risk (technical, organizational, ..)
 what is affected by the risk:
 Project risks affect schedule or resources;
 Product risks affect the quality or performance of the software being
developed;
 Business risks affect the organisation developing or procuring the software.

Unit 1_Software Engineering Process 63

Examples of project, product, and
business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is
finished.
Management change Project There will be a change of organizational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not
be delivered on schedule.
Requirements change Project and product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule.
Size underestimate Project and product The size of the system has been underestimated.

CASE tool Product CASE tools, which support the project, do not
underperformance perform as anticipated.
Technology change Business The underlying technology on which the system
is built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.
Unit 1_Software Engineering Process 64
The risk management process
 Risk identification
 Identify project, product and business risks;
 Risk analysis
 Assess the likelihood and consequences of these risks;
 Risk planning
 Draw up plans to avoid or minimise the effects of the risk;
 Risk monitoring
 Monitor the risks throughout the project;

Unit 1_Software Engineering Process 65

The risk management process

Unit 1_Software Engineering Process 66

Risk identification
 May be a team activities or based on the individual project manager’s
experience.
 A checklist of common risks may be used to identify risks in a project
 Technology risks.
 Organizational risks.
 People risks.
 Requirements risks.
 Estimation risks.

Unit 1_Software Engineering Process 67

Examples of different risk types
Risk type Possible risks
Estimation The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
Organizational The organization is restructured so that different management are responsible for
the project. (6)
Organizational financial problems force reductions in the project budget. (7)
People It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Requirements Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Technology The database used in the system cannot process as many transactions per
second as expected. (1)
Reusable software components contain defects that mean they cannot be reused
as planned. (2)
Tools The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)

Unit 1_Software Engineering Process 68

Risk analysis
 Assess probability and seriousness of each risk.
 Probability may be very low, low, moderate, high or very high.
 Risk consequences might be catastrophic, serious, tolerable or insignificant.

Unit 1_Software Engineering Process 69

 Risk types and examples
Risk Probability Effects

Organizational financial problems force reductions in the Low Catastrophic

project budget (7).
It is impossible to recruit staff with the skills required for the High Catastrophic
project (3).
Key staff are ill at critical times in the project (4). Moderate Serious
Faults in reusable software components have to be repaired Moderate Serious
before these components are reused. (2).
Changes to requirements that require major design rework Moderate Serious
are proposed (10).
The organization is restructured so that different High Serious
management are responsible for the project (6).
The database used in the system cannot process as many Moderate Serious
transactions per second as expected (1).

Unit 1_Software Engineering Process 70

Risk types and examples
Risk Probability Effects

The time required to develop the software is High Serious

underestimated (12).
Software tools cannot be integrated (9). High Tolerable
Customers fail to understand the impact of requirements Moderate Tolerable
changes (11).
Required training for staff is not available (5). Moderate Tolerable
The rate of defect repair is underestimated (13). Moderate Tolerable
The size of the software is underestimated (14). High Tolerable
Code generated by code generation tools is inefficient (8). Moderate Insignificant

Unit 1_Software Engineering Process 71

Risk planning
 Consider each risk and develop a strategy to manage that risk.
 Avoidance strategies
 The probability that the risk will arise is reduced;
 Minimization strategies
 The impact of the risk on the project or product will be reduced;
 Contingency plans
 If the risk arises, contingency plans are plans to deal with that risk;

Unit 1_Software Engineering Process 72

Key points
 People management involves choosing the right people to work on a
project and organizing the team and its working environment.
 People are motivated by interaction with other people, the recognition of
management and their peers, and by being given opportunities for
personal development.
 Software development groups should be fairly small and cohesive. The
key factors that influence the effectiveness of a group are the people in
that group, the way that it is organized and the communication between
group members.
 Communications within a group are influenced by factors such as the
status of group members, the size of the group, the gender composition
of the group, personalities and available communication channels.

Unit 1_Software Engineering Process 73

 Software Configuration Management
 The elements that comprise all information produced as a part of the
software process are collectively called a software configuration.
 As software development progresses, the number of Software Configuration
elements (SCI's) grow rapidly.
 These are handled and controlled by SCM. This is where we require software
configuration management.
 Therefore, SCM is the discipline which
• Identify change
• Monitor and control change
• Ensure the proper implementation of change made to the item.
• Auditing and reporting on the change made.
 The objective is to maximize productivity by minimizing mistakes (errors).

Unit 1_Software Engineering Process 74

SCM Process
 The SCM process defines a number of tasks:
• Identification of objects in the software configuration
• Version Control
• Change Control
• Configuration Audit
• Status Reporting

Unit 1_Software Engineering Process 75

 Identification:
 Basic Object: Unit of Text created by a software engineer during analysis,
design, code, or test.
 Aggregate Object: A collection of essential objects and other aggregate
objects. Design Specification is an aggregate object.
 Each object has a set of distinct characteristics that identify it uniquely: a
name, a description, a list of resources, and a "realization."
 The interrelationships between configuration objects can be described
with a Module Interconnection Language (MIL).
 Version Control
 Version Control combines procedures and tools to handle different version of
configuration objects that are generated during the software process.

Unit 1_Software Engineering Process 76

Clemm defines version control in the context of SCM:
Configuration management allows a user to specify the alternative configuration
of the software system through the selection of appropriate versions.
Change Control
James Bach describes change control in the context of SCM is: Change Control is
Vital. But the forces that make it essential also make it annoying.
The "check-in" and "check-out" process implements two necessary elements of
change control-access control and synchronization control.
 Access Control governs which software engineers have the authority to
access and modify a particular configuration object.
 Synchronization Control helps to ensure that parallel changes, performed by
two different people, don't overwrite one another.

Unit 1_Software Engineering Process 77

 Software Engineering is required due to the following reasons:
• To manage Large software
• For more Scalability
• Cost Management
• To manage the dynamic nature of software
• For better quality Management
Configuration Audit
 SCM audits to verify that the software product satisfies the baselines
requirements and ensures that what is built and what is delivered.
 SCM audits also ensure that traceability is maintained between all CIs and
that all work requests are associated with one or more CI modification.
 SCM audits are the "watchdogs" that ensures that the integrity of the project's
scope is preserved.

Unit 1_Software Engineering Process 78

 Status Reporting
 Configuration Status reporting (sometimes also called status accounting)
providing accurate status and current configuration data to developers,
testers, end users, customers and stakeholders through admin guides, user
guides, FAQs, Release Notes, Installation Guide, Configuration Guide, etc.

Unit 1_Software Engineering Process 79

Software Quality Assurance
What is Quality?
 Quality defines to any measurable characteristics such as correctness,
maintainability, portability, testability, usability, reliability, efficiency,
integrity, reusability, and interoperability.
There are two kinds of Quality:

Unit 1_Software Engineering Process 80

 Quality of Design: Quality of Design refers to the characteristics that designers
specify for an item. The grade of materials, tolerances, and performance
specifications that all contribute to the quality of design.
 Quality of conformance: Quality of conformance is the degree to which the
design specifications are followed during manufacturing. Greater the degree of
conformance, the higher is the level of quality of conformance.
 Software Quality: Software Quality is defined as the conformance to explicitly
state functional and performance requirements, explicitly documented
development standards, and inherent characteristics that are expected of all
professionally developed software.
 Quality Control: Quality Control involves a series of inspections, reviews, and
tests used throughout the software process to ensure each work product meets
the requirements place upon it. Quality control includes a feedback loop to the
process that created the work product.

Unit 1_Software Engineering Process 81

 Quality Assurance: Quality Assurance is the preventive set of activities that provide
greater confidence that the project will be completed successfully.
 Quality Assurance focuses on how the engineering and management activity will be
done?
 As anyone is interested in the quality of the final product, it should be assured that we
are building the right product.
 It can be assured only when we do inspection & review of intermediate products, if
there are any bugs, then it is debugged. This quality can be enhanced.

Software Quality Assurance

 Software quality assurance is a planned and systematic plan of all actions necessary to
provide adequate confidence that an item or product conforms to establish technical
requirements.
 A set of activities designed to calculate the process by which the products are
developed or manufactured.

Unit 1_Software Engineering Process 82

Quality Assurance v/s Quality control

Unit 1_Software Engineering Process 83

Project Monitoring and Control

 Monitoring and Controlling are processes needed to track, review, and

regulate the progress and performance of the project.
 It also identifies any areas where changes to the project management method
are required and initiates the required changes.

Unit 1_Software Engineering Process 84

Monitoring and Controlling Process
 Monitoring and Controlling are processes needed to track, review, and
regulate the progress and performance of the project.
 It also identifies any areas where changes to the project management method
are required and initiates the required changes.
o 1. Monitor and control project work
o 2. Perform integrated change control
o 3. . Validate scope
o 4. Control scope
o 5. Control schedule
o 6. Control costs
o 7. Control quality
o 8. Control communications
o 9. Control Risks
o 10. Control procurements
o 11. Control stakeholder engagement
Unit 1_Software Engineering Process 85
 Cost Estimation Models in Software Engineering:
The cost estimate is the financial spend that is done on the efforts to
develop and test software.

Unit 1_Software Engineering Process 86

 Empirical Estimation Technique –
o Empirical estimation is a technique or model in which empirically derived
formulas.
o It is used for predicting the data that are a required and essential part of the
software project planning step.
o These techniques are usually based on the data that is collected previously
from a project and also based on some guesses, prior experience with the
development of similar types of projects, and assumptions.
o It uses the size of the software to estimate the effort.
For example Delphi technique and Expert Judgement technique(Expert
Oopinion).

Unit 1_Software Engineering Process 87

Heuristic Technique –
 Heuristic word is derived from a Greek word that means “to discover”.
 The heuristic technique is a technique or model that is used for solving
problems, learning, or discovery in the practical methods which are used for
achieving immediate goals.
 These techniques are flexible and simple for taking quick decisions through
shortcuts and good enough calculations, most probably when working with
complex data.
 But the decisions that are made using this technique are necessary to be
optimal.
 In this technique, the relationship among different project parameters is
expressed using mathematical equations.
 The popular heuristic technique is given by Constructive Cost Model
(COCOMO). This technique is also used to increase or speed up the analysis
and investment decisions.

Unit 1_Software Engineering Process 88

Analytical Estimation Technique –
 It is used to measure work.
 In this technique, firstly the task is divided or broken down into its basic component
operations or elements for analyzing.
 Second, if the standard time is available from some other source, then these sources
are applied to each element or component of work.
 Third, if there is no such time available, then the work is estimated based on the
experience of the work. In this technique, results are derived by making certain
basic assumptions about the project.


Unit 1_Software Engineering Process 89

 Staffing Level Estimation

 To develop a software has been determined, it is necessary to determine the

staffing requirement for the project.
 3 Model:
 Norden’s Work
 Putnam’s Work
 Jenson’s Model

Unit 1_Software Engineering Process 90

 Norden’s Work
E = K/t²d * t * e-t² / 2 t² d
Where E is the effort required at time t
K is the area under the curve
td is the time at which the curve attains its maximum value
Results of Norden are applicable to general R & D projects and were not meant
to model the staffing pattern of software development project

Unit 1_Software Engineering Process 91

Putnam’s Work
L = Ck K 1/3td 4/3
K is the total effort expended (in PM) in the product development
L is the product size in KLOC.
td corresponds to the time of system and integration testing
Ck is the state of technology constant
Typical values of Ck = 2 for poor development environment (no methodology, poor
documentation, and review, etc.)
Ck = 8 for good software development environment (software engineering principles
are adhered to)
Ck = 11 for an excellent environment (in addition to following software engineering
principles, automated tools and techniques are used).

Unit 1_Software Engineering Process 92

Effect of schedule change on cost
 By analysing a large number of army projects, Putnam
derived the following expression:
 K = L 3 /C k 3 td 4 OR K = C/td 4
 For the same product size, C = L3 / C k 3 is a constant
or, K1/K2 = td24 /t d1 4 or, K ∝ 1/td 4 or, cost ∝ 1/td

Unit 1_Software Engineering Process 93

 Organization and Team structures
Organization Structure:
Three broad ways in which a software development
organization can be structured,
i) Functional format
ii) Project format
iii) Matrix format

Unit 1_Software Engineering Process 94

Functional format:
In the functional format, totally different groups of programmers perform
different phases of a project.
For example, one team may do the necessities specification, another do the
planning, and so on.
The partially completed product passes from one team to a different because the
project evolves.

Unit 1_Software Engineering Process 95

Project format:
In the project format, a group of engineers is appointed to the project at the
beginning of the project and that they stay with the project until the completion
of the project.
Thus, the identical team carries out all the life cycle activities.
Obviously, the functional format needs a lot of communication among groups
than the project format, as a result of one team should perceive the work done
by the previous groups.

Unit 1_Software Engineering Process 96

Matrix Organizational Structure:
The matrix form of organization seeks to achieve the twin objectives of
efficient use of resources and effective realization of project objectives,
– at the cost of greater organizational complexity.

In this form of organization, the personnel working on the project have a

responsibility to their functional superior as well as the project managers.

Unit 1_Software Engineering Process 97

Team Structure:
 Team Structure addresses organization of the individual project teams.
1. Chief-programmer team
2. Democratic team
3. Mixed team
Chief-programmer team:
 This team organization is composed of a small team consisting the following team
members :

• The Chief programmer : It is the person who is actively involved in the planning,
specification and design process and ideally in the implementation process as well.
• The project assistant : It is the closest technical co-worker of the chief
programmer.
• The project secretary : It relieves the chief programmer and all other
programmers of administration tools.
• Specialists : These people select the implementation language, implement
individual system components and employ software tools and carry out tasks.

Unit 1_Software Engineering Process 98

 Advantages of Chief-programmer team organization :

•Centralized decision-making
•Reduced communication paths
•Small teams are more productive than large teams
Disadvantages of Chief-programmer team organization :

•Project survival depends on one person only.

•Can cause the psychological problems as the “chief programmer” is like the
“king”
Unit 1_Software who
Engineering takes all the credit and other members are resentful.
Process 99

•Team organization is limited to only small team and small team cannot
 Democratic Team Organization :
It is quite similar to the egoless team organization, but one member is the
team leader with some responsibilities :

• Coordination
• Final decisions, when consensus cannot be reached.
 Advantages of Democratic Team Organization :

• Each member can contribute to decisions.

• Members can learn from each other.
• Improved job satisfaction.
 Disadvantages of Democratic Team Organization :

• Communication overhead increased.

• Need for compatibility of members.
• Less individual responsibility and authority.

Unit 1_Software Engineering Process 100

Mixed Control team organization:
In this, the people of organization at different levels following a tree
structure.
People at bottom level generally possess most detailed knowledge about the
system.
People at higher levels have broader appreciation of the whole project.

Unit 1_Software Engineering Process 101

Staffing
 Software project managers usually take the responsibility of choosing their
team, they need to identify good software developers for the success of
the project.

 A common misconception held by managers as evidenced in their staffing,

planning and scheduling practices, is the assumption that one software
engineer is as productive as another.

 Experiments have revealed that there exists a large variability of

productivity between the worst and the best software developers in a scale
of 1 to 30.

 So choosing good software developers is crucial to the success of a project.

Unit 1_Software Engineering Process 102

Attributes of Good software developers:
The following attributes that good software developers should possess:
 Exposure to systematic techniques, i.e. familiarity with software engineering
principles.
 Good technical knowledge of the project areas(Domain knowledge)
 Good programming abilities
 Good communication skills. The skills comprise of oral and written skills.
 High motivation
 Sound knowledge of fundamentals of computer science
 Intelligence
 Ability to work in a team
 Discipline ,etc.

Unit 1_Software Engineering Process 103

Software Requirement Specification(SRS)
 A software requirements specification (SRS) is a document that captures
complete description about how the system is expected to perform. It is
usually signed off at the end of requirements engineering phase.
 The basic goal of the requirement phase is to produce the SRS, which
describes the complete behavior of the proposed software.
 SRS is also helping the clients to understand their own needs.
Advantages
• Software SRS establishes the basic for agreement between the client and the
supplier on what the software product will do.
• SRS provides a reference for validation of the final product.
• A high-quality SRS is a prerequisite to high-quality software.
• A high-quality SRS reduces the development cost.

Unit 1_Software Engineering Process 104

Characteristics of good SRS
 Correctness
 Completeness
 Consistency
 Unambiguousness
 Ranking for importance and stability
 Modifiability
 Verifiability
 Traceability
 Testability
 Design Independence
 Understandable by the customer
 Right level of Abstraction

Unit 1_Software Engineering Process 105

Correctness:
 User review is used to ensure the correctness of requirements stated in the
SRS.
 SRS is said to be correct if it covers all the requirements that are actually
expected from the system.
Completeness:
 Completeness of SRS indicates every sense of completion including the
numbering of all the pages, resolving the to be determined parts to as much
extent as possible as well as covering all the functional and non-functional
requirements properly.
Consistency:
 Requirements in SRS are said to be consistent if there are no conflicts
between any set of requirements.
 Examples of conflict include differences in terminologies used at separate
places, logical conflicts like time period of report generation, etc.

Unit 1_Software Engineering Process 106

Unambiguous:
 An SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and buddy checks, etc.

Ranking for importance and stability:

 There should a criterion to classify the requirements as less or more important or
more specifically as desirable or essential.
 An identifier mark can be used with every requirement to indicate its rank or
stability.
Modifiability:
 SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent.
 Modifications should be properly indexed and cross-referenced.
Verifiability:
 An SRS is verifiable if there exists a specific technique to quantifiably measure the
extent to which every requirement is met by the system.

Unit 1_Software Engineering Process 107

Traceability:
 One should be able to trace a requirement to a design component and then to a
code segment in the program.
 Similarly, one should be able to trace a requirement to the corresponding test
cases.
There are two types of Traceability:
1. Backward Traceability: This depends upon each requirement explicitly referencing
its source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique
name or reference number.
 The forward traceability of the SRS is especially crucial when the software product
enters the operation and maintenance phase. As code and design document is
modified, it is necessary to be able to ascertain the complete set of requirements
that may be concerned by those modifications.
Design Independence:
 There should be an option to choose from multiple design alternatives for the final
system. More specifically, the SRS should not include any implementation details.

Unit 1_Software Engineering Process 108

Testability:
 An SRS should be written in such a way that it is easy to generate test cases
and test plans from the document.
Understandable by the customer:
 An end user maybe an expert in his/her specific domain but might not be an
expert in computer science.
 Hence, the use of formal notations and symbols should be avoided to as much
extent as possible. The language should be kept easy and clear.
Right level of abstraction:
 If the SRS is written for the requirements phase, the details should be
explained explicitly.
 Whereas, for a feasibility study, fewer details can be used. Hence, the level
of abstraction varies according to the purpose of the SRS.

Unit 1_Software Engineering Process 109

Types of Requirements
A software requirement are 3 types:
• Functional requirements
• Non-functional requirements
• Domain requirements

Unit 1_Software Engineering Process 110

FUNCTIONAL REQUIREMENTS
 A Functional Requirement (FR) is a description of the service that the
software must offer.
 Functional requirements are product features that developers must
implement to enable the users to achieve their goals. They define the basic
system behavior under specific conditions.
 It describes a software system or its component. A function is nothing but
inputs to the software system, its behavior, and outputs
 It can be a calculation, data manipulation, business process, user interaction,
or any other specific functionality which defines what function a system is
likely to perform.
 Functional Requirements in Software Engineering are also called Functional
Specification.

Unit 1_Software Engineering Process 111

Functional Requirement Specifications:
The following are the key fields, which should be part of the functional
requirements specifications document:
 Purpose of the Document
 Scope
 Business Processes
 Data and Integration
 Security Requirements
 Performance
 Data Migration & Conversion

Unit 1_Software Engineering Process 112

Identification of functional requirement:
 Identifying Essential Functions
 Identifying Vital Records, Systems, and Equipment
 Naming Key Personnel
 Selecting an Alternate Facility
 Determining the existence of Interoperable Communications

Unit 1_Software Engineering Process 113

NON-FUNCTIONAL REQUIREMENTS
 Non-Functional Requirements are the constraints or the requirements
imposed on the system. They specify the quality attribute of the software.
 Non-Functional Requirements deal with issues like scalability, maintainability,
performance, portability, security, reliability, and many more. Non-Functional
Requirements address vital issues of quality for software systems.
 If NFRs not addressed properly, the results can include:
• Users, clients, and developers are unsatisfied.
• Inconsistent software.
• Time and cost overrun to fix the software which was prepared without
keeping NFRs in mind.

Unit 1_Software Engineering Process 114

Types of Non-functional Requirement :
1. Scalability
2. Reliability
3. Regulatory
4. Maintainability
5. Serviceability
6. Utility
7. Security
8. Manageability
9. Data integrity
10. Capacity
11. Availability
12. Usability
13. Interoperability
14. Environmental

Unit 1_Software Engineering Process 115

Advantages of Non-Functional Requirement
• The nonfunctional requirements ensure the software system follow legal and
compliance rules.
• They ensure the reliability, availability, and performance of the software
system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.
Disadvantages of Non-functional requirement
• None functional requirement may affect the various high-level software
subsystem
• They require special consideration during the software architecture/high-
level design phase which increases costs.
• Their implementation does not usually map to the specific software sub-
system,
• It is tough to modify non-functional once you pass the architecture phase
Unit 1_Software Engineering Process 116
Difference between functional and non functional requirement
Parameters Functional Requirement Non-Functional Requirement
What is it? Verb Attributes
Requirement It is mandatory It is non-mandatory

Capturing type It is captured in use case. It is captured as a quality attribute.

End-result Product feature Product properties

Capturing Easy to capture Hard to capture

Helps you to verify the performance of the

Objective Helps you verify the functionality of the software.
software.

Area of focus Focus on user requirement Concentrates on the user’s expectation.

Documentation Describe what the product does Describes how the product works

Functional Testing like System, Integration, End to Non-Functional Testing like Performance,
Type of Testing
End, API testing, etc. Stress, Usability, Security testing, etc.

Test Execution Test Execution is done before non-functional testing. After the functional testing

Product Info Product Features Product Properties

Unit 1_Software Engineering Process 117

 THANK YOU

Unit 1_Software Engineering Process 118