UNIT-1

CHAPTER-1 THE NATURE OF SOFTWARE

DEFINING 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)descriptive information in both hard copy and virtual forms that describes the
operation and use of the programs.

(4) Software is a logical rather than a physical system element. Therefore, software has
one fundamental characteristic that makes it considerably different from hardware.

The above Figure depicts failure rate as a function of time for hardware. The
relationship, often called the “bathtub curve,” indicates that hardware exhibits relatively
high failure rates early in its life. defects are corrected and the failure rate drops to a
steady-state level (hopefully, quite low) for some period of time. As time passes,
however, the failure rate rises again as hardware components suffer from the
cumulative effects of dust.

In theory, therefore, the failure rate curve for software should take the form of the
“idealized curve” shown in the following Figure.
Before the curve can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again. Slowly, the minimum failure rate level
begins to rise—the software is deteriorating due to change.

SOFTWARE APPLICATION DOMAINS:

seven broad categories of computer software present continuing challenges for

software engineers:

System software— a collection of programs written to service other programs.

Application software —. Applications in this area process business or technical data in

a way that facilitates business operations or management/technical decision making.

Engineering/scientific software —a broad array of “number-crunching programs that

range from astronomy to volcanology, from automotive stress analysis to orbital
dynamics, and from computer-aided design to molecular biology, from genetic analysis
to meteorology.

Embedded software—Embedded software can perform limited and esoteric functions

(e.g., keypad control for a microwave oven) or provide significant function and control
capability (e.g., digital functions in an automobile such as fuel control, dashboard
displays, and braking systems).

Product-line software —Product-line software can focus on a limited and esoteric

marketplace (e.g., inventory control products) or address mass consumers.

Web/Mobile applications —this network-centric software category spans a wide array

of applications and encompasses both browser-based apps and software that resides
on mobile devices.

Artificial intelligence software— makes use of nonnumerical algorithms to solve

complex problems. Applications within this area include robotics, expert systems,
pattern recognition (image and voice), artificial neural networks, theorem proving, and
game playing.

LEGACY SOFTWARE:

Hundreds of thousands of computer programs fall into one of the seven broad
application domains discussed in the preceding subsection. Some of these are
state-of-the-art software—just released to individuals, industry, and government. But
other programs are older, in some cases much older. These older programs—often
referred to as legacy software.

However, as time passes, legacy systems often evolve for one or more of the following
reasons:

• The software must be adapted to meet the needs of new computing environments or
technology.

• The software must be enhanced to implement new business requirements.

• The software must be extended to make it interoperable with other more modern
systems or databases.

• The software must be re-architected to make it viable within an evolving computing

environment.

WEBAPPS:

WebApps have evolved into sophisticated computing tools that not only provide
stand-alone functions to the end user, but also have been integrated with corporate
databases and business applications. WebApps “involve[d] a mixture between print
publishing and software development, between marketing and computing, between
internal communications and external relations, and between art and technology.” But
today, they provide full computing potential in many of the application categories.

MOBILE APPLICATIONS:

Mobile applications encompass a user interface that takes advantage of the unique
interaction mechanisms provided by the mobile platform, interoperability with
Web-based resources that provide access to a wide array of information that is relevant
to the app, and local processing capabilities that collect, analyze, and format information
in a manner that is best suited to the mobile platform.
CLOUD COMPUTING:

Cloud computing encompasses an infrastructure or “ecosystem” that enables any user,

anywhere, to use a computing device to share computing resources on a broad scale.
The implementation of cloud computing requires the development of an architecture that
encompasses front-end and back-end services. The front-end includes the client (user)
device and the application software (e.g., a browser) that allows the back-end to be
accessed. The back-end includes servers and related computing resources.

The cloud architecture can be segmented to provide access at a variety of different

levels from full public access to private cloud architectures accessible only to those with
authorization.

PRODUCT LINE SOFTWARE:

The Software Engineering Institute defines a software product line as “a set of

software-intensive systems that share a common, managed set of features satisfying
the specific needs of a particular market segment or mission and that are developed
from a common set of core assets in a prescribed way.” A software product line shares
a set of assets that include requirements , architecture , design patterns , reusable
components , test cases, and other software engineering work products. In essence, a
software product line results in the development of many products that are engineered
by capitalizing on the commonality among all the products within the product line.
CHAPTER 2 - Software Engineering

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 striving to achieve a broad objective is applied
regardless of the application domain, size of the project, complexity of the effort, or
degree of rigor with which software engineering is to be applied.
An action (e.g., architectural design) encompasses a set of tasks that produce a major
work product (e.g., an architectural model).
A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.

