MODULE I SOFTWARE PROCESS

Nature of Software – Software Engineering - Software Process – Models –

Generic Process Model – Process Assessment - Prescriptive Process Model –
Specialized Process Models – Unified Process – Personal and Team Process
Models – Process Technology – Product and Process – Agile Model.
MODULE II REQUIREMENTS GATHERING
Requirements Engineering – Understanding Requirements – Requirements
Modeling – Scenarios, Information and Analysis Classes, Flow, Behavior,
Patterns and Web Apps.

NATURE OF SOFTWARE
Software is:
1. instructions (computer programs) that when executed provide desired
features, function, and performance;
2. data structures that enable the programs to adequately manipulate
information, and
3. document that describes the operation and use of the programs.
Characteristics of software ➢ Software is developed or engineered, it is not
manufactured in the classical sense. ➢ Software does not wear out. However it
deteriorates due to change. ➢ Software is custom built rather than assembling
existing components. - Although the industry is moving towards component
based construction, most software continues to be custom built
the changing nature of software:
Seven Broad Categories of software are challenges for software engineers
• System software- System software is a collection of programs written to
service other programs. System software: such as compilers, editors, file
management utilities.
• Application software: stand-alone programs for specific needs. This
software are used to controls business needs. Ex: Transaction processing.
• Artificial intelligence software- Artificial intelligence (AI) software
makes use of nonnumeric algorithms to solve complex problems.
Application within this area include robotics, pattern recognition, game
playing. Engineering and scientific software-Engineering and scientific
software have been characterized by "number crunching" algorithm.

1
 • Embedded software resides within a product or system. (key pad control
of a microwave oven, digital function of dashboard display in a car)
• Product-line software focus on a limited marketplace to address mass
consumer market. (Word processing, graphics, database management)
• WebApps (Web applications) network centric software. As web 2.0
emerges, more sophisticated computing environments is supported
integrated with remote database and business applications.
SOFTWARE ENGINEERING
• Software engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and
works efficiently on real machines. • Or
• The IEEE definition: • Software Engineering: (1) The application of a
systematic, disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application of
engineering to software.
SOFTWARE ENGINEERING - LAYERED TECHNOLOGY
Software engineering is a fully layered technology.
• To develop a software, we need to go from one layer to another.
• All these layers are related to each other and each layer demands the
fulfillment of the previous layer.

The layered technology consists of:

1. Quality focus
The characteristics of good quality software are:
• Correctness of the functions required to be performed by the software.
• Integrity i.e. providing security so that the unauthorized user cannot
access information or data.
• Usability i.e. the efforts required to use or operate the software.
2
 2. Process
• It is the base layer or foundation layer for the software engineering. It
covers all activities, actions and tasks required to be carried out for
software development.
3. Methods
• It provides the technical way to implement the software. It includes
collection of tasks starting from communication, requirement analysis,
analysis and design modelling, program construction, testing and support.
4. Tools
• The software engineering tool is an automated support for the software
development. The tools are integrated i.e the information created by one
tool can be used by the other tool.
THE SOFTWARE PROCESS
• A process is a collection of activities, actions, and tasks that are performed
when some work product is to be created. An activity strives to achieve a
broad objective with which software engineering is to be applied. An action
encompasses a set of tasks that produce a major work .A task focuses on a
small, but well-defined objective that produces a tangible outcome.
• A generic process framework for software engineering encompasses five
activities:
• Communication- Before any technical work can commence, it is critically
important to communicate and collaborate with the customer (and other
stakeholders11 The intent is to understand stakeholders’ objectives for the
project and to gather requirements that help define software features and
functions.
• Planning-Any complicated journey can be simplified if a map exists. The
map— called a software project plan—defines the software engineering
work by describing the technical tasks to be conducted, the risks that are
likely, the resources that will be required, the work products to be
produced, and a work schedule.
• Modeling-A software engineer creating models to better understand
software requirements and the design that will achieve those requirements.
• Construction-This activity combines code generation (either manual or
automated) and the testing that is required to uncover errors in the code.
• Deployment-The software (as a complete entity or as a partially completed
increment) is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation. Software

3
 engineering process framework activities are complemented by a number
of umbrella activities.

Typical umbrella activities include:

• Software project tracking and control—allows the software team to
assess progress against the project plan and take any necessary action to
maintain the schedule.
• Risk management—assesses risks that may affect the outcome of the
project or the quality of the product.
• Software quality assurance—defines and conducts the activities required
to ensure software quality.
• Technical reviews—assesses software engineering work products in an
effort to uncover and remove errors before they are propagated to the next
activity.
• Measurement—defines and collects process, project, and product
measures that assist the team in delivering software that meets
stakeholders’ needs; can be used in conjunction with all other framework
and umbrella activities.
• Software configuration management—manages the effects of change
throughout the software process.
• Reusability management—defines criteria for work product reuse
(including software components) and establishes mechanisms to achieve
reusable components.
• Work product preparation and production—encompasses the activities
required to create work products such as models, documents, logs, forms,
and lists.

4
SDLC MODELS
1. WATERFALL MODEL:

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.

1. Requirements analysis and specification phase: The aim of this phase is to

understand the exact requirements of the customer and to document them
properly. 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.

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).

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

