MCA403T: ADVANCED SOFTWARE ENGINEERING

Total Teaching Hours: 52 No. of Hours / Week: 04

UNIT - I
Agile development: Agile, Agility and cost of change; Agile Process, Extreme
programming; Other agile process models. Web Application Design: Web
application design quality; Design quality and design pyramid; Interface design;
Aesthetic design; Content design; Architecture design; Navigation design;
Component-level design; Object-oriented hypermedia design method.
UNIT - II
Formal Modeling and verification: The cleanroom strategy; Functional
specification; Cleanroom design; Cleanroom testing; Formal methods: Concepts;
Applying mathematical notation for formal specification; Formal specification
languages. Software Project Management: The management spectrum; The
management of people, product, process and project; The W5HH Principle;
Critical practices. Estimation for Software Projects: Software project estimation;
Decomposition techniques, Examples; Empirical estimation models; Estimation
for Object-Oriented projects; Specialized estimation techniques; The make / buy
decision.
UNIT - III
Software Project Scheduling: Basic concepts and principles of project scheduling;
Defining task set and task network; Scheduling; Earned value analysis. Risk
Management: Reactive versus proactive strategies; Software risks; risk
identification; Risk projection; Risk refinement; Risk mitigation, monitoring and
management; The RMMM plan. Maintenance and Reengineering: Software
maintenance; Software supportability; Reengineering; Business process
reengineering; Software reengineering; Reverse engineering; Restructuring;
Forward engineering; The economics of reengineering.
UNIT - IV
Software Process Improvement (SPI): Approaches to SPI; Maturity models; The
SPI process; The CMMI; The People CMM; Other SPI frameworks: SPICE,
Bootstrap, PSP and TSP, ISO; SPI return on investment.
UNIT - V
Software Configuration Management (SCM): Basic concepts; SCM repository;
The SCM process; Configuration management for web applications; SCM
standards. Product Metrics: A framework for product metrics; Metrics for
requirements model, design model, source code, testing and maintenance; Design
metrics for web applications. Process and Project Metrics: Basic concepts;
Software measurement; Metrics for software quality; Integrating metrics within
the software process; Metrics for small organizations; Establishing a software
metrics program.
Reference
1. Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”,
Alternate Edition, 7th Edition, McGraw Hill, 2010.
2. Ian Sommerville, “Software Engineering”, 8th Edition, Pearson, 2012.
 UNIT - I
Introduction:
Software development processes that plan on completely
specifying the requirements and then designing, building, and
testing the system are not geared to rapid software development.

As the requirements change or as requirements problems are

discovered, the system design or implementation has to be
reworked and retested.
As a consequence, a conventional waterfall or specification-
based process is usually prolonged and the final software is
delivered to the customer long after it was originally specified.

Rapid software development processes are designed to

reduce useful software quickly.
The software is not developed as a single unit but as a series of
increments, with each increment including new system
functionality.

Traditional software development:

 Project planning, formalized quality assurance, the use of
analysis and design methods supported by CASE tools.

 Controlled and rigorous software development processes.

 These plan driven approaches involve a significant

overhead in planning, designing, and documentingthe
system.

 More time is spent on how the system should be developed

than on program development and testing
Agile development:
 Dissatisfaction with these heavyweight approaches to
software engineering led a number of software developers
in the 1990s to propose new ‘agile methods’.

 These allowed the development team to focus on the

software itself rather than on its design .

 Agile methods universally rely on an incremental

approach to software specification, development, and
delivery.
 They are best suited to application development where the
system requirements usually change rapidly during the
development process.
 They are intended to deliver working software quickly to
customers, who can then propose new and changed
requirements to be included in later iterations of the system.

Agile is a software development methodology to build a

software incrementally using short iterations of 1 to 4 weeks
so that the development process is aligned with the changing
business needs.
Instead of a single-pass development of 6 to 18 months where
all the requirements and risks are predicted upfront, Agile adopts
a process of frequent feedback where a workable product is
delivered after 1 to 4-week iteration.

The Manifesto for Agile Software Development

The philosophy behind agile methods is reflected in the agile
manifesto that was agreed on by many of the leading
developers of these methods.
This manifesto states:
“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value
the items on the left more.”-Kent Beck et al