The Process Framework:-

Communication:- Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other stakeholders). 3 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. A software
project is a complicated journey, and the planning activity creates a “map” that helps
guide the team as it makes the journey. 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:- Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day. You create a “sketch” of the
thing so that you’ll understand the big picture—what it will look like architecturally, how
the constituent parts fit together, and many other characteristics. If required, you refine
the sketch into greater and greater detail in an effort to better understand the problem
and how you’re going to solve it. A software engineer does the same thing by creating
models to better understand software requirements and the design that will achieve
those requirements.
Construction:- What you design must be built. 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
Umbrella Activities:-
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:- It defines and conducts the activities required to ensure
software quality.
Technical reviews :-assess software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
Measurement:- It 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:- It 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:- It encompasses the activities required to
create work products such as models, documents, logs, forms, and lists.

Process Adaptation:-
• Overall flow of activities, actions, and tasks and the interdependencies among them.
• Degree to which actions and tasks are defined within each framework activity.
• Degree to which work products are identified and required.
• Manner in which quality assurance activities are applied.
• Manner in which project tracking and control activities are applied.
• Overall degree of detail and rigor with which the process is described.
• Degree to which the customer and other stakeholders are involved with the project.
• Level of autonomy given to the software team.
• Degree to which team organization and roles are prescribed.
The Essence of Practice:-
The essence of software engineering practice:
1. Understand the problem (communication and analysis)
2. Plan a solution (modeling and software design)
3. Carry out the plan (code generation)
. 4. Examine the result for accuracy (testing and quality assurance)

General Principles:-
1.The First Principle: The Reason It All Exists:- A software system exists for one
reason: to provide value to its users. All decisions should be made with this in mind.
Before specifying a system requirement, before noting a piece of system functionality,
before determining the hardware platforms or development processes
2.The Second Principle: KISS (Keep It Simple, Stupid!):- All design should be as
simple as possible, but no simpler. This facilitates having a more easily understood and
easily maintained system. This is not to say that features, even internal features, should
be discarded in the name of simplicity
3. The Third Principle: Maintain the Vision:- A clear vision is essential to the success
of a software project. Without one, a project almost unfailingly ends up being “of two [or
more] minds” about itself. Compromising the architectural vision of a software system
weakens and will eventually break even the well-designed systems. Having an
empowered architect who can hold the vision and enforce compliance helps ensure a
very successful software project.
4.The Fourth Principle: What You Produce, Others Will Consume:- . In some way or
another, someone else will use, maintain, document, or otherwise depend on being able
to understand your system. So, always specify, design, and implement knowing
someone else will have to understand what you are doing. The audience for any
product of software development is potentially large.
5.The Fifth Principle: Be Open to the Future:- Never design yourself into a corner.
Always ask “what if,” and prepare for all possible answers by creating systems that
solve the general problem, not just the specific one. 6 This could very possibly lead to
the reuse of an entire system.
6.The Sixth Principle: Plan Ahead for Reuse:- Reuse saves time and effort. 7
Achieving a high level of reuse is arguably the hardest goal to accomplish in developing
a software system. The reuse of code and designs has been proclaimed as a major
benefit of using object-oriented technologies. However, the return on this investment is
not automatic.
7.The Seventh Principle: Think!:- This last Principle is probably the most overlooked.
Placing clear, complete thought before action almost always produces better results.
When you think about something, you are more likely to do it right. You also gain
knowledge about how to do it right again. If you do think about something and still do it
wrong, it becomes a valuable experience. A side effect of thinking is learning to
recognize when you don’t know something, at which point you can research the answer.
When clear thought has gone into a system, value comes out

SOFTWARE DEVELOPMENT MYTH:-