5
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.

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.

Advantages of Waterfall model

• This model is simple to implement also the number of resources that are
required for it is minimal.
• The requirements are simple and explicitly declared; they remain
unchanged during the entire project development.
• The start and end points for each phase is fixed, which makes it easy to
cover progress.
• The release date for the complete product, as well as its final cost, can be
determined before development.
• It gives easy to control and clarity for the customer due to a strict reporting
system.

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.
• Since the testing done at a later stage, it does not allow identifying the
challenges and risks in the earlier phase, so the risk reduction strategy is
difficult to prepare.

6
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. It implements the potential
for rapid development of new versions of the software. 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.

Each cycle in the spiral is divided into four parts:

1. 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.

2. 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.

3. 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.

7
4. 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.

The development phase depends on the remaining risks. For example, if

performance or user-interface risks are treated more essential than the program
development risks, the next phase may be an evolutionary development that
includes developing a more detailed prototype for solving the risks.

The risk-driven feature of the spiral model allows it to accommodate any

mixture of a specification-oriented, prototype-oriented, simulation-oriented, or
another type of approach. An essential element of the model is that each period
of the spiral is completed by a review that includes all the products developed
during that cycle, including plans for the next cycle. The spiral model works for
development as well as enhancement projects.

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.

8
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. So V-Model contains
Verification phases on one side of the Validation phases on the other side.
Verification and Validation process is joined by coding phase in V-shape. Thus
it is known as V-Model.

Verification: It involves a static analysis method (review) done without

executing code. It is the process of evaluation of the product development process
to find whether specified requirements meet.

Validation: It involves dynamic analysis method (functional, non-functional),

testing is done by executing code. Validation is the process to classify the
software after the completion of the development process to determine whether
the software meets the customer expectations and requirements.

9
There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product

requirements understood from the customer's side. This phase contains
detailed communication to understand customer's expectations and exact
requirements.
2. System Design: In this stage system engineers analyze and interpret the
business of the proposed system by studying the user requirements
document.
3. Architecture Design: The baseline in selecting the architecture is that it
should understand all which typically consists of the list of modules, brief
functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology detail, etc. The
integration testing model is carried out in a particular phase.
4. Module Design: In the module design phase, the system breaks down into
small modules. The detailed design of the modules is specified, which is
known as Low-Level Design
5. Coding Phase: After designing, the coding phase is started. Based on the
requirements, a suitable programming language is decided. There are some
guidelines and standards for coding. Before checking in the repository, the
final build is optimized for better performance, and the code goes through
many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed
during the module design phase. These UTPs are executed to eliminate
errors at code level or unit level. A unit is the smallest entity which can
independently exist, e.g., a program module. Unit testing verifies that the
smallest entity can function correctly when isolated from the rest of the
codes/ units.
2. Integration Testing: Integration Test Plans are developed during the
Architectural Design Phase. These tests verify that groups created and
tested independently can coexist and communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design
Phase. Unlike Unit and Integration Test Plans, System Tests Plans are

10
 composed by the client’s business team. System Test ensures that
expectations from an application developer are met.
4. Acceptance Testing: Acceptance testing is related to the business
requirement analysis part. It includes testing the software product in user
atmosphere. Acceptance tests reveal the compatibility problems with the
different systems, which is available within the user atmosphere. It
conjointly discovers the non-functional problems like load and
performance defects within the real user atmosphere.

Advantage of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall
model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage of V-Model:

1. Very rigid and least flexible.

2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early
prototypes of the software are produced.
4. If any changes happen in the midway, then the test documents along with
the required documents, has to be updated.

11
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.

The Iterative Model allows the accessing earlier phases, in which the variations
made respectively. The final output of the project renewed at the end of the
Software Development Life Cycle (SDLC) process.

The various phases of Iterative model are as follows:

1. Requirement gathering & analysis: In this phase, requirements are gathered

from customers and check by an analyst whether requirements will fulfil or not.
Analyst checks that need will achieve within budget or not. After all of this, the
software team skips to the next phase.

2. Design: In the design phase, team 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.
12
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, black box, and grey box test 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
error 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.

Advantages of Iterative Model:

1. Testing and debugging during smaller iteration is easy.

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 of Iterative Model:

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.

13
GENERIC PROCESS MODELS:

A software process is a collection of various activities.

There are five generic process framework activities:

1. Communication:
The software development starts with the communication between customer and
developer.

2. Planning:
It consists of complete estimation, scheduling for project development and
tracking.

3. Modeling:
• Modeling consists of complete requirement analysis and the design of the
project like algorithm, flowchart etc.
• The algorithm is the step-by-step solution of the problem and the flow
chart shows a complete flow diagram of a program.
4. Construction:
• Construction consists of code generation and the testing part.
• Coding part implements the design details using an appropriate
programming language.
• Testing is to check whether the flow of coding is correct or not.
• Testing also check that the program provides desired output.
5. Deployment:
• Deployment step consists of delivering the product to the customer and
take feedback from them.
• If the customer wants some corrections or demands for the additional
capabilities, then the change is required for improvement in the quality
of the software

