STUDY MATERIAL - NEP SYLLABUS

Class: IV Semester BCA

Subject: SOFTWARE ENGINEERING

By

Ms. Hemalatha R.,

Associate Professor,
Department of Computer Science

1
 CA-C16T : SOFTWARE ENGINEERING

Total Teaching Hours: 48 No. of Hours / Week: 03

UNIT – I [12 Hours]

Introduction to Software Engineering: Evolution and impact of Software engineering,

software life cycle models: Waterfall, prototyping, Evolutionary, and Spiral models.
Feasibility study, Functional and Non-functional requirements, Requirements gathering,
Requirements analysis and specification. Agile development: Agile, Agility and cost of
change; Agile Process, Extreme programming; Other agile process models.

UNIT - II [12 Hours]

Formal Modeling and verification: The cleanroom strategy; Functional specification;

Cleanroom design; Cleanroom testing; Formal methods: Concepts; Applying
mathematical notation for formal specification; Formal specification languages.
Software Project Management: The management spectrum; The management of people,
product, process and project; The W5HH Principle; Critical practices. Software testing
strategies: A Strategic Approach to Software Testing, Test Strategies for Conventional
Software, Test Strategies for Object-Oriented Software, Test Strategies for WebApps,
System Testing, Software Testing Fundamentals, White-Box Testing, Black-Box
Testing

UNIT - III [12 Hours]

Software Project Scheduling: Basic concepts and principles of project scheduling;

Defining task set and task network; Scheduling; Earned value analysis. Risk
Management: Reactive versus proactive strategies; Software risks; risk identification;
Risk projection; Risk refinement; Risk mitigation, monitoring and management; The
RMMM plan. Maintenance and reengineering: Software maintenance; Software
supportability; Reengineering; Business process reengineering; Software reengineering;
Reverse engineering; Restructuring; Forward engineering; The economics of
reengineering.

UNIT - IV [12 Hours]

Software Process Improvement (SPI): Approaches to SPI; Maturity models; The SPI
process; The CMMI; The People CMM; Other SPI frameworks: SPICE, Bootstrap, PSP
and TSP, ISO; SPI return on investment. Software Configuration Management (SCM):
Basic concepts; SCM repository; The SCM process; Configuration management for
web applications; SCM standards.

2
 SOFTWARE ENGINEERING

UNIT – 1

INTRODUCTION TO SOFTWARE ENGINEERING

Software engineering has evolved significantly since its inception in the 1960s. Initially,
software development was a purely technical process, and there was no standardization
in terms of development methodologies or programming languages. However, as
software systems grew more complex, the need for formalized approaches to software
development became evident. This led to the development of various software
engineering methodologies, such as the Waterfall model, the Spiral model, and the
Agile model.
Evolution of Software Engineering:

1. Early Years (1940s-1950s): During this period, computers were primarily used for
scientific and military purposes. Software development was mostly done by engineers
who worked on hardware and wrote programs in low-level assembly languages.

2. Batch Processing (1960s): The development of high-level programming languages,

such as FORTRAN and COBOL, made it easier to write software and enabled the
creation of large-scale business applications. The introduction of batch processing,
which allowed multiple jobs to be executed in sequence, helped to automate many
business processes.

3. Interactive Computing (1970s): The development of time-sharing systems, which

allowed multiple users to access a computer system simultaneously, and the creation of
the first personal computers enabled the growth of interactive computing. This led to the
development of new software applications, such as word processors and spreadsheet
programs.

4. Client-Server Computing (1980s): The widespread adoption of personal computers

and local area networks (LANs) led to the growth of client-server computing. This
model enabled multiple users to access a shared database or application from their own
computers, and it paved the way for the development of client-server architectures and
distributed systems.

5. Web-based Computing (1990s): The invention of the World Wide Web and the
growth of the internet transformed the software industry. The web enabled the creation
of new software applications, such as e-commerce websites, and it paved the way for
the development of cloud computing and software-as-a-service (SaaS) models.

6. Mobile Computing (2000s-2010s): The proliferation of smartphones and mobile

devices has had a major impact on software engineering. Developers have had to adapt

3
their software to work on smaller screens and to take advantage of mobile-specific
features, such as GPS and touch screens. This has led to the development of mobile
apps and the growth of the app store ecosystem.

Impact of Software Engineering:

The impact of software engineering has been significant. It has transformed the way
businesses operate and has led to the creation of new industries, such as software-as-a-
service (SaaS) and mobile applications. Software engineering has also led to the
automation of many processes, resulting in increased efficiency and productivity. In
addition, software engineering has enabled the creation of new technologies, such as
artificial intelligence, machine learning, and block-chain.
One of the most significant impacts of software engineering has been its contribution to
the growth of the internet. Without software engineering, the internet as we know it
today would not exist. The development of web browsers, search engines, social media
platforms, and e-commerce websites are all products of software engineering. These
technologies have transformed the way we communicate, work, and access information.

However, software engineering also has some negative impacts. The development of
software systems can be costly, and many projects fail due to budget overruns or
technical issues. In addition, the rapid pace of software development can lead to security
vulnerabilities, which can be exploited by cybercriminals. This has resulted in increased
concerns about data privacy and cybersecurity.

The impact of software engineering has been enormous. Software is now an essential
part of virtually every aspect of modern life, from communication and entertainment to
finance and healthcare. Software engineering has made it possible to create complex
and powerful software applications that can process vast amounts of data, automate
business processes, and improve decision-making. At the same time, software
engineering has also introduced new challenges, such as security and privacy concerns,
software complexity, and the need to continuously update and maintain software
applications.

Introduction: The notion of software engineering was first proposed in 1968 at a

conference held to discuss what was called “software crisis”.

“Software Engineering – Application of a systematic and disciplined approach to

the development, operation and maintenance of software.
Or
“Software Engineering “is the science and art of building significant software
systems, depends on
• Time
• Budget
• Acceptable performance
4
• Correct operation.

Software : It is the collection of computer programs, rules and associated documents

and data.

There are two types of software’s :-

1) System software: software designed to operate the computer hardware and to

provide a platform for running application system software.

Eg: O.S, translator s/w(compiler, assembler, interpreter..)

2) Application software: it is a set of programs that help to solve particular problem

of the user.

Eg: Airline Reservation, Railway Reservation, satellite tracking….

Software Engineering: [Definition given by IEEE] : The application of a systematic,