Define /What is “Agility”? (2m)

Agility can be defined as
 Effective (rapid and adaptive) response to changes
 Effective communication among all stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of the work
performed
And resulting in Rapid, incremental delivery of software

 An agile team is a nimble(active) team able to appropriately

respond to changes.
 It emphasizes rapid delivery of operational software
 it adopts the customer as a part of the development team
 it recognizes that project plan must be flexible.

Agility can be applied to any software process.

 the process be designed in a way that allows the project
team to adapt tasks and to streamline them,
  conduct planning in a way that understands the fluidity of
an agile development approach,
 emphasize an incremental delivery strategy that gets
working software to the customer as rapidly as feasible for
the product type and operational environment.

Agility and cost of change

An agile process reduces the cost of change because
 software is released in increments and
 change can be better controlled within an increment.
 well-designed agile process “flattens” the cost of change
curve ( shaded, solid curve), allowing a software team to
accommodate changes late in a software project without
dramatic cost and time impact.

Agile Process (2m)

 Is driven by customer descriptions of what is required
(scenarios)
 Recognizes that plans are short-lived
  Develops software iteratively with a heavy emphasis on
construction activities
 Delivers multiple ‘software increments’
 Adapts as changes occur

Agility Principles (2m)

1. Customer satisfaction through early and continuous software
delivery.
2. Accommodate changing requirements throughout the
development process
3. Frequent delivery of working software
4. Collaboration between the business stakeholders and
developers throughout the project.
5. Support, trust, and motivate the people involved .
6. Enable face-to-face interactions
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good
design enhances agility.
10. Simplicity – Develop just enough to get the job done for right
now
11. The best architectures, requirements, and designs emerge
from self–organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Extreme programming; ( 6m)
The most widely used agile process, originally proposed by Kent
Beck
I. XP Planning
 Begins with the creation of “user stories” by listening
to the user. User stories describe required output,
features, and functionality for software to be built
 Customer assigns a value to the story.
 Agile team assesses each story and assigns a cost
 Stories are grouped to for a deliverable increment
 A commitment is made on delivery date
 After the first increment “project velocity” is used to
help define subsequent delivery dates for other
increments.
Project velocity is a subtle measure of team
productivity.
Project velocity can then be used to
(1) help estimate delivery dates and schedule for
subsequent releases and
(2) determine whether an over commitment has been
made for all stories across the entire development
project.
II. XP Design
 Follows the KIS (Keep It Simple) principle.
 Encourage the use of CRC cards (class-
responsibility collaborator)
-cards identify and organize the object-oriented
 classes that are relevant to the current software
increment. 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

For difficult design problems, suggests the creation of

“spike solutions”.
Spike solution: immediate creation of an
operational prototype of that portion of the design.

 Encourages “refactoring”—an iterative refinement

of the internal program design.

Refactoring is the process of changing a software

system in such a way that it does not alter the external
behavior of the code yet improves the internal
structure.
III. XP Coding
 Recommends the construction of a unit test for a story
before coding commences
 Encourages “pair programming”. XP recommends that
two people work together at one computer workstation
to create code for a story.
IV. XP Testing
 creation of unit tests before coding commences is a
key element of the XP approach
 All unit tests are executed daily (whenever code is
modified)
  “Acceptance tests” are defined by the customer and
executed to assess customer visible functionality

The Extreme Programming process

Other agile process models.

the most widely used of all agile process models is Extreme Programming (XP).
But many other agile process models have been proposed and are in use across
the industry.
Among the most common are:
• Adaptive Software Development (ASD)
• Scrum
• Dynamic Systems Development Method (DSDM)
 • Crystal
• Feature Drive Development (FDD)
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
Adaptive Software Development
 Mission-driven planning
 Component-based focus
 Uses “time-boxing” (a timebox is a defined period of time during which a
task must be accomplished).

 Explicit consideration of risks

 Emphasizes collaboration for requirements gathering
 Emphasizes “learning” throughout the process
Dynamic Systems Development Method
• Active user involvement is imperative.
• DSDM teams must be empowered to make decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential criterion for
acceptance of deliverables.
• Iterative and incremental development is necessary to
converge on an accurate business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.
Scrum
• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is
constructed
 • Work occurs in “sprints” and is derived from a “backlog” of