Management myths:- Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slipping,
and improve quality. Like a drowning person who grasps at a straw, a software manager
often grasps at belief in a software myth, if that belief will lessen the pressure (even
temporarily).
Customer myths:- A customer who requests computer software may be a person at
the next desk, a technical group down the hall, the marketing/sales department, or an
outside company that has requested software under contract. In many cases, the
customer believes myths about software because software managers and practitioners
do little to correct misinformation. Myths lead to false expectations (by the customer)
and, ultimately, dissatisfaction with the developer.
Practitioner’s myths:- Myths that are still believed by software practitioners have been
fostered by over 60 years of programming culture. During the early days, programming
was viewed as an art form. Old ways and attitudes die hard
Chapter 3 - SOFTWARE PROCESS STRUCTURE
1) A GENERIC PROCESS MODEL:
● Each software engineering action is defined by a task set that identifies the work
tasks that are to be completed, the work products that will be produced , the
quality assurance points that will be required, and the milestones that will be
used to indicate progress.
● A generic process framework for software engineering defines five framework
activities— communication, planning, modeling, construction, and
deployment. In addition, a set of umbrella activities—project tracking and
control, risk management, quality assurance, configuration management,
technical reviews, and others—are applied throughout the process.
● This aspect—called process flow—describes how the framework activities and
the actions and tasks that occur within each framework activity are organized
with respect to sequence and time.

2)A SOFTWARE PROCESS FRAMEWORK

3) DEFINING A FRAMEWORK ACTIVITY:
I) Process flow:
For a small software project requested by one person (at a remote location) with simple,
straightforward requirements, the communication activity might encompass little more
than a phone call or email with the appropriate stakeholder. Therefore, the only
necessary action is phone conversation, and the work tasks (the task set) that this
action encompasses are:
1. Make contact with stakeholders via telephone.
2. Discuss requirements and develop notes.
3. Organize notes into a brief written statement of requirements.
4. Email to stakeholder for review and approval.
The communication activity might have six distinct actions: inception, elicitation ,
elaboration, negotiation, specification, and validation. Each of these software
engineering actions would have many work tasks and a number of distinct work
products.
4) IDENTIFYING A TASK SET:
● Each software engineering action (e.g., elicitation, an action associated with the
communication activity) can be represented by a number of different task
sets—each a collection of software engineering work tasks, related work
products, quality assurance points, and project milestones.
● You should choose a task set that best accommodates the needs of the project
and the characteristics of your team. This implies that a software engineering
action can be adapted to the specific needs of the software project and the
characteristics of the project team.

5) PROCESS PATTERN:
● A process pattern describes a process-related problem that is encountered
during software engineering work, identifies the environment in which the
problem has been encountered, and suggests one or more proven solutions to
the problem. Stated in more general terms, a process pattern provides you with a
template [Amb98]—a consistent method for describing problem solutions within
the context of the software process. By combining patterns, a software team can
solve problems and construct a process that best meets the needs of a project.
Pattern Name. The pattern is given a meaningful name describing it within the
context of the software process (e.g. Technical Reviews).
Forces. The environment in which the pattern is encountered and the issues that
make the problem visible and may affect its solution.
Type : The pattern type is specified. Ambler suggests three types:

1. Stage pattern—
defines a problem associated with a framework activity for the process. Since a
framework activity encompasses multiple actions and work tasks, a stage pattern
incorporates multiple task patterns (see the following) that are relevant to the
stage (framework activity).
2. Task pattern—defines a problem associated with a software engineering
action or work task and relevant to successful software engineering practice (e.g.
Requirements Gathering is a task pattern).
3. Phase pattern—define the sequence of framework activities that occurs within
the process, even when the overall flow of activities is iterative in nature. An
example of a phase pattern might be Spiral Model or Prototyping.
Initial Context. Describes the conditions under which the pattern applies. Prior
to the initiation of the pattern:
(1) What organizational or team-related activities have already occurred?
(2) What is the entry state for the process?
(3) What software engineering information or project information already exists?
Problem. The specific problem to be solved by the pattern.
Solution. Describes how to implement the pattern successfully. This section
describes how the initial state of the process (that exists before the pattern is
implemented) is modified as a consequence of the initiation of the pattern. It also
describes how software engineering information or project information that is
available before the initiation of the pattern is transformed as a consequence of
the successful execution of the pattern.
Resulting Context. Describes the conditions that will result once the pattern has
been successfully implemented. Upon completion of the pattern:
(1) What organizational or team-related activities must have occurred?
(2) What is the exit state for the process?
(3) What software engineering information or project information has been
developed? Related Patterns. Provide a list of all process patterns that are
directly related to this one. This may be represented as a hierarchy or in some
other diagrammatic form. For example, the stage pattern Communication
encompasses the task patterns: Project Team, Collaborative Guidelines, Scope
Isolation, Requirements Gathering, Constraint Description, and Scenario
Creation.
6) PROCESS ASSESSMENT AND IMPROVEMENT:
Standard CMMI Assessment Method for Process Improvement (SCAMPI)—
provides a five-step process assessment model that incorporates five phases:
initiating, diagnosing, establishing, acting, and learning. The SCAMPI
method uses the SEI CMMI as the basis for assessment [SEI00].
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—
provides a diagnostic technique for assessing the relative maturity of a software
organization; uses the SEI CMM as the basis for the assessment [Dun01].
SPICE (ISO/IEC15504)—a standard that defines a set of requirements for
software process assessment. The intent of the standard is to assist
organizations in developing an objective evaluation of the efficacy of any defined
software process [ISO08].
ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products, systems, or
services that it provides. Therefore, the standard is directly applicable to software
organizations and companies [Ant06].
Chapter- 4 Process Model:
Process models were originally proposed to bring order to the chaos of software
development.
A process model provides a specific roadmap for software engineering work. It defines
the flow of all activities, actions and tasks, the degree of iteration, the work products,
and the organization of the work that must be done.
THE WATERFALL PROCESS MODEL:
There are times when the requirements for a problem are well understood—when work
flows from communication through deployment in a reasonably linear fashion. This
situation is sometimes encountered when well-defined adaptations or enhancements to
an existing system must be made (e.g., an adaptation to accounting software that has
been mandated because of changes to government regulations). It may also occur in a
limited number of new development efforts but only when requirements are well defined
and reasonably stable.