disciplined, quantifiable approach to the development, operation , maintenance of a
software by applying engineering techniques.

Goals of software Engineering

1) Improve the quality of s/w products.

2) To increase productivity.
3) To get the ability to develop and maintain a software.
4) Job satisfaction to s/w engineers.

Characteristic of software

1. Maintainability: It should be possible for the software to meet the

changing requirements.
2. Dependability: As a range of characteristics, it must include reliability, security
and safety. security and safety dependable s/w does not cause any damage in the
event of system failure
3. Efficiency: It should not make any wasteful use of system resource such as
memory, processing time.
4. Usability: It must be easy to use for customers or user. Easy description how
to install and use the system.

Software products: These are software systems that are delivered to a customer with
documentation which describe how to install and use the system.

There are two types of software products available they are:

5
 1. Generic Products: These are stand alone systems which are produced to sell in
open market to any customer. The requirements and specification are controlled
by the developer.
Generic s/w is also called commercial-off-the-self (COTS) s/w.
Ex: Word processor, Drawing packages.

2. Customized (Bespoke)products: This type of s/w is developed to meet the

requirement of a specific user or a group of user. The requirements and
specification are controlled by the customer.
Ex: Hospital management, Railway reservations…

Software process: A set of activities and associated result which produce a s/w product.

Fundamental activities in all software processes are:

(1)Software Specification: Specification process involves defining s/w to be

produced and there constraints. Designer must collect all the required specification
before starting the development activities.

(2)Software Development: It involves team of profession with innovation idea that

helps to develop and design the s/w specified by the user.

(3)Software validation: S/w is validated after matching requirement of the customer

with the s/w developed. It is the process of checking the s/w

(4)Software evolution: S/w is modified to adopt changing customer and market

requirement.

Characteristics of s/w process

1) Understandability
2) Visibility
3) Supportability
4) Acceptability
5) Reliability
6) Maintainability

6
Software Engineering Challenges:

1. Heterogeneity challenge: Many of the s/w product will always have

heterogeneity, meaning varied requirements such as different types of computers
and specifications.
“The challenge is to develop s/w which can automatically to adjust(flexible)
with heterogeneous systems”.
2. Delivery challenge: s/w project development is time consuming as it has to be
manufactured and must maintain quality. ”Delivering the s/w to the customer
on-time is a real challenge”.
3. Trust challenge: Maintaining the trust is very important. Many times s/w is
accessed through web. The developer must develop the s/w such that they trust
the product.” The s/w engineers must develop trustworthy s/w”.

Components of Software Engineering:

1. Software Development Life Cycle.

It identifies various stages and activities associated with development of software.

2. Software quality assurance:

It is the process of ensuring users satisfaction through developing a quality product.

3. Software Project Management:

It is the application of principles project management to process of
software development.

4. Software Management:
These are the methods and procedures to be followed for effective
software maintenance.

5. CASE: (Computer Aided Software engineering)

They are set of automated tools that support the process of software development.

7
Software Development Life cycle[SDLC]:

In SDLC each phase of the software development take the input of previous phase
result.

1. Requirement Analysis & Specification:

Here, we collect functional & non- functional requirements of the proposed system
from the customer. Functional requirements describe the system software’s processing &
input /output needs. Non –functional describe about machine in terms of its size &
capacity.

2. System & Software Design:

In this stage, the designers produce a system architecture i.e. description of
hardware & software systems. The software designers design Units/Models/Subroutines.

The output of this phase is description of program units written in a formal

language which is given to programmer for translation.

3. Coding and Unit testing:

The designed module is given to the purpose of coding. In this stage, each unit is
coded using a programming language and tested for its proper working.

4. Implementation & Integration of S/W Units:

The design is translated to program units. These units are tested individually to
ensure that it matches design & its requirement specification. The common errors are
typing mistakes, statement omission. Then the units are integrated in a pre-defined way
such as top-down or bottom-up to form a system.

8
5. Software Operation & Maintenance:
This phase describes modification to the system developed while operation.
Corrective maintenance defines modification as a result of error discover. It includes
improvements update to the new version and making the system error free.

Types of SDLC Models

1) Water fall model

2) Prototype model
3) Rapid application model
4) Evolutionary model
5) Incremental model
6) Iterative Model
7) Component based software engineering model
8) Spiral model.
WATER FALL MODEL
It is a software life cycle developed by W.W.Royce in 1970 in which the development is
supposed to proceed linearly through the phases of requirement analysis, design,
implementation, testing, integration and maintenance.

The water fall model is also referred as linear sequential model or classical life cycle
model.
1. Requirement definition
All possible requirement of a system to be developed are captured in this phase and also
requirement specification document is created which serves as a guideline for the next
phases of the model.
2. System and software design
It is highly important to understand the requirements of the user how should end
product look like. System design helps in specifying hardware and system requirements
and also defining system architecture.
9
 3. Implementation and unit testing:
The system is first developed and the work is divided into modules or units. Each unit is
developed and tested for its functionality and this is referred as unit testing. It mainly
verifies whether all the modules are working properly or not.
4. Integration and system testing.
The units are integrated into a complete system during integration phase and tested to
check all the modules are co-ordinating with each other.
5. Operation and maintenance
This phase is a never ending phase generally problem arises after its practical use only,
so the maintenance of the system comes into picture directly when it is used. Hence this
phase is referred to as Maintenance.

Advantages:
1) It is very easy to understand
2) Widely used in many development areas
3) Identifies the milestones of the software development.
4) There is a clear compartment regarding work and control of the model.
5) It is the model as defined before design and design before code.
6) This model is the easiest to implement in the eyes of the managers.

Disadvantages:
1) Difficult and expensive to make changes to document in the middle of the process.
2) Significant administration is required.
3) Software is delivered late in project.
4) Unrealistic to expect to accurate requirements in the starting phase.

Where it is applicable?
This model is applicable only when all the requirements are well defined and
understood.

SPIRAL MODEL
The spiral model was proposed by “Barry Boehm” in 1986, it combines the best features
of water fall model and prototype model. The Spiral Model is a risk-driven model,
meaning that the focus is on managing risk through multiple iterations of the software
development process. Each loop represents a phase of the s/w development process. The
exact number of loops of the spiral is unknown and can vary from project to project. The
inner most loop is concerned with the system analysis and system feasibility and the next
loop with requirement definition. The next loop with system design and so on. Each phase
of the Spiral Model is divided into four quadrants as shown in the figure below. The
functions of these four quadrants are:

1. Objectives determination and identify alternative solutions: Requirements are

gathered from the customers and the objectives are identified, elaborated, and analysed
at the start of every phase. Then alternative solutions possible for the phase are
proposed in this quadrant.
10
2. Identify and resolve Risks: During the second quadrant, all the possible
solutions are evaluated to select the best possible solution. Then the risks associated
with that solution are identified and the risks are resolved using the best possible
strategy. At the end of this quadrant, the Prototype is built for the best possible
solution.

3. Develop next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third quadrant,
the next version of the software is available.

4. Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning for the
next phase is started.

Advantages:
• The high amount of risk analysis.
• Good for large and mission critical projects.
• Project monitoring is very easy because of transparency in the model.
• It is suitable for high risk projects where business needs are high.
• A highly customized product can be developed using this model.
Disadvantages:
• Cost involve is usually high.
• Doesn’t work for smaller project.
• Required for evaluating & reviewing the project time to time
11
 • Risk analysis required highly specific experts.
• Scheduling requirement are very much tough.

INCREMENTAL MODEL

Incremental Model is a process of software development where requirements are

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

The various phases of incremental model are as follows:

1. Requirement analysis: In the first phase of the incremental model, the product
analysis expertise identifies the requirements. The system functional requirements are
understood by the requirement analysis team. To develop the software under the
incremental model, this phase performs a crucial role.
2. Design & Development: In this phase of the Incremental model of SDLC, the design
of the system functionality and the development method are finished with success.
When software develops new practicality, the incremental model uses style and
development phase.
3. Testing: In the incremental model, the testing phase checks the performance of each
existing function as well as additional functionality. In the testing phase, the various
methods are used to test the behavior of each task.
4. Implementation: Implementation phase enables the coding phase of the
development system. It involves the final coding that design in the designing and
development phase and tests the functionality in the testing phase. After completion of
this phase, the number of the product working is enhanced and upgraded up to the final
system product.

When do we use the Incremental Model?

12
 1. When the requirements are superior.
2. A project has a lengthy development schedule.
3. When Software team are not very well skilled or trained.
4. When the customer demands a quick release of the product.
5. You can develop prioritized requirements first.

Advantages of Incremental Model

1. Errors are easy to be recognised.
2. Easier to test and debug.
3. More flexible.
4. Simple to manage risk because it handled during its iteration.
5. The Client gets important functionality early.

Disadvantages of Incremental Model

1. Need for good planning
2. Total Cost is high.
3. Well defined module interfaces are needed.

ITERATIVE MODEL

In this Model, we 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.
The Iterative Model allows the accessing earlier phases, in which the variations are
made respectively. The final output of the project is renewed at the end of the Software
Development Life Cycle (SDLC) process.

13
The various phases of Iterative model are as follows:
1. Requirement gathering & analysis: In this phase, requirements are gathered from
customers and checked by an analyst whether requirements will fulfil or not. Analyst
checks whether the need will be achieved within budget or not. After all of this, the
software team skips to the next phase.
2. Design: In the design phase, team will design the software by the different diagrams
like Data Flow diagram, activity diagram, class diagram, state transition diagram, etc.
3. Implementation: In the implementation, requirements are written in the coding
language and transformed into computer programmes which are called Software.
4. Testing: After completing the coding phase, software testing starts using different
test methods. There are many test methods, but the most common are white box and
black box testing methods.
5. Deployment: After completing all the phases, software is deployed to its work
environment.
6. Review: In this phase, after the product deployment, review phase is performed to
check the behaviour and validity of the developed product. And if there are any errors
found, then the process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in the
working environment there may be some bugs, some errors or new updates are required.
Maintenance involves debugging and new addition options.

When to use the Iterative Model?

1. When requirements are defined clearly and easy to understand.
2. When the software application is large.
3. When there is a requirement for changes in future.

Advantages:
1. Testing and debugging during smaller iteration is easy.
14
 2. A Parallel development can plan.
3. It is easily acceptable to ever-changing needs of the project.
4. Risks are identified and resolved during iteration.
5. Limited time spent on documentation and extra time on designing.

Disadvantages:
1. It is not suitable for smaller projects.
2. More Resources may be required.
3. Design can be changed again and again because of imperfect requirements.
4. Requirement changes can cause over budget.
5. Project completion date not confirmed because of changing requirements.

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 working
model 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 the software
product. In such a scenario where there is an absence of detailed information regarding
the input to the system, the processing needs and the output requirement, the
prototyping model may be employed.

15
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision
3. Build a Prototype
4. Assessment or User Evaluation
5. Prototype Refinement
6. Engineer Product

Advantages of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted
3. Regular visible process aids management
4. Support early product marketing
5. Reduce Maintenance cost.
6. Errors can be detected much earlier as the system is made side by side.

Disadvantages of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration

• Costs customer money

• Needs committed customer
• Difficult to finish if customer withdraw
• May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper requirement analysis, design,
customer evaluation, and feedback.
5. Prototyping tools are expensive.
6. Special tools & techniques are required to build a prototype.
7. It is a time-consuming process.

EVOLUTIONARY MODEL
Evolutionary model is a combination of Iterative and Incremental model of software
development life cycle. Delivering your system in a big bang release, delivering it in
incremental process over time is the action done in this model. Some initial requirements

16
and architecture envisioning need to be done. It is better for software products that have
their feature sets redefined during development because of user feedback and other
factors. The Evolutionary development model divides the development cycle into smaller,
incremental waterfall models in which users are able to get access to the product at the
end of each cycle. Feedback is provided by the users on the product for the planning stage
of the next cycle and the development team responds, often by changing the product, plan
or process. Therefore, the software product evolves with time. All the models have the
disadvantage that the duration of time from start of the project to the delivery time of a
solution is very high. Evolutionary model solves this problem in a different approach.

Evolutionary model suggests breaking down of work into smaller units, prioritizing
them and then delivering those units to the customer one by one. The number of units is
huge and is the number of deliveries made to the customer. The main advantage is that
the customer’s confidence increases as he constantly gets quantifiable goods or services
from the beginning of the project to verify and validate his requirements. This model
allows for changing requirements as well as all work is broken down into maintainable
work units.
Application of Evolutionary Model:
1. It is used in large projects where you can easily find modules for incremental
implementation.
2. Evolutionary model is commonly used when the customer wants to start using the
core features instead of waiting for the full software.
3. Evolutionary model is also used in object oriented software development because
the system can be easily portioned into units in terms of objects.
Necessary conditions for implementing this model:
1. Customer needs are clear and been explained in deep to the developer team.
2. There might be small changes required in separate parts but not a major change.
3. As it requires time, so there must be some time left for the market constraints.
17
 4. Risk is high and continuous targets to achieve and report to customer repeatedly.