14
SOFTWARE PROCESS ASSESSMENT:

A software process assessment is a disciplined examination of the software

processes used by an organization, based on a process model. The assessment
includes the identification and characterization of current practices, identifying
areas of strengths and weaknesses, and the ability of current practices to control
or avoid significant causes of poor (software) quality, cost, and schedule.
A software assessment (or audit) can be of three types.
• A self-assessment (first-party assessment) is performed internally
by an organization's own personnel.
• A second-party assessment is performed by an external assessment
team or the organization is assessed by a customer.
• A third-party assessment is performed by an external party or (e.g.,
a supplier being assessed by a third party to verify its ability to enter
contracts with a customer).
Software process assessments are performed in an open and collaborative
environment. They are for the use of the organization to improve its software
processes, and the results are confidential to the organization. The organization
being assessed must have members on the assessment team.

Software Process Maturity Assessment

The scope of a software process assessment can cover all the processes in the
organization, a selected subset of the software processes, or a specific project.
Most of the standard-based process assessment approaches are invariably based
on the concept of process maturity.
When the assessment target is the organization, the results of a process
assessment may differ, even on successive applications of the same method.
There are two reasons for the different results. They are,
• The organization being investigated must be determined. For a large
company, several definitions of organization are possible and
therefore the actual scope of appraisal may differ in successive
assessments.
• Even in what appears to be the same organization, the sample of
projects selected to represent the organization may affect the scope
and outcome.
When the target unit of assessment is at the project level, the assessment should
include all meaningful factors that contribute to the success or failure of the
project. It should not be limited by established dimensions of a given process
maturity model. Here the degree of implementation and their effectiveness as
substantiated by project data are assessed.
15
Process maturity becomes relevant when an organization intends to embark on an
overall long-term improvement strategy. Software project assessments should be
independent assessments in order to be objective.

Software Process Assessment Cycle

According to Paulk and colleagues (1995), the CMM-based assessment approach

uses a six-step cycle. They are −
• Select a team - The members of the team should be professionals
knowledgeable in software engineering and management.
• The representatives of the site to be appraised complete the standard
process maturity questionnaire.
• The assessment team performs an analysis of the questionnaire
responses and identifies the areas that warrant further exploration
according to the CMM key process areas.
• The assessment team conducts a site visit to gain an understanding
of the software process followed by the site.
• The assessment team produces a list of findings that identifies the
strengths and weakness of the organization's software process.
• The assessment team prepares a Key Process Area (KPA) profile
analysis and presents the results to the appropriate audience.
For example, the assessment team must be led by an authorized SEI Lead
Assessor. The team must consist of between four to ten team members. At least,
one team member must be from the organization being assessed, and all team
members must complete the SEI's Introduction to the CMM course (or its
equivalent) and the SEI's CBA IPI team training course. Team members must
also meet some selection guidelines.
With regard to data collection, the CBA IPI relies on four methods −
• The standard maturity questionnaire
• Individual and group interviews
• Document reviews
• Feedback from the review of the draft findings with the assessment
participants

SCAMPI

The Standard CMMI Assessment Method for Process Improvement (SCAMPI)

was developed to satisfy the CMMI model requirements (Software Engineering
Institute, 2000). It is also based on the CBA IPI. Both the CBA IPI and the
SCAMPI consist of three phases −
• Plan and preparation
16
 • Conduct the assessment onsite
• Report results
The activities for the plan and preparation phase include −
• Identify the assessment scope
• Develop the assessment plan
• Prepare and train the assessment team
• Make a brief assessment of participants
• Administer the CMMI Appraisal Questionnaire
• Examine the questionnaire responses
• Conduct an initial document review
The activities for the onsite assessment phase include −
• Conduct an opening meeting
• Conduct interviews
• Consolidate information
• Prepare the presentation of draft findings
• Present the draft findings
• Consolidate, rate, and prepare the final findings
The activities of the reporting results phase include −
• Present the final findings
• Conduct an executive session
• Wrap up the assessment

17
PRESCRIPTIVE PROCESS MODELS:
The name 'prescriptive' is given because the model prescribes a set of activities,
actions, tasks, quality assurance and change the mechanism for every project.

There are three types of prescriptive process models. They are:

1. The Waterfall Model (refer page: 5 )

2. Incremental Process model
3. RAD model

INCREMENTAL PROCESS MODEL:

• The incremental model combines the elements of waterfall model and
they are applied in an iterative fashion.
• The first increment in this model is generally a core product.
• Each increment builds the product and submits it to the customer for any
suggested modifications.
• The next increment implements on the customer's suggestions and add
additional requirements in the previous increment.
• This process is repeated until the product is finished.
For example, the word-processing software is developed using the
incremental model.

Advantages of incremental model

• This model is flexible because the cost of development is low and initial
product delivery is faster.

18
 • It is easier to test and debug during the smaller iteration.