existing requirements
• Meetings are very short and sometimes conducted without chairs
• “Demos” are delivered to the customer with the time-box allocated

Web Application Design

Design for WebApps encompasses technical and nontechnical
activities that include:
 Establishing the look and feel of the WebApp,
 creating the aesthetic layout of the user interface,
 defining the overall architectural structure,
 developing the content and functionality that reside within the architecture,
and
 planning the navigation that occurs within the WebApp.

WebApp design encompasses six major steps that are driven by information
obtained during requirements modeling.
 Content design uses the content model (developed during analysis) as the
basis for establishing the design of content objects.
 Aesthetic design (also called graphic design) establishes the look and feel
that the end user sees.
 Architectural design focuses on the overall hypermedia structure of all
content objects and functions.
 Interface design establishes the layout and interaction mechanisms that
define the user interface.
 Navigation design defines how the end user navigates through the
hypermedia structure, and
 component design represents the detailed internal structure of functional
elements of the WebApp.
WEBAPP DESIGN QUALITY (5m)
major quality attributes are:
1)Security:
• Security
– Rebuff external attacks
– Exclude unauthorized access
– Ensure the privacy of users/customers

The key measure of security is the ability of the WebApp and its server
environment to deny unauthorized access and prevent an outright malicious
attack.

2)Availability:
 Even the best WebApp will not meet users’ needs if it is unavailable.
 In a technical sense, availability is the measure of the percentage of time
that a WebApp is available for use.
 The typical end user expects WebApps to be available 24/7/365.
 Anything less is deemed unacceptable.

3)Scalability
– Can the WebApp and the systems with which it is interfaced handle
significant variation in user or transaction volume
4)Time to Market

Quality Dimensions for End-Users

• Time
– How much has a Web site changed since the last upgrade?
– How do you highlight the parts that have changed?
• Structural
– How well do all of the parts of the Web site hold together.
– Are all links inside and outside the Web site working?
– Do all of the images work?
– Are there parts of the Web site that are not connected?
• Content
– Does the content of critical pages match what is supposed to be
there?
– Do key phrases exist continually in highly-changeable pages?
– Do critical pages maintain quality content from version to version?
– What about dynamically generated HTML pages?
• Accuracy and Consistency
– Are today's copies of the pages downloaded the same as yesterday's?
Close enough?
– Is the data presented accurate enough? How do you know?
 • Response Time and Latency
– Does the Web site server respond to a browser request within certain
parameters?
– In an E-commerce context, how is the end to end response time after
a SUBMIT?
– Are there parts of a site that are so slow the user declines to continue
working on it?
• Performance
– Is the Browser-Web-Web site-Web-Browser connection quick
enough?
– How does the performance vary by time of day, by load and usage?
Is performance adequate for E-commerce applications?

WebApp Design Goals (2m)

Identity
Establish an “identity” that is appropriate for the business
purpose
Robustness
The user expects robust content and functions that are relevant to
the user’s needs
Navigability
designed in a manner that is intuitive and predictable
Visual appeal
the look and feel of content, interface layout, color
coordination, the balance of text, graphics and other media,
navigation mechanisms must appeal to end-users
Compatibility
With all appropriate environments and configurations
A DESIGN PYRAMID FOR WEBAPPS

A design pyramid for Web Apps

Each level of the pyramid represents a design action that is

described in the sections that follow.

I. INTERFACE DESIGN

The objectives of a WebApp interface are to:

(1) establish a consistent window into the content and

functionality provided by the interface,
(2) guide the user through a series of interactions with the
WebApp
(3) organize the navigation options and content available
to the user.

What interaction mechanisms are available to

WebApp designers?
To implement navigation options, you can select from
one of a number of interaction mechanisms:

• Navigation menus—keyword menus (organized

vertically or horizontally) that list key content and/or
functionality. These menus may be implemented so
that the user can choose from a hierarchy of
subtopics that is displayed when the primary menu
option is selected.

• Graphic icons—button, switches, and similar

graphical images that enable the user to select
some property or specify a decision.
• Graphic images—some graphical representation
that is selectable by the user and implements a link
to a content object or WebApp functionality.
Effective WebApp Interfaces