5. It is used when working on a technology is new and requires time to learn.
Advantages:
1. In evolutionary model, a user gets a chance to experiment partially developed
system.
2. It reduces the error because the core modules get tested thoroughly.
Disadvantages:
1. Sometimes it is hard to divide the problem into several versions that would be
acceptable to the customer which can be incrementally implemented and
delivered.
FEASIBILITY STUDY
Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed
project or system. Feasibility study is one of the stages among important four stages of
Software Project Management Process. As name suggests feasibility study is the
feasibility analysis or it is a measure of the software product in terms of how much
beneficial product development will be for the organization in a practical point of view.
Feasibility study is carried out based on many purposes to analyse whether software
product will be right in terms of development, implementation, contribution of project
to the organization etc.

Types of Feasibility Study:

The feasibility study mainly concentrates on below five mentioned areas. Among
these, Economic Feasibility Study is most important part of the feasibility analysis and
Legal Feasibility Study is less considered feasibility analysis.

1. Technical Feasibility – In Technical Feasibility, the current resources both

hardware and software along with required technology are analysed/assessed to
develop project. This technical feasibility study gives report whether there exists
correct required resources and technologies which will be used for project
development. Along with this, feasibility study also analyses technical skills and
capabilities of technical team, existing technology can be used or not,
maintenance and up-gradation is easy or not for chosen technology etc.
2. Operational Feasibility – In Operational Feasibility, degree of providing service
to requirements is analysed along with how much easy product will be to operate
and maintain after deployment. Along with this, other operational scopes are
determining usability of product, determining suggested solution by software
development team is acceptable or not etc.
3. Economic Feasibility – In Economic Feasibility, study cost and benefit of the
project is analysed. Means under this feasibility study a detail analysis is carried
out what will be cost of the project for development which includes all required
cost for final development like hardware and software resource required, design
and development cost and operational cost and so on. After that it is analysed
whether project will be beneficial in terms of finance for organization or not.
4. Legal Feasibility – In Legal Feasibility, study project is analysed in legality
point of view. This includes analysing barriers of legal implementation of project,
data protection acts or social media laws, project certificate, license, copyright
18
 etc. Overall it can be said that Legal Feasibility Study is study to know if
proposed project conform legal and ethical requirements.
5. Schedule Feasibility – In Schedule Feasibility Study mainly timelines/deadlines
is analysed for proposed project which includes how many times teams will take
to complete final project which has a great impact on the organization as purpose
of project may fail if it can’t be completed on time.

Aim of feasibility study:

1. The overall objective of the organization are covered and contributed by the
system or not.
2. The implementation of the system be done using current technology or not.
3. Can the system be integrated with the other systems which already exists.

Feasibility Study Process:

The below steps are carried out during entire feasibility analysis.
1. Information assessment
2. Information collection
3. Report writing
4. General information

Need of Feasibility Study:

Feasibility study is so important stage of Software Project Management Process
as after completion of feasibility study it gives a conclusion of whether to go ahead with
proposed project as it is practically feasible or to stop proposed project here, as it is not
right/feasible to develop or to think/analyse about proposed project again.

Along with this, Feasibility study helps in identifying risk factors involved in
developing and deploying system and planning for risk analysis also narrows the
business alternatives and enhance success rate analysing different parameters associated
with proposed project development.

REQUIREMENTS ANALYSIS
Requirements analysis is a very critical process that enables the success of a
system or software project to be assessed. Requirements are generally split into
two types:
1. Functional requirements
2. Non-functional requirements

1. Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer. All these
functionalities need to be necessarily incorporated into the system as a part of the
contract. These are represented or stated in the form of input to be given to the
system, the operation performed and the output expected. They are basically the
requirements stated by the user which one can see directly in the final product,
unlike the non-functional requirements.

19
 2. Non-functional requirements: These are basically the quality constraints that
the system must satisfy according to the project contract. The priority or extent to
which these factors are implemented varies from one project to other. They are
also called non-behavioural requirements.
They basically deal with issues like:
➢ Portability
➢ Security
➢ Maintainability
➢ Reliability
➢ Scalability
➢ Performance
➢ Reusability
➢ Flexibility

Following are the differences between Functional and Non-functional requirements

Functional Requirements Non Functional Requirements

A functional requirement defines a A non-functional requirement
system or its component. defines the quality attribute of a
software system.
It specifies “What should the It places constraints on “How should
software system do?” the software system fulfill the
functional requirements?”
Functional requirement is specified Non-functional requirement is
by User. specified by technical peoples e.g.
Architect, Technical leaders and
software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of Helps you to verify the performance
the software. of the software.
Functional Testing like System, Non-Functional Testing like
Integration, End to End, API testing, Performance, Stress, Usability,
etc are done. Security testing, etc are done.
Usually easy to define. Usually more difficult to define.
Example Example
1) Authentication of user whenever 1) Emails should be sent with a
he/she logs into the system. latency of no greater than 12 hours
2) System shutdown in case of a from such an activity.
cyber-attack. 2) The processing of each request
3) A Verification email is sent to should be done within 10 seconds
user whenever he/she registers for 3) The site should load in 3 seconds
the first time on some software when the number of simultaneous
system. users are > 10000

20
 REQUIREMENTS GATHERING

Definition: Requirements gathering is the process of identifying project's

exact requirements from start phase to finish phase. This process occurs during the
project initiation phase but will continue to manage project requirements throughout the
entire project timeline.
Requirements elicitation (also known as Requirements Gathering or
Capture) is the process of generating a list of requirements (functional, system,
technical, etc.) from the various stakeholders (customers, users, vendors, IT staff, etc.)

A 6-Step Requirements Gathering Process

1. Identify the relevant stakeholders.
2. Establish project goals and objectives.
3. Elicit requirements from stakeholders.
4. Document the requirements.
5. Confirm the requirements.
6. Prioritize the requirements.

There are two main types of project requirements:

a) Business requirements define what an organization will accomplish with the

project.
b) Technical requirements explain how the project must be executed. They’re gathered
during the initiation phase of the project life cycle, but project managers need to
monitor them throughout the project timeline, as they can change.