• The working software generates quickly and early during the software
life cycle.
• The customers can respond to its functionalities after every increment.
Disadvantages of the incremental model
• The cost of the final product may cross the cost estimated initially.
• This model requires a very clear and complete planning.
• The planning of design is required before the whole system is broken into
small increments.
• The demands of customer for the additional functionalities after every
increment causes problem during the system architecture.

RAD MODEL:
• RAD is a Rapid Application Development model.
• Using the RAD model, software product is developed in a short period of
time.
• The initial activity starts with the communication between customer and
developer.
• Planning depends upon the initial requirements and then the requirements
are divided into groups.
• Planning is more important to work together on different modules.
The RAD model consist of following phases:

1. Business Modeling
• Business modeling consist of the flow of information between various
functions in the project.
• For example what type of information is produced by every function and
which are the functions to handle that information.
• A complete business analysis should be performed to get the essential
business information.
2. Data modeling
• The information in the business modeling phase is refined into the set of
objects and it is essential for the business.
• The attributes of each object are identified and define the relationship
between objects.

19
3. Process modeling
• The data objects defined in the data modeling phase are changed to fulfil
the information flow to implement the business model.
• The process description is created for adding, modifying, deleting or
retrieving a data object.
4. Application generation
• In the application generation phase, the actual system is built.
• To construct the software the automated tools are used.
5. Testing and turnover
• The prototypes are independently tested after each iteration so that the
overall testing time is reduced.
• The data flow and the interfaces between all the components are are fully
tested. Hence, most of the programming components are already tested.

SPECIALIZED PROCESS MODELS

Special process models take on many of the characteristics of one or more of the
conventional models. However, specialized models tend to be applied when a
narrowly defined software engineering approach is chosen.

COMPONENT-BASED DEVELOPMENT. Commercial off-the-shelf (COST)

software components, developed by vendors who offer them as products, can be
used when software is to be built. These components provide targeted
functionality with well-defined interfaces that enable the component to be

20
integrated into the software. The component-based development model
incorporates many of the characteristics of the spiral model. It is evolutionary in
nature, demanding an iterative approach to the creation of software. However,
the model composes applications from prepackaged software components.
Modeling and construction activities begin with the identification of candidate
components. These components can be designed as either conventional software
modules or object-oriented classes or packages of classes. Regardless of the
technology that is used to create the components, the component-based
development model incorporates the following steps (implemented using an
evolutionary approach):

• Available component-based products are researched and evaluated for the

application domain in question. http://wikistudent.ws/Unisa
• Component integration issues are considered.
• A software architecture is designed to accommodate the components.
• Components are integrated into the architecture.
• Comprehensive testing is conducted to ensure proper functionality. The
component-based development model leads to software reuse, and reusability
provides software engineers with a number of measurable benefits. Based on
studies of reusability component-based development can lead to reduction in
development cycle time, reduction in project cost and increase in productivity.
Although these results are a function of the robustness of the component library,
there is little question that the component-based development model provides
significant advantages for software engineers.

THE FORMAL METHODS MODEL. The formal methods model encompasses

a set of activities that leads to formal mathematical specification of computer
software. Formal methods enable a software engineer to specify, develop, and
verify a computer-based system by applying rigorous, mathematical notation. A
variation on this approach is called clean-room software engineering. When
formal methods are used during development, they provide a mechanism for
eliminating many of the problems that are difficult to overcome using other
software engineering paradigms. Ambiguity, incompleteness, and inconsistency
can be discovered and corrected more easily, not through ad hoc review, but
through the application of mathematical analysis. When formal methods are
used during design, they serve as a basis for program verification and therefore
enable the software engineer to discover and correct errors that might otherwise
go undetected. Although not a mainstream approach, the formal methods model
offers the promise of defect-free software. Yet, concern about its applicability in
a business environment has been voiced:
21
• The development of formal models is currently quite time-consuming and
expensive.
• Because few software developers have the necessary background to apply
formal methods, extensive training is required.
• It is difficult to use the model as a communication mechanism for technically
unsophisticated customers.

ASPECT-ORIENTED SOFTWARE DEVELOPMENT.

Regardless of the software process that is chosen, the builders of complex

software invariably implement a set of localized features, functions and
information content. These localized software characteristics are modeled as
components and then constructed within the context of a system architecture. As
modern computer-based systems become more sophisticated and complex,
certain concerns, customer required properties or areas of technical interest,
span the entire architecture. Some concerns are high-level properties of a
system; others affect functions or are systemic. When concerns cut across
multiple system functions, features, and information they are often referred to as
crosscutting concerns. Aspectual requirements define those crosscutting
concerns that have impact across the software architecture. Aspects are
mechanisms beyond subroutines and inheritance for localizing the expression of
a crosscutting concerns. Aspect-oriented software development (AOSD), often
referred to as aspect-oriented programming (AOP), is a relatively new software
engineering paradigm that provides a process and methodological approach for
defining, specifying, designing, and constructing aspects.
http://wikistudent.ws/Unisa A distinct aspect-oriented process has not yet
matured. However, it is likely that such a process will adopt characteristics of
both the spiral and concurrent process models. The evolutionary nature of the
spiral is appropriate as aspects are identified and then constructed. The parallel
nature of concurrent development is essential because aspects are engineered
independently of localized software components and yet, aspects have a direct
impact on these components.