1.Real projects rarely follow the sequential flow that the model proposes.Although the
linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty accommodating the natural uncertainty that exists
at the beginning of many projects.
INCREMENTAL PROCESS MODEL:
There are many situations in which initial software requirements are reasonably well
defined, but the overall scope of the development effort precludes a purely linear
process. In addition, there may be a compelling need to provide a limited set of software
functionality to users quickly and then refine and expand on that functionality in later
software releases. In such cases, you can choose a process model that is designed to
produce the software in increment.
EVOLUTIONARY PROCESS MODELS:
Evolutionary models are iterative. They are characterized in a manner that enables you
to develop increasingly more complete versions of the software.
Two common evolutionary process models are :
Prototyping Model
Spiral Model
Prototyping Process Model : Often, a customer defines a set of general objectives for
software but does not identify detailed requirements for functions and features. In other
cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of
an operating system, or the form that human-machine interaction should take. In these,
and many other situations, a prototyping paradigm may offer the best approach.
The Spiral Models : The spiral development model is a risk-driven process model
generator that is used to guide multi-stakeholder concurrent engineering of software
intensive systems. It has two main distinguishing features. One is a cyclic approach for
incrementally growing a system’s degree of definition and implementation while
decreasing its degree of risk. The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory system solutions. A spiral
model is divided into a set of framework activities defined by the software engineering
team. For illustrative purposes, we use the generic framework activities discussed
earlier.
CONCURRENT MODEL:
The concurrent development model, sometimes called concurrent engineering, allows a
software team to represent iterative and concurrent elements of any of the process
models described in this chapter. For example, the modeling activity defined for the
spiral model is accomplished by invoking one or more of the following software
engineering actions: prototyping, analysis and design.

Concurrent modeling is applicable to all types of software development and provides an

accurate picture of the current state of a project.
engineering activities, actions, and tasks to a sequence of events ,it defines a process
network. Each activity, action, or task on the network exists simultaneously with other
activities, actions, or tasks. Events generated at one point in the process network trigger
transitions among the states associated with each activity.
The Formal Method Model:
The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software. Formal methods enable you to specify,
develop, and verify a computer-based system by applying mathematical notation. A
variation on this approach, called cleanroom software engineering [Mil87, Dye92], is
currently applied by some software development organizations.
Team software process:
• Build self-directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams
(IPTs) of 3 to about 20 engineers.
• Show managers how to coach and motivate their teams and how to help them sustain
peak performance
• Accelerate software process improvement by making CMM 18 level 5
behavior normal and expected.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills
Process technology:
Process technology tools allow a software organization to build an automated model of
the process framework, task sets, and umbrella activities discussed in Chapter 3. The
model, normally represented as a network, can then be analyzed to determine typical
workflow and examine alternative process structures that might lead to reduced
development time or cost.
Product and process:
If the process is weak, the end product will undoubtedly suffer. But an obsessive
overreliance on process is also dangerous. In a brief essay written many years ago,
Margaret Davis [Dav95a] makes timeless products and processes.
CHAPTER - 5 : AGILE DEVELOPMENT