Requirements Gathering Process

Requirements gathering is made up of a few discrete steps.

1. Appoint and Assign

First thing: who’s going to be the person that tells everyone you’re the project manager?
Ensure that that person understands why this role is so important—everyone must go to
you with all project updates, as you will act as the knowledge centre for project
progress.

You should identify who the key stakeholders will be. These will be the people who
brainstorm, analyse, approve or deny project updates. They’re typically made up of
customers, team leads, department managers, board members, business partners or
manufacturers. They’ll have the most stay in the progress of the project overall.

2. Elicit Requirements & Interview

Next, you’ll want to interview all of the stakeholders that you identified. Ask them
questions like:

• What is on your wish list for this product update?

• What is your ultimate goal for this project?
21
 • What do you wish this product would do that it doesn’t already?
• What got you interested in this product in the first place?
• What changes would convince you to recommend this product to others?
• What tools would you need to make this project successful?
• What are the concerns you have for this project process?

3. Gather and Document

Write absolutely everything down. Write until you can’t write anymore. Record every
single answer, and create an easily-accessible repository where (approved) others can
access if they need to reference any information that was collected during the
requirements gathering phase.

Not only will this documentation be helpful at the end of the project when you reflect
back on goals achieved, updates accomplished, features added and bugs fixed, but it will
also act to help manage stakeholder expectations, and keep team members focused and
on track.

4. List All Assumptions & Requirements

This is the meat of the process. Once you’ve documented everyone’s goals and
expectations, you can create a requirements management plan that’s actionable,
measurable and quantifiable.

During this phase you’ll answer:

• How long will the project timeline be? Map out your timeline, and then map out
your requirements on that timeline. This will help in case some requirements are
contingent on dependencies.
• Who will be involved in the project? Will it be the entire design and development
teams, or just a select few from each? Which team members will be available?
Which team members specialize in the types of issues the project will tackle?
• What are the risks for the requirements-gathering process? Define all
assumptions, and document all risks that might impact your requirements.
Understand that your assumptions are typically divided into three categories:
time, budget and scope. They can range from assuming PTO, holidays and sick
days, to assuming stakeholders will provide feedback in a timely manner.
• What is our ultimate goal in understanding our project requirements? What is the
time-based goal, the budget goal and the scope goal? Will it be to compete in the
market more directly with a competitor? Will it be to solve a customer problem,
or fix a bug?
• By answering all of the questions above in a clear and concise manner, you’ll
have a full map of your requirements ready to present to stakeholders.

5. Monitor Progress
Once you’ve got an stakeholder approval on the requirements you’ve presented, you’ll
implement them into the project timeline and process. At this point, you’ll want to make

22
sure you have a method in place to monitor and track all of your requirements across all
teams to ensure that triggers for risk stay low.

You’ll also want to use this data to report project progress to stakeholders, give
feedback to department managers, and ensure the project is on track from a time, scope
and budget standpoint. Our free requirements traceability matrix is a great tool to keep
track of project requirements.

REQUIREMENTS ANALYSIS AND SPECIFICATION

SOFTWARE REQUIREMENTS
The process of establishing the services that the customer requires from a system and
the constraints under which it operates and is developed.
Requirements may be functional or non-functional
• Functional requirements describe system services or functions
• Non-functional requirements is a constraint on the system or on the development
process.
Types of requirements
1. User requirements: Statements in natural language (NL) plus diagrams of the
services the system provides and its operational constraints written for customers.
2. System requirements: A structured document setting out detailed descriptions of
the system services. Written as a contract between client and contractor.
3. Software specification: A detailed software description which can serve as a
basis for a design or implementation. Written for developers.
FUNCTIONAL AND NON-FUNCTIONAL COMPONENTS:
a) Functional requirements:
• Functionality or services that the system is expected to provide.
• Functional requirements may also explicitly state what the system shouldn‘t do.
• Functional requirements specification should be:
➢ Complete: All services required by the user should be defined
➢ Consistent: should not have contradictory definition (also avoid ambiguity
don‘t leave room for different interpretations)
Examples:
• The LIBSYS system
• A library system that provides a single interface to a number of databases of
articles in different libraries.
• Users can search for, download and print these articles for personal study.
• The user shall be able to search either all of the initial set of databases or select a
subset from it.

23
 • The system shall provide appropriate viewers for the user to read documents in
the document store.
• Every order shall be allocated a unique identifier (ORDER_ID) which the user
shall be able to copy to the account‘s permanent storage area.

b) Non-Functional requirements:
Requirements that are not directly concerned with the specific functions delivered by
the system. Typically, relate to the system as a whole rather than the individual
system features.
Often could be deciding factor on the survival of the system (e.g. reliability, cost,
response time)
Non-Functional requirements classifications:

We can see from this diagram that the non-functional requirements may come from
required characteristics of the software (product requirements), the organization
developing the software (organizational requirements) or from external sources.
The types of non-functional requirements are:
i) Product requirements:
• Specify the desired characteristics that a system or subsystem must possess.
• Most NFRs are concerned with specifying constraints on the behavior of the
executing system.
• Performance
• Capacity
• Others are more difficult to quantify and, consequently, are often stated informal.
• Usability

24
ii) Organisational requirements
Process requirements are constraints placed upon the development process of the
system. Process requirements include:
• Requirements on development standards and methods which must be followed
• CASE tools which should be used
• The management reports which must be provided
Examples of process requirements
• The development process to be used must be explicitly defined and must be
conformant with ISO 9000 standards
• The system must be developed using the XYZ suite of CASE tools
• Management reports setting out the effort expended on each identified system
component must be produced every two weeks
• A disaster recovery plan for the system development must be specified
iii) External requirements: May be placed on both the product and the process.
Derived from the environment in which the system is developed.
External requirements are based on:
• Application domain information
• Organizational considerations.
• The need for the system to work with other systems Health and safety or data
protection regulations
• Or even basic natural laws such as the laws of physics.
Examples of external requirements
Medical data system: The organization’s data protection officer must certify that all data
is maintained according to data protection legislation before the system is put into
operation.
Train protection system: The time required to bring the train to a complete halt is
computed using the function.
USER REQUIREMENT: The user requirement(s) document (URD) or user
requirement(s) specification is a document usually used in software engineering that
specifies the requirements the user expects from software to be constructed in a
software project.
Once the required information is completely gathered it is documented in a URD, which
is meant to spell out exactly what the software must do and becomes part of the
contractual agreement.
A customer cannot demand features not in the URD, while the developer cannot claim
the product is ready if it does not meet an item of the URD.