Effective interfaces are visually apparent and forgiving,

instilling in their users a sense of control. Users quickly
see the breadth of their options, grasp how to achieve
their goals, and do their work.
Effective interfaces do not concern the user with the
inner workings of the system. Work is carefully and
continuously saved, with full option for the user to undo
any activity at any time.

Effective applications and services perform a maximum

of work, while requiring a minimum of information from
users.

II. AESTHETIC DESIGN

Aesthetic design, also called graphic design, is an artistic
effort that complements the technical aspects of
WebApp design
 Don’t be afraid of white space.
It is inadvisable to pack every square inch of a
Web page with information. The resulting
clutter makes it difficult for the user to identify
needed information or features and create
visual chaos that is not pleasing to the eye.
 Emphasize content.
the typical Web page should be 80 percent
content with the remaining real estate
dedicated to navigation and other features
 Organize layout elements from top-left to bottom
right.
Group navigation, content, and function
geographically within the page.
  Don’t extend your real estate with the scrolling
bar.
Although scrolling is often necessary, most
studies indicate that users would prefer not to
scroll. It is better to reduce page content or to
present necessary content on multiple pages.
Consider resolution and browser window size when
designing layout

III. CONTENT DESIGN

 Develops a design representation for content
objects
 Represents the mechanisms required to
instantiate their relationships to one another.

 A content object has attributes that include

content-specific information and
implementation-specific attributes that are
specified as part of design

IV. ARCHITECTURE DESIGN

 Content architecture focuses on the manner in
which content objects (or composite objects such
as Web pages) are structured for presentation
and navigation.
The design of content architecture focuses on
the definition of the overall hypermedia
structure of the WebApp
  WebApp architecture describes an infrastructure
that enables a Web-based system or application
to achieve its business objectives.
 Architecture design is conducted in parallel with
interface design, aesthetic design and content
design.

The four different content structures are as follows:

1. Linear structures are encountered when a
predictable sequence of interactions (with some
variation or diversion) is common.
A classic example might be a tutorial presentation in
which pages of information along with related graphics,
short videos, or audio are presented only after
prerequisite information has been presented.

2. Grid structures are an architectural option that you

can apply when WebApp content can be organized
categorically in twodimensions. For
example, consider a situation in which an e-commerce
site sells golf clubs. The horizontal dimension of the grid
represents the type of club to be sold (e.g., woods, irons,
wedges, putters). The vertical dimension represents the
offerings provided by various golf club manufacturers.

3. Hierarchical structures are undoubtedly the most

common WebApp architecture. WebApp
hierarchical structure can be designed in a manner
that enables (via hypertext branching) flow of
control horizontally across vertical branches of the
structure. Hence, content presented on the far
left-hand branch of the hierarchy can have
hypertext links that lead directly to content that
exists in the middle or right-hand branch of the
structure. It should be noted, however, that
although such branching allows rapid navigation
across WebApp content, it can lead to confusion on the
part of the user.
4. A networked or “pure web” structure is similar in
many ways to the architecture that evolves for
object-oriented systems. Architectural components
are designed so that they may pass control (via
hypertext links) to virtually every other component
in the system. This approach allows considerable
navigation flexibility, but at the same time, can be
confusing to a user

V. NAVIGATION DESIGN
Navigation design represents the navigational flow
between content objects and for all WebApp functions.

Navigation semantics are defined by describing a set of

navigation semantic units. Each unit is composed of
ways of navigating and navigational links and nodes.
 As each user interacts with the WebApp, she
encounters a series of navigation semantic units
(NSUs)
NSU—“a set of information and related navigation
structures that collaborate in the fulfillment of a subset
of related user requirements

Navigation syntax depicts the mechanisms used for

effecting the navigation described as part of the
semantics.

VI. COMPONENT DESIGN

develops the detailed processing logic required to
implement functional components that implement a
complete WebApp function

WebApp components implement the following

functionality:
 perform localized processing to generate content
and navigation capability in a dynamic fashion
 provide computation or data processing capability
that are appropriate for the WebApp’s business
domain
 provide sophisticated database query and access
 establish data interfaces with external corporate
systems.