THE UNIFIED PROCESS.

In some ways the unified process (UP) is an attempt to draw on the best features
and characteristics of conventional software process models, but characterize
them in a way that implements many of the best principles of agile software
development. The unified process recognizes the importance of customer
communication and streamlined methods for describing the customer’s view of
22
a system. It emphasizes the important role of software architecture and helps the
architect focus on the right goals, such as understandability, reliance to future
changes, and reuse. It suggests a process flow that is iterative and incremental,
providing the evolutionary feel that is essential in modern software
development.
UNIFIED PROCESS MODEL:
We'll go through the four different phases, one at a time, here:

1. Inception: The inception phase is similar to the requirements collection and analysis
stage of the waterfall model of software development. In this phase, you'd collect
requirements from the customer and analyze the project's feasibility, its cost, risks,
and profits.

2. Elaboration: In this phase, you'd be expanding upon the activities undertaken in the
inception phase. The major goals of this phase include creating fully functional
requirements (use-cases) and creating a detailed architecture for fulfillment of the
requirements. You'd also prepare a business case document for the customer.

3. Construction: In this phase, you'd be writing actual code and implementing the
features for each iteration. You'd be rolling out the first iteration of the software
depending on the key use-cases that make up the core functionalities of the
software system.

4. Transition: In this phase, you'd be rolling out the next iterations to the customer
and fixing bugs for previous releases. You would also deploy builds of the software
to the customer.

PERSONAL AND TEAM PROCESS MODELS

https://youtu.be/0gHb9e2s_60

23
PRODUCT AND PROCESS:
S.No. PRODUCT PROCESS
1. Product is the final production While the process is a set of
of the project. sequence steps that have to be
followed to create a project.
2. A product focuses on the final Whereas the process is focused on
result. completing each step being
developed.
3. In the case of products, the In contrast, the process
firm guidelines are followed. consistently follows guidelines.
4. A product tends to be short- Whereas the process tends to be
term. long-term.
5. The main goal of the product While the purpose of the process is
is to complete the work to make the quality of the project
successfully. better.
6. Product is created based on A process serves as a model for
the needs and expectations of producing various goods in a
the customers. similar way.
7. A product layout is a style of When resources with similar
layout design in which the processes or functions are grouped
materials required to make the together, it is referred to as a
product are placed in a single process layout.
line depending on the order of
operations.
8. Product patents are thought to A process patent provides the
offer a greater level of inventor only limited protection.
protection than process
patents.

AGILE MODEL
Agile SDLC model is a combination of iterative and incremental process models
with focus on process adaptability and customer satisfaction by rapid delivery of
working software product. Agile Methods break the product into small
incremental builds. These builds are provided in iterations. Each iteration
typically lasts from about one to three weeks. Every iteration involves cross
functional teams working simultaneously on various areas like −
• Planning
• Requirements Analysis
• Design
• Coding

24
 • Unit Testing and
• Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and
important stakeholders.

What is Agile?

Agile model believes that every project needs to be handled differently and the
existing methods need to be tailored to best suit the project requirements. In
Agile, the tasks are divided to time boxes (small time frames) to deliver specific
features for a release.
Iterative approach is taken and working software build is delivered after each
iteration. Each build is incremental in terms of features; the final build holds all
the features required by the customer.
Here is a graphical illustration of the Agile Model −

The Agile thought process had started early in the software development and
started becoming popular with time due to its flexibility and adaptability.
The most popular Agile methods include Rational Unified Process (1994), Scrum
(1995), Crystal Clear, Extreme Programming (1996), Adaptive Software
Development, Feature Driven Development, and Dynamic Systems Development

25
Method (DSDM) (1995). These are now collectively referred to as Agile
Methodologies, after the Agile Manifesto was published in 2001.
Following are the Agile Manifesto principles −
• Individuals and interactions − In Agile development, self-
organization and motivation are important, as are interactions like
co-location and pair programming.
• Working software − Demo working software is considered the best
means of communication with the customers to understand their
requirements, instead of just depending on documentation.
• Customer collaboration − As the requirements cannot be gathered
completely in the beginning of the project due to various factors,
continuous customer interaction is very important to get proper
product requirements.
• Responding to change − Agile Development is focused on quick
responses to change and continuous development.

Agile Vs Traditional SDLC Models

Agile is based on the adaptive software development methods, whereas the

traditional SDLC models like the waterfall model is based on a predictive
approach. Predictive teams in the traditional SDLC models usually work with
detailed planning and have a complete forecast of the exact tasks and features to
be delivered in the next few months or during the product life cycle.
Predictive methods entirely depend on the requirement analysis and
planning done in the beginning of cycle. Any changes to be incorporated go
through a strict change control management and prioritization.
Agile uses an adaptive approach where there is no detailed planning and there
is clarity on future tasks only in respect of what features need to be developed.
There is feature driven development and the team adapts to the changing product
requirements dynamically. The product is tested very frequently, through the
release iterations, minimizing the risk of any major failures in future.
Customer Interaction is the backbone of this Agile methodology, and open
communication with minimum documentation are the typical features of Agile
development environment. The agile teams work in close collaboration with each
other and are most often located in the same geographical location.

Agile Model - Pros and Cons

Agile methods are being widely accepted in the software world recently.
However, this method may not always be suitable for all products. Here are some
pros and cons of the Agile model.

26
Agile Testing Methods:

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

The advantages of the Agile Model are as follows −

• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing requirements
• Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall
planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
The disadvantages of the Agile Model are as follows −
• Not suitable for handling complex dependencies.
• More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must
without which it will not work.
• Strict delivery management dictates the scope, functionality to be
delivered, and adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear,
team can be driven in the wrong direction.
• There is a very high individual dependency, since there is minimum
documentation generated.
• Transfer of technology to new team members may be quite
challenging due to lack of documentation.

27
MODULE II

REQUIREMENTS ENGINEERING

Requirements Engineering (RE) refers to the process of defining, documenting,

and maintaining requirements in the engineering design process. Requirement
engineering provides the appropriate mechanism to understand what the customer
desires, analyzing the need, and assessing feasibility, negotiating a reasonable
solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system. Thus,
requirement engineering is the disciplined application of proven principles,
methods, tools, and notation to describe a proposed system's intended behavior
and its associated constraints.

Requirement Engineering Process

It is a four-step process, which includes -

1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management

28
1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing
the software that is acceptable to users, flexible to change and conformable to
established standards.

Types of Feasibility:

1. Technical Feasibility - Technical feasibility evaluates the current

technologies, which are needed to accomplish customer requirements
within the time and budget.
2. Operational Feasibility - Operational feasibility assesses the range in
which the required software performs a series of levels to solve business
problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are

identified with the help of customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements

are analyzed to identify inconsistencies, defects, omission, etc. We describe
requirements in terms of relationships and also resolve conflicts if any.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want
o Stakeholders express requirements in their terms.
o Stakeholders may have conflicting requirements.
o Requirement change during the analysis process.
o Organizational and political factors may influence system requirements.

29
3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a

software analyst after the requirements collected from the various sources - the
requirement received by the customer written in ordinary language. It is the job
of the analyst to write the requirement in technical language so that they can be
understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs),
function decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows the flow of data through a system.
The system may be a company, an organization, a set of procedures, a
computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.
o Data Dictionaries: Data Dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirements
stage, the data dictionary should at least define customer data items, to
ensure that the customer and developers use the same definition and
terminologies.
o Entity-Relationship Diagrams: Another tool for requirement
specification is the entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the

30
 organization and uses three main constructs i.e. data entities, relationships,
and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this

document are validated. The user might demand illegal, impossible solution or
experts may misinterpret the needs. Requirements can be the check against the
following conditions -

o If they can practically implement

o If they are correct and as per the functionality and specially of software
o If there are any ambiguities
o If they are full
o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the

requirements.
o Prototyping: Using an executable model of the system to check
requirements.
o Test-case generation: Developing tests for requirements to check
testability.
o Automated consistency analysis: checking for the consistency of
structured requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements

during the requirements engineering process and system development.

New requirements emerge during the process as business needs a change, and a
better understanding of the system is developed.

The priority of requirements from different viewpoints changes during

development process.

The business and technical environment of the system changes during the
development.

31
Prerequisite of Software requirements

Collection of software requirements is the basis of the entire software

development project. Hence they should be clear, correct, and well-defined.

A complete Software Requirement Specifications should be:

o Clear
o Correct
o Consistent
o Coherent
o Comprehensible
o Modifiable
o Verifiable
o Prioritized
o Unambiguous
o Traceable
o Credible source

Software Requirements: Largely software requirements must be categorized

into two categories:

1. Functional Requirements: Functional requirements define a function that

a system or system element must be qualified to perform and must be
documented in different forms. The functional requirements are describing
the behavior of the system as it correlates to the system's functionality.
2. Non-functional Requirements: This can be the necessities that specify
the criteria that can be used to decide the operation instead of specific
behaviors of the system.
Non-functional requirements are divided into two main categories:
o Execution qualities like security and usability, which are
observable at run time.
o Evolution qualities like testability, maintainability, extensibility,
and scalability that embodied in the static structure of the software
system.

32
UNDERSTANDING SOFTWARE REQUIREMENTS
https://www.youtube.com/watch?v=akI9ww7VyqY

REQUIREMENTS MODELING:
Requirements modelling is the process used in software development projects
where requirements and solutions constantly evolve through collaborative efforts
and teamwork. By using this method of cross-functional and self-organizing
teams, you can ensure that your team meets the exact needs of the stakeholders.

Requirement modeling strategies

Following are the requirement modeling strategies:

1. Flow Oriented Modeling
2. Class-based Modeling

Flow Oriented Modeling

It shows how data objects are transformed by processing the function.

The Flow oriented elements are:

i. Data flow model

• It is a graphical technique. It is used to represent information flow.
• The data objects are flowing within the software and transformed by
processing the elements.
• The data objects are represented by labeled arrows. Transformation are
represented by circles called as bubbles.
• DFD shown in a hierarchical fashion. The DFD is split into different
levels. It also called as 'context level diagram'.

ii. Control flow model

• Large class applications require a control flow modeling.
• The application creates control information instated of reports or
displays.
• The applications process the information in specified time.
• An event is implemented as a boolean value.
For example, the boolean values are true or false, on or off, 1 or 0.

33
iii. Control Specification
• A short term for control specification is CSPEC.
• It represents the behaviour of the system.
• The state diagram in CSPEC is a sequential specification of the
behaviour.
• The state diagram includes states, transitions, events and activities.
• State diagram shows the transition from one state to another state if a
particular event has occurred.

iv. Process Specification

• A short term for process specification is PSPEC.
• The process specification is used to describe all flow model processes.
• The content of process specification consists narrative text, Program
Design Language(PDL) of the process algorithm, mathematical
equations, tables or UML activity diagram.

2. Class-based Modeling

• Class based modeling represents the object. The system manipulates the
operations.
• The elements of the class based model consist of classes and object,
attributes, operations, class – responsibility - collaborator (CRS) models.

Classes
Classes are determined using underlining each noun or noun clause and enter it
into the simple table.

Classes are found in following forms:

• External entities: The system, people or the device generates the
information that is used by the computer based system.
• Things: The reports, displays, letter, signal are the part of the
information domain or the problem.
• Occurrences or events: A property transfer or the completion of a series
or robot movements occurs in the context of the system operation.

34
 • Roles: The people like manager, engineer, salesperson are interacting
with the system.
• Organizational units: The division, group, team are suitable for an
application.
• Places: The manufacturing floor or loading dock from the context of the
problem and the overall function of the system.
• Structures: The sensors, computers are defined a class of objects or
related classes of objects.

Attributes
Attributes are the set of data objects that are defining a complete class within
the context of the problem.
For example, 'employee' is a class and it consists of name, Id, department,
designation and salary of the employee are the attributes.

Operations
The operations define the behaviour of an object.

The operations are characterized into following types:

• The operations manipulate the data like adding, modifying, deleting and
displaying etc.
• The operations perform a computation.
• The operation monitors the objects for the occurrence of controlling an
event.

CRS Modeling
• The CRS stands for Class-Responsibility-Collaborator.
• It provides a simple method for identifying and organizing the classes
that are applicable to the system or product requirement.
• Class is an object-oriented class name. It consists of information about
sub classes and super class.
• Responsibilities are the attributes and operations that are related to the
class.
• Collaborations are identified and determined when a class can achieve
each responsibility of it. If the class cannot identify itself, then it needs
to interact with another class.

35
REQUIREMENTS ANALYSIS:
Requirements analysis results in the specification of software’s operational
characteristics, indicates software’s interface with other system elements, and
establishes constraints that software must meet.Requirements analysis allows you
(regardless of whether you’re called a software engineer, an analyst, or a modeler)
to elaborate on basic requirements established during the inception, elicitation,
and negotiation tasks that are part of requirements engineering
The requirements modeling action results in
• Scenario-based models of requirements from the point of view of various
system “actors”
• Data models that depict the info domain for the problem
• Class-oriented models that represent object-oriented classes (attributes
and operations) and the manner in which classes collaborate to achieve
system requirements
• Flow-oriented models that represent the functional elements of the system
and how they transform data as it moves through the system
• Behavioral models that depict how the software behaves as a
consequence of external “events”.
The requirements model must achieve three primary objectives:
• to describe what the customer requires,
• to establish a basis for the creation of a software design,
• to define a set of requirements that can be validated once the software is
built.
• The analysis model bridges the gap between a system-level description
that describes overall system or business functionality as it is achieved by
applying software, hardware, data, human, and other system elements and
a software design that describes the software’s application architecture,
user interface, and component-level structure

36
Analysis Rules of Thumb

• The analysis model should focus on requirements that are visible within
the problem or business domain

- The level of abstraction should be relatively high

• Each element of the analysis model should add to an overall

understanding of software requirements and provide insight into the
following

- Information domain, function, and behavior of the system

• The model should delay the consideration of infrastructure and other non-
functional models until the design phase

- First complete the analysis of the problem domain

• The model should minimize coupling throughout the system

- Reduce the level of interconnectedness among functions and

classes

• The model should provide value to all stakeholders

• The model should be kept as simple as can be

Domain Analysis

• Definition

- The identification, analysis, and specification of common, reusable

capabilities within a specific application domain
37
 - Do this in terms of common objects, classes, subassemblies, and
frameworks
• Sources of domain knowledge

- Technical literature

- Existing applications

- Customer surveys and expert advice

- Current/future requirements
• Outcome of domain analysis

- Class taxonomies

- Reuse standards

- Functional and behavioral models

- Domain languages

38
A Set of ModelsFlow
• oriented modeling – provides an indication of how data objects are
transformed by a set of processing functions
• Scenario-based modeling – represents the system from the user's point of
view
• Class-based modeling – defines objects, attributes, and relationships
• Behavioral modeling – depicts the states of the classes and the impact of
events on these states

Scenario based Modeling

• User satisfaction
- Properly characterize requirements
- Actors Interaction with the system
- Build meaningful analysis models
• Requirements modeling
• UML
- Usecase
- Activity diagrams
- Swimlane diagrams

39
Creating a preliminary Use Case
• Contract for behaviorwhat
- to write about (inception and elicitation)
Requirements gathering meeting, QFD, scope, functional
requirements etc.
- how much to write about it
- how detailed to make your description
- how to organize the description?

Writing Use Cases Use-case title: Actor: Description: I …

It is effective to use the first person “I” to describe how the actor interacts with
the softwareFormat of the text part of a use case
Use-case title:
Actor:
Description: I …

40
ACTIVITY DIAGRAM:
• Supplements the use case by providing a graphical representation of the
flow of interaction within a specific scenario
• Uses flowchart-like symbols
- Rounded rectangle - represent a specific system function/action
- Arrow - represents the flow of control from one function/action to
another
- Diamond - represents a branching decision
- Solid bar – represents the fork and join of parallel activities

41
SWIMLANE DIAGRAM:
• The UML swimlane diagram is a useful variation of the activity diagram
and allows you to represent the flow of activities described by the use case
and at the same time indicate which actor (if there are multiple actors
involved in a specific use case) or analysis class (discussed later in this
chapter) has responsibility for the action described by an activity rectangle.
• Responsibilities are represented as parallel segments that divide the
diagram vertically, like the lanes in a swimming pool.

42
FLOW-ORIENTED MODELING
• Represents how data objects are transformed at they move through the
system
• data flow diagram (DFD) – complement UML diagrams and provide
additional insight into system requirements and flow
• Considered by many to be an “old school” approach, but continues to
provide a view of the system that is unique
• Input –process-output view of the system
Data objects flow into the system- transformed by processing elements-resultant
data objects flow out of the software
• represented in hierarchical fashion

43
LEVEL 0 DFD

44
LEVEL 1 DFD

LEVEL 2 DFD

45
CLASS DIAGRAM for Safe Home Security Function:

46
Data Flow and Control Flow
• Data Flow Diagram
- Depicts how input is transformed into output as data objects move
through a system
• Process Specification
- Describes data flow processing at the lowest level of refinement in
the data flow diagrams
• Control Flow Diagram
- Illustrates how events affect the behavior of a system through the
use of state diagrams

47
STATE DIAGRAM for Safe Home Security Diagram:

CLASS BASED MODELING

• Class-based modeling represents the objects that the system will
manipulate, the operations (also called methods or services) that will be
applied to the objects to effect the manipulation, relationships (some
hierarchical) between the objects, and the collaborations that occur
between the classes that are defined.
• The elements of a class-based model include classes and objects,
attributes, operations, class responsibility- collaborator (CRC) models,
collaboration diagrams, and packages.
Identifying Analysis Classes
1) Perform a grammatical parse of the problem statement or use cases
2) Classes are determined by underlining each noun or noun clause
3) A class required to implement a solution is part of the solution space
4) A class necessary only to describe a solution is part of the problem space
5) A class should NOT have an imperative procedural name (i.e., a verb)
6) List the potential class names in a table and "classify" each class
according to some taxonomy and class selection characteristics

48
 7) A potential class should satisfy nearly all (or all) of the selection
characteristics to be considered a legitimate problem domain class.

Class Diagram:

Class Responsibility Collaborator (CRC)

• A CRC model is really a collection of standard index cards that represent
classes. The cards are divided into three sections. Along the top of the
card you write the name of the class.
• In the body of the card you list the class responsibilities on the left and
the collaborators on the right.
• In reality, the CRC model may make use of actual or virtual index cards.
• The intent is to develop an organized representation of classes.

49
 • Responsibilities are the attributes and operations that are relevant for the
class.
Classes can be
• Entity class/ model/ business classes (eg. Floor plan/sensors)
• Boundary classes are used to create the interface (e.g., interactive screen
or printed reports) that the user sees and interacts with as the software is
used.
• Controller classes manage a “unit of work” from start to finish. That is,
controller classes can be designed to manage
- the creation or update of entity objects,
- the instantiation of boundary objects as they obtain information
from entity objects,
- complex communication between sets of objects,
- validation of data communicated between objects or between the
user and the application.
Behavioral Modeling
The behavioral model indicates how software will respond to external events or
stimuli.To create the model, one should perform the following steps:
• Evaluate all use cases to fully understand the sequence of interaction
within the system
• Identify events that drive the interaction sequence and understand how
these events relate to specific objects
• Create a sequence for each use case.
• Build a state diagram for the system.
• Review the behavioral model to verify accuracy and consistency.

State Diagram for Control panel:

50
Building a State Diagram
• A state is represented by a rounded rectangle
• A transition (i.e., event) is represented by a labeled arrow leading from
one state to another
- Syntax: trigger-signature [guard]/activity
• The active state of an object indicates the current overall status of the
object as is goes through transformation or processing
- A state name represents one of the possible active states of an
object
• The passive state of an object is the current value of all of an object's
attributes
- A guard in a transition may contain the checking of the passive
state of an object

Sequence Diagram for Safe Home Security Function:

51
52