25
The URD can be used as a guide to planning cost, timetables, milestones, testing, etc.
The explicit nature of the URD allows customers to show it to various stakeholders to
make sure all necessary features are described.
Formulating a URD requires negotiation to determine what is technically and
economically feasible.
Preparing a URD is one of those skills that lies between a science and an art, requiring
both software technical skills and interpersonal skills.
Often a URD includes priority ranking for each requirement. A typical system might be
as follows:
• M Mandatory requirement. This feature must be built into the final system.
• D Desirable requirement. This feature should be built into the final system unless
the cost is too high.
• O Optional requirement.
• E Possible future enhancement.
SYSTEM REQUIREMENTS
SRS (Software Requirement Specification): It is a document that
outlines the requirements for a software project. It describes the
software’s functionality, performance and design.
Purpose of SRS: Official statement of what is required by the system developer. It
should include user requirements and specification of system requirements. It should
describe what the system should do.
Ways of writing an SRS:
1. Natural Language
2. Structured Natural Language
3. Design Description Language
4. Graphical Notations
5. Mathematical specification
Guidelines for Writing SRS:
1. Use standard formats
2. Use “shall” for mandatory requirements and “should” for desirable requirements.
3. Use text highlighting to identify key parts of requirements.
4. Include rationale of why a requirement is necessary

To be used efficiently, all computer software needs certain hardware components or

other software resources to be present on a computer.
26
Most software defines two sets of system requirements: minimum and recommended.
With increasing demand for higher processing power and resources in newer versions of
software, system requirements tend to increase over time. Industry analysts suggest that
this trend plays a bigger part in driving upgrades to existing computer systems than
technological advancements.
A second meaning of the term of System requirements is a generalization of this first
definition, giving the requirements to be met in the design of a system or sub-system.
Typically an organization starts with a set of Business requirements and then derives the
System requirements from there.

SOFTWARE REQUIREMENT DOCUMENT

• Should provide for communication among team members
• Should act as an information repository to be used by maintenance engineers
• Should provide enough information to management to allow them to perform all
program management related activities
• Should describe to users how to operate and administer the system.
• Specify external system behaviour
• Specify implementation constraints
• Easy to change
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the system i.e. predict changes
characterize responses to unexpected events.

27
Qualities / Characteristics of SRS:

1. Correctness: User review is used to provide the accuracy of requirements stated in

the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from
the system.
2. Completeness: The SRS is complete if, and only if, it includes the following
elements:
(a). All essential requirements, whether relating to functionality, performance, design,
constraints, attributes, or external interfaces.
(b). Definition of their responses of the software to all realizable classes of input data in
all available categories of situations.
(c). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.
3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in the
SRS:
(1). The specified characteristics of real-world objects may conflict.
For example,
(a) The format of an output report may be described in one requirement as tabular but in
another as textual.
(b) One condition may state that all lights shall be green while another states that all
lights shall be blue.

28
(2). There may be a reasonable or temporal conflict between the two specified actions.
For example,
(a) One requirement may determine that the program will add two inputs, and another
may determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other requires that
"A and B" co-occurs.
(3). Two or more requirements may define the same real-world object but use different
terms for that object. For example, a program's request for user input may be called a
"prompt" in one requirement's and a "cue" in another. The use of standard terminology
and descriptions promotes consistency.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements report should determine the
implications in the SRS so that it is clear and simple to understand.
5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the significance or
stability of that particular requirement.
Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable. Each
element should be identified to make these differences clear and explicit. Another way
to rank requirements is to distinguish classes of items as essential, conditional, and
optional.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of
quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.
7. Verifiability: SRS is correct when the specified requirements can be verified with a
cost-effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear
and if it facilitates the referencing of each condition in future development or
enhancement documentation.
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,
29
it is necessary to be able to ascertain the complete set of requirements that may be
concerned by those modifications.
9. Design Independence: There should be an option to select from multiple design
alternatives for the final system. More specifically, the SRS should not contain any
implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate
test cases and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal
notations and symbols should be avoided to as much extent as possible. The language
should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage, the
details should be explained explicitly. Whereas, for a feasibility study, fewer analysis
can be used. Hence, the level of abstraction modifies according to the objective of the
SRS.
IEEE suggests the following structure for requirements document
1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements cover functional, non-functional and interface
requirements.
i) This is obviously the most substantial part of the document but because of the
wide variability in organizational practice, it is not appropriate to define standard
structure for this section.

30
ii) The requirements may document external interfaces, describe system
functionality and performance, specify logical database requirements, design
constraints, emergent system properties and quality characteristics.
4. Appendices
5. Index

31
 AGILE DEVELOPMENT

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. The
project scope and requirements are laid down at the beginning of the development
process. Plans regarding the number of iterations, the duration and the scope of each
iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which
typically lasts from one to four weeks. The division of the entire project into smaller
parts helps to minimize the project risk and to reduce the overall project delivery time
requirements. Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis, design, coding, and
testing before a working product is demonstrated to the client.

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

1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build the
project. Based on this information, you can evaluate technical and economic feasibility.
2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-
32
level UML diagram to show the work of new features and show how it will apply to the
existing system.
3. Construction / Iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a
working product. The product will undergo various stages of improvement, so it
includes simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work
environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

AGILITY:
Agility has become today’s buzzword when describing a contemporary software
method. Everyone is agile. An associate agile team could be a quick team able to
befittingly reply to changes. modification is what software development is extremely
abundant.

➢ Changes within the software being engineered,

➢ Changes to the team members,
➢ Changes attributable to new technology,
➢ Changes of all types that will have an effect on the merchandise they build or the
project that makes the merchandise.

All changes can be represented as shown in the below diagram which is considered
according to Ivar Jacobson Agility process of Software.

Support for changes ought to be inherent everything we tend to kill software, one thing
we tend to embrace as a result of it’s the guts and soul of software. Associate in agile
team acknowledges that software is developed by people operating in groups which the
talents of those folks, their ability to collaborate is at the core for the success of the
project.

In Jacobson’s read, the generality of modification is that the primary driver for agility.
Software engineers should be fast on their feet if they’re to accommodate the speedy
changes that Jacobson describes. But agility is over an efficient response to alter.

33
 1. It encourages team structures and attitudes that create communication (among
team members, between technologists and business folks, between software
engineers and their managers) additional facile.
2. It emphasizes speedy delivery of operational software Associate in emphasizes
the importance of intermediate work merchandise (not continuously a decent
thing);
3. It adopts the client as a vicinity of the event team and works to eliminate the “us
and them” angle that continues to perforate several software projects;
4. It acknowledges that coming up within an unsure world has its limits which a
project arrange should be versatile.

Agility is applied to any software method. However, to accomplish this, it’s essential
that the method be designed during a manner that enables the project team to adapt tasks
and to contour them, conduct coming up within a good manner that understands the
fluidity of an agile development approach, eliminate about the foremost essential work
products and keeps them lean, Associate in emphasize a progressive delivery strategy
that gets operating package to the client as apace as possible for the merchandise sort
and operational atmosphere.

Agility and Cost of Change in Software Engineering

An agile process reduces the agility and cost of change because software is released in
increments and change can be better controlled within an increment.

Agility argue that a well designed agile process “flattens” the cost of change curve
shown in following figure, allowing a software team to accommodate changes late in a
software project without dramatic cost and time impact.

When incremental delivery is coupled with other agile practices such as continuous unit
testing and pair programming, the cost of making a change is reduced.

Although debate about the degree to which the cost curve flattens is ongoing, there is
evidence to suggest that a significant reduction in the cost of change can be achieved.

AGILE PROCESS: Agile is a software development methodology that emphasizes

flexibility, collaboration, and customer satisfaction. The Agile process is iterative and
34
incremental, with small, cross-functional teams working in short time-boxed periods
called sprints or iterations. The Agile approach encourages frequent feedback,
adaptation, and continuous improvement throughout the development process.

Characteristics of Agile process are –

1. Agile processes must be adaptable to technical and environmental changes. That

means if any technological changes occur, then the agile process must accommodate it.
2. The development of agile processes must be incremental. That means, in each
development the increment should contain some functionality that can be tested and
verified by customer.
3. The customer feedback must be used to create the next increment of the process.
4. The software increment must be delivered in short span of time.
5. It must be iterative, so that each increment can be evaluated regularly.

The Agile process consists of several key practices and principles, including:

1. User Stories: Agile teams create user stories to capture the needs and
requirements of the end-users. User stories are short, simple descriptions of a
feature or functionality that a user needs to accomplish a specific task.

2. Iterative Development: The Agile process is based on iterative and incremental

development, with each iteration building upon the work of the previous one. At
the end of each iteration, the team delivers a potentially shippable product
increment.

3. Prioritization: Agile teams prioritize their work based on business value and
customer needs. The most important features and functionality are developed
first, ensuring that the team delivers the highest value to the customer.

4. Continuous Integration and Delivery: Agile teams use continuous integration

and delivery to ensure that the code is always in a releasable state. This means
that the team can release new features and functionality to customers quickly and
frequently.

5. Cross-Functional Teams: Agile teams are cross-functional, meaning that they

include members with different skills and expertise. This allows the team to
collaborate effectively and deliver high-quality software.

6. Retrospectives: Agile teams regularly hold retrospectives to reflect on their work

and identify opportunities for improvement. This helps the team continuously
improve their processes and deliver better software.

Overall, the Agile process is designed to be flexible and adaptable, allowing teams to
respond quickly to changing requirements and deliver software that meets the needs of
the customer.
35
Advantages:

1. Working through Pair programming produces well-written compact programs

which have fewer errors as compared to programmers working alone.
2. It reduces the total development time of the whole project.
3. Agile development emphasizes face-to-face communication among team
members, leading to better collaboration and understanding of project goals.
4. Customer representatives get the idea of updated software products after each
iteration. So, it is easy for him to change any requirement if needed.
5. Agile development puts the customer at the center of the development process,
ensuring that the end product meets their needs.

Disadvantages:

1. The lack of formal documents creates confusion and important decisions taken
during different phases can be misinterpreted at any time by different team
members.
2. Agile development models often involve working in short sprints, which can
make it difficult to plan and forecast project timelines and deliverables. This can
lead to delays in the project and can make it difficult to accurately estimate the
costs and resources needed for the project.
3. Agile development models require a high degree of expertise from team
members, as they need to be able to adapt to changing requirements and work in
an iterative environment. This can be challenging for teams that are not
experienced in agile development practices and can lead to delays and difficulties
in the project.
4. Due to the absence of proper documentation, when the project completes and the
developers are assigned to another project, maintenance of the developed project
can become a problem.

Extreme programming (XP)

Extreme programming (XP) is one of the most important software development
frameworks of Agile models. It is used to improve software quality and responsiveness
to customer requirements. The extreme programming model recommends taking the
best practices that have worked well in the past in program development projects to
extreme levels.

Good practices need to be practiced in extreme programming: Some of the good

practices that have been recognized in the extreme programming model and suggested
to maximize their use are given below:

1. Code Review: Code review detects and corrects errors efficiently. It suggests
pair programming as coding and reviewing of written code carried out by a pair
of programmers who switch their works between them every hour.

36
 2. Testing: Testing code helps to remove errors and improves its reliability. XP
suggests test-driven development (TDD) to continually write and execute test
cases. In the TDD approach, test cases are written even before any code is
written.
3. Incremental development: Incremental development is very good because
customer feedback is gained and based on this development team comes up with
new increments every few days after each iteration.
4. Simplicity: Simplicity makes it easier to develop good quality code as well as to
test and debug it.
5. Design: Good quality design is important to develop good quality software. So,
everybody should design daily.
6. Integration testing: It helps to identify bugs at the interfaces of different
functionalities. Extreme programming suggests that the developers should
achieve continuous integration by building and performing integration testing
several times a day.

Applications of Extreme Programming (XP): Some of the projects that are suitable to
develop using the XP model are given below:

1. Small projects: XP model is very useful in small projects consisting of small

teams as face-to-face meeting is easier to achieve.
2. Projects involving new technology or Research projects: This type of project face
changing requirements rapidly and technical problems. So XP model is used to
complete this type of project.
3. Web development projects: XP model is well-suited for web development
projects as the development process is iterative and requires frequent testing to
ensure the system meets the requirements.
4. Collaborative projects: XP model is useful for collaborative projects that require
close collaboration between the development team and the customer.
5. Projects with tight deadlines: XP model can be used in projects that have a tight
deadline, as it emphasizes simplicity and iterative development.
6. Projects with rapidly changing requirements: XP model is designed to handle
rapidly changing requirements, making it suitable for projects where
requirements may change frequently.
7. Projects where quality is a high priority: XP model places a strong emphasis on
testing and quality assurance, making it a suitable approach for projects where
quality is a high priority.