What is Agile?
Agile is an iterative approach to project management and software development that
helps teams deliver value to their customers faster and with fewer headaches. Instead
of betting everything on a "big bang" launch, an agile team delivers work in small, but
consumable, increments.
What is “Agility”?
● Agility can be applied to any software process.
● Effective (rapid and adaptive) response to change (team members, new
technology, requirements).
● Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers.
● Drawing the customer onto the team.
● Organizing a team so that it is in control of the work performed.
Yielding…
● Rapid, incremental delivery of software.

AGILITY AND THE COST OF CHANGE

Conventional wisdom is that the cost of change increases nonlinearly as a project
progresses. It is relatively easy to accommodate a change when a team is gathering
requirements early in a project. If there are any changes, the costs of doing this work
are minimal. But in the middle of validation testing, a stakeholder is requesting a major
functional change. Then the change requires a modification to the architectural design,
construction of new components, changes to other existing components, new testing
and so on. Costs escalate quickly.
A well-designed agile process may "flatten the cost of change curve by coupling
incremental delivery with agile practices such as continuous unit testing and pair
programming. Thus the team can accommodate changes late in the software project
without dramatic cost and time impact.
An Agile Process
An agile process is driven by customer descriptions of what is required (scenarios).
Some assumptions:
● Recognizes that plans are short-lived (some requirements will persist, some will
change.
● Customer priorities will change) Develops software iteratively with a heavy
emphasis on construction activities (design and construction are interleaved,
hard to say how much design is necessary before construction. Design models
are proven as they are created). Analysis, design, construction and testing are
not predictable.
● Thus has to Adapt as changes occur due to unpredictability Delivers multiple
‘software increments’, deliver an operational prototype or portion of an OS to
collect customer feedback for adaption.

Agile Principles
● The highest priority of this process is to satisfy the customer.
● Acceptance of changing requirements even late in development.
● Frequently deliver working software in a small time span.
● Throughout the project business people and developers work together on a daily
basis.
● Projects are created around motivated people if they are given the proper
environment and support.
● Face to face interaction is the most efficient method of moving information in the
development team.
● Primary measure of progress is working software.
● The Agile process helps in sustainable development.
● Continuous attention to technical excellence and good design increases agility.
● From self organizing teams the best architecture, design and requirements
emerged.
● Simplicity is necessary in development.

Extreme Programming (XP)

● Extreme Programming is a commonly used agile process model.
● It uses the concept of object-oriented programming.
● A developer focuses on the framework activities like planning, design, coding
and testing. XP has a set of rules and practices.
XP process diagram

The XP Process
The XP process comprises four framework activities:

1. Planning
● Planning starts with the requirements gathering which enables the XP team to
understand the rules for the software.
● The customer and developer work together for the final requirements.
2. Design
● The XP design follows the 'keep it simple' principle.
● A simple design always prefers the more difficult representation.
3. Coding
● The coding is started after the initial design work is over.
● After the initial design work is done, the team creates a set of unit tests which
can test each situation that should be a part of the release.
● The developer is focused on what must be implemented to pass the test.
● Two people are assigned to create the code. It is an important concept in
coding activity.
4. Testing
● Validation testing of the system occurs on a daily basis. It gives the XP team a
regular indication of the progress.
● 'XP acceptance tests' are known as the customer test.
XP values

Following are the values for extreme programming:

1. Communication
● Building a software development process needs communication between the
developer and the customer.
● Communication is important for requirement gathering and discussing the
concept.
2) Simplicity
The simple design is easy to implement in code.

3.Feedback
Feedback guides the development process in the right direction.

4.Courage
In every development process there will always be a pressure situation. The courage or
the discipline to deal with it surely makes the task easy.

5.Respect
The Agile process should inculcate the habit to respect all team members, other
stakeholders and customers.

OTHER AGILE PROCESS MODELS

Scrum
● Scrum is an agile software development method.
● Scrum principles are consistent with the agile platform that are used to guide
development activities within a process.
● It includes the framework activities like requirement, analysis, design, evolution
and delivery.
● Work tasks occur within a process pattern in each framework activity called
'sprint'.
● Scrum highlights the use of a set of software process patterns that are effective
for the projects with tight timelines, changing requirements and business
criticality.
● Scrum consists of the use of a set of software process patterns.