Other Agile Process Models

1. Extreme Programming (XP)

2. Adaptive Software Development (ASD)
3. Dynamic Systems Development Method (DSDM)
4. Scrum
5. Crystal
6. Feature Driven Development (FDD)
37
7. Agile Modelling (AM)

1. Extreme Programming:
a) Relies on object-oriented approach
b) Key activities
• Planning (user stories created and ordered by customer value)
• Design (simple designs preferred, CRC cards and design prototypes are only
work products, encourages use of refactoring)
• Coding (focuses on unit tests to exercise stories, emphasizes use of pairs
programming to create story code, continuous integration and smoke testing is
utilized)
• Testing (unit tests created before coding are implemented using an automated
testing framework to encourage use of regression testing, integration and validation
testing done on daily basis, acceptance tests focus on system features and functions
viewable by the customer)

2. Adaptive Software Development:

a) Self-organization arises when independent agents cooperate to create a

solution to a problem that is beyond the capability of any individual agent
b) Emphasizes self-organizing teams, interpersonal collaboration, and both
individual and team learning
c) Adaptive cycle characteristics
d) Phases
• Mission-driven
• Component-based
• Iterative
• Time-boxed
• Risk driven and change-tolerant
• Speculation (project initiated and adaptive cycle planning takes place)
• Collaboration (requires teamwork from a jelled team, joint application
development is preferred requirements gathering approach, minispecs created)
• Learning (components implemented and testes, focus groups provide feedback,
formal technical reviews, postmortems)

3. Dynamic Systems Development Method:

a) Provides a framework for building and maintaining systems which meet tight
time constraints using incremental prototyping in a controlled environment
b) Uses Pareto principle (80% of project can be delivered in 20% required to deliver
the entire project) --→ [80% of results come from 20% of the causes]
c) Each increment only delivers enough functionality to move to the next increment
d) Uses time boxes to fix time and resources to determine how much functionality
will be delivered in each increment
e) Guiding principles
• Active user involvement
38
 • Teams empowered to make decisions
• Fitness foe business purpose is criterion for deliverable acceptance
• Iterative and incremental develop needed to converge on accurate business
solution
• All changes made during development are reversible
• Requirements are baselined at a high level
• Testing integrates throughout life-cycle
• Collaborative and cooperative approach between stakeholders
f) Life cycle activities
• Feasibility study (establishes requirements and constraints)
• Business study (establishes functional and information requirements needed to
provide business value)
• Functional model iteration (produces set of incremental prototypes to demonstrate
functionality to customer)
• Design and build iteration (revisits prototypes to ensure they provide business
value for end users, may occur concurrently with functional model iteration)
• Implementation (latest iteration placed in operational environment)

4. Scrum:
a) Scrum principles
• Small working teamed used to maximize communication, minimize overhead,
and maximize sharing of informal knowledge
• Process must be adaptable to both technical and business challenges to ensure
bets product produced
• Process yields frequent increments that can be inspected, adjusted, tested,
documented and built on
• Development work and people performing it are partitioned into clean, low
coupling partitions
• Testing and documentation is performed as the product is built
• Provides the ability to declare the product done whenever required

b) Process patterns defining development activities

• Backlog (prioritized list of requirements or features the provide business value to
customer, items can be added at any time)
• Sprints (work units required to achieve one of the backlog items, must fir into a
predefined time-box, affected backlog items frozen)
• Scrum meetings (15 minute daily meetings) addressing these questions: What
was done since last meeting? What obstacles were encountered? What will be
done by the next meeting?
• Demos (deliver software increment to customer for evaluation)

5. Crystal:
a) Development approach that puts a premium on maneuverability during a resource-
limited game of invention and communication with the primary goal of delivering
useful software and a secondary goal of setting up for the next game
39
b) Crystal principles
• Its always cheaper and faster to communicate face-to-face
• As methodologies become more formal teams become weighed down and have
trouble adapting to project work vagaries
• As projects grow in size, teams become larger and methodologies become heavier
• As projects grow in criticality some degree of formality will need to be
introduced in parts of the methodology
• As feedback and communication become more efficient the need for intermediate
work products is reduced
• Discipline, skills, and understanding counter process, formality, and
documentation
• Team members not on the critical project path can spend their excess time
improving the product or helping people who are on the critical path
c) Incremental development strategy used with 1 to 3 month time lines
d)Reflection workshops conducted before project begins, during increment development
activity, and after increment is delivered
e)Crystal methodologies
• Clear (small, low criticality projects)
• Orange (larger, moderately critical projects)
• Orange Web (typical e-business applications)

6. Feature Driven Development:

a) Practical process model for object-oriented software engineering
b) Feature is a client-valued function, can be implemented in two weeks or less
c) FDD Philosophy
• Emphasizes collaboration among team members
• Manages problem and project complexity using feature-based decomposition
followed integration of software increments
• Technical communication using verbal, graphical, and textual means
• Software quality encouraged by using incremental development, design and code
inspections, SQA audits, metric collection, and use of patterns (analysis, design,
construction)
d) Framework activities
• Develop overall model (contains set of classes depicting business model of
application to be built)
• Build features list (features extracted from domain model, features are
categorized and prioritized, work is broken up into two week chunks)
• Plan by feature (features assessed based on priority, effort, technical issues,
schedule dependencies)
• Design by feature (classes relevant to feature are chosen, class and method
prologs are written, preliminary design detail developed, owner assigned to each
class, owner responsible for maintaining design document for his or her own
work packages)
• Build by feature (class owner translates design into source code and performs unit
testing, integration performed by chief programmer)
40
 7. Agile Modeling:
a) Practice-based methodology for effective modeling and documentation of software
systems in a light-weight manner
b) Modeling principles
• Model with a purpose
• Use multiple models
• Travel light (only keep models with long-term value)
• Content is more important than representation
• Know the models and tools you use to create them
• Adapt locally
c)Requirements gathering and analysis modeling
• Work collaboratively to find out what customer wants to do
• Once requirements model is built collaborative analysis modeling continues with
the customer
d) Architectural modeling
• Derives preliminary architecture from the analysis model
• Architectural model must be realistic for the environment and must be
understandable by developers.

41