Agile Modeling
Agile Modeling (AM) is a practice-based methodology for effective modeling and
documentation of software-based systems. Simply put, Agile Modeling (AM) is a
collection of values, principles, and practices for modeling software that can be applied
on a software development project in an effective and light-weight manner. Agile
models are more effective than traditional models because they are just barely good,
they don’t have to be perfect.

Agile modeling adopts all of the values that are consistent with the agile manifesto. The
agile modeling philosophy recognizes that an agile team must have the courage to
make decisions that may cause it to reject a design and refactor. The team must also
have the humility to recognize that technologists do not have all the answers and that
business experts and other stakeholders should be respected and embraced.

Agile Unified Process (AUP)

Agile Unified Process (AUP) is a simplified version of the Rational Unified
Process (RUP) developed by Scott Ambert. It describes a simple, easy to understand
approach to developing business application software using agile techniques and
concepts yet still remaining true to the RUP. The AUP applies agile techniques
including test-driven development (TDD), agile modeling (AM), agile change
management, and database refactoring to improve productivity.
In 2011 the AUP accounted for one percent of all the agile methodologies used. [2] In
2012 the AUP was superseded by disciplined agile delivery (DAD). Since then work has
ceased on evolving AUP.

The AUP has only seven disciplines:

1. Model Understand the business of the organization, the problem domain

being addressed by the project, and identify a viable solution to address
the problem domain.
2. Implementation. Transform model(s) into executable code and perform a
basic level of testing, in particular unit testing.
3. Test. Perform an objective evaluation to ensure quality. This includes
finding defects, verifying that the system works as designed, and
validating that the requirements are met.
4. Deployment. Plan for the delivery of the system and to execute the plan
to make the system available to end users.
5. Configuration Management. Manage access to project artifacts. This
includes not only tracking artifact versions over time but also controlling
and managing changes to them.
6. Project Management. Direct the activities that take place within the
project. This includes managing risks, directing people (assigning tasks,
tracking progress, etc.), and coordinating with people and systems
outside the scope of the project to be sure that it is delivered on time and
within budget.
7. Environment. Support the rest of the effort by ensuring that the proper
process, guidance (standards and guidelines), and tools (hardware,
software, etc.) are available for the team as needed.
Chapter - 6 : Human Aspects of Software Engineering
Software is built by humans. To ensure adequate quality in the final product, we need to
create systems that humans can understand and reason about. We know systems grow
to be very large in terms of the amount of code, models, artifacts, documentation
amongst other things. This course investigates how we can ensure the human ingenuity
and smarts is being amplified by the processes and tools used rather than the humans
spending precious cognitive effort dealing with mundane or unnecessary problems.

Layered behavioral model of software engineering

The software team structure:

What is the team structure in software engineering?

A typical software development team structure includes a business analyst, a product

owner, a project manager, a product designer, a software architect, software
developers, software testing engineers, including test automation engineers, as well as
a DevOps engineer.

Constantine suggest four “organizational paradigms” for software engineering

teams:

1. A closed paradigm structure.

2. A random paradigm structure.
3. An open paradigm structure.
4. A synchronous paradigm structure.
●
The generic agile teams:

A “team” in the Agile sense is a small group of people, assigned to the same project
or effort, nearly all of them on a full-time basis. A small minority of team members
may be part-time contributors, or may have competing responsibilities.

The XP teams:

Extreme Programming (XP) is an agile software development framework that aims

to produce higher quality software, and higher quality of life for the development
team. XP is the most specific of the agile frameworks regarding appropriate engineering
practices for software development.

The impact of social media:

Software engineers make use of a variety of social media tools to coordinate with one
another, to communicate with and learn from users, to become informed about new
technologies and to create informal documentation.

Global teams:

Global Software Development (GSD) is carried out by teams of knowledge workers

located in various parts of the globe developing commercially viable software for a
company. Often, centralized software development is moved from “home” locations to
dispersed teams or/and external organizations in remote locations.

Decision making on all software teams is complicated by four factors;

● Complexity of the problem.

● Uncertainty and risk associated with the decision.
● The law of unintended consequences.
● Different views of the problem that lead to different conclusions
about the way forward.

Factors affecting GSD: