21CS61 Software Engineering & Project Management Internal Assessment-II

1. Define a set of Modeling Principles that are intended for those who use the agile process model.

 Principle 1. The primary goal of the software team is to build software, not create models.
Agility means getting software to the customer in the fastest possible time. Models that make this happen are
worth creating, but models that slow the process down or provide little new insight should be avoided.

 Principle 2. Travel light—don’t create more models than you need.

Every model that is created must be kept up-to-date as changes occur. Therefore, create only those models that
make it easier and faster to construct the software.

 Principle 3. Strive to produce the simplest model that will describe the problem or the software. Don’t
overbuild the software [Amb02b]. By keeping models simple, the resultant software will also be simple. The
result is software that is easier to integrate, easier to test, and easier to maintain (to change).

 Principle 4. Build models in a way that makes them amenable to change.

Assume that your models will change, but in making this assumption don’t get sloppy. For example, since
requirements will change, there is a tendency to give requirements models short shrift. Why? Because you
know that they’ll change anyway. The problem with this attitude is that without a reasonably complete
requirements model, you’ll create a design (design model) that will invariably miss important functions and
features.

 Principle 5. Be able to state an explicit purpose for each model that is created.
Every time you create a model, ask yourself why you’re doing so. If you can’t provide solid justification for
the existence of the model, don’t spend time on it.

 Principle 6. Adapt the models you develop to the system at hand.

It may be necessary to adapt model notation or rules to the application; for example, a video game application
might require a different modeling technique than real-time, embedded software that controls an automobile
engine.

 Principle 7. Try to build useful models, but forget about building perfect models.
When building requirements and design models, a software engineer reaches a point of diminishing returns.
That is, the effort required to make the model absolutely complete and internally consistent is not worth the
benefits of these properties. Iterating endlessly to make a model “perfect” does not serve the need for agility.

 Principle 8. Don’t become dogmatic about the syntax of the model.

If it communicates content successfully, representation is secondary. Although everyone on a software team
should try to use consistent notation during modeling, the most important characteristic of the model is to
communicate information that enables the next software engineering task. If a model does this successfully,
incorrect syntax can be forgiven.

 Principle 9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably
have reason to be concerned.
If you are an experienced software engineer, trust your instincts. If something tells you that a design model is
doomed to fail you have reason to spend additional time examining the model or developing a different one.

 Principle 10. Get feedback as soon as you can.

Every model should be reviewed by members of the software team. The intent of these reviews is to provide
feedback that can be used to correct modeling mistakes, change mis interpretations, and add features or
functions that were inadvertently omitted.
2. Summarize the different elements of the Design Modeling Principles.
The software design model is analogous to an architect’s plans for a house. It begins by representing the totality of
the thing to be built and slowly refines the thing to provide guidance for constructing each detail. Similarly, the
design model that is created for software provides a variety of different views of the system.
The set of design principles that can be applied regardless of the method that is used:

 Principle 1. Design should be traceable to the requirements model.

The design model translates requirements model information into an architecture, a set of subsystems that
implement major functions, and a set of components that are the realization of requirements classes. The
elements of the design model should be traceable to the requirements model.

 Principle 2. Always consider the architecture of the system to be built.

Software architecture is the skeleton of the system to be built. Design should start with architectural
considerations. Only after the architecture has been established should component-level issues be considered.

 Principle 3. Design of data is as important as design of processing functions.

Data design is an essential element of architectural design. A well-structured data design helps to simplify
program flow, makes the design and implementation of software components easier, and makes overall
processing more efficient.

 Principle 4. Interfaces (both internal and external) must be designed with care.
A well-designed interface makes integration easier and assists the tester in validating component functions.

 Principle 5. User interface design should be tuned to the needs of the end user.
However, in every case, it should stress ease of use. A poor interface design often leads to the perception that
the software is “bad.”

 Principle 6. Component-level design should be functionally independent.

Functional independence is a measure of the “single-mindedness” of a software component. The functionality
that is delivered by a component should be cohesive.

 Principle 7. Components should be loosely coupled to one another and to the external environment.
Coupling is achieved in many ways— via a component interface, by messaging, through global data. A
component coupling should be kept as low as is reasonable.

 Principle 8. Design representations (models) should be easily understand able .

The purpose of design is to communicate information to practitioners who will generate code, to those who
will test the software, and to others who may maintain the software in the future. If the design is difficult to
understand, it will not serve as an effective communication medium.

 Principle 9. The design should be developed iteratively.

With each iteration, the designer should strive for greater simplicity. The first iterations work to refine the
design and correct errors, but later iterations should strive to make the design as simple as is possible.

3. What is an Extreme Programming (XP)? Explain its different kinds.

Extreme programming (XP) is the most widely used agile process. Organized as four framework activities—
planning, design, coding, and testing—XP suggests a number of innovative and powerful techniques that allow an
agile team to create frequent software releases that deliver features and functionality that have been described and
then prioritized by stakeholders.
a) Industrial XP: Joshua Kerievsky [Ker05] describes Industrial Extreme Programming (IXP) in the following
manner: “IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric, test-driven
spirit. IXP differs most from the original XP in its greater inclusion of management, its expanded role for
 customers, and its upgraded technical practices.” IXP incorporates six new practices that are designed to help
ensure that an XP project works successfully for significant projects within a large organization.
 Readiness assessment. Prior to the initiation of an IXP project, the organization should conduct a readiness
assessment.
 Project community. Classic XP suggests that the right people be used to populate the agile team to ensure
success. The implication is that people on the team must be well-trained, adaptable and skilled, and have the
proper temperament to contribute to a self-organizing team.
 Project chartering. The IXP team assesses the project itself to determine whether an appropriate business
justification for the project exists and whether the project will further the overall goals and objectives of the
organization.
 Test-driven management. An IXP project requires measurable criteria for assessing the state of the project and
the progress that has been made to date.
 Retrospectives. An IXP team conducts a specialized technical review after a software increment is delivered.
Called a retrospective. The intent is to improve the IXP process.
 Continuous learning. Because learning is a vital part of continuous process improvement, members of the XP
team are encouraged to learn new methods and techniques that can lead to a higher quality product.

b) The XP Debate: All new process models and methods spur worthwhile discussion and in some in stances
heated debate. Extreme Programming has done both. Proponents counter that XP is continuously evolving and
that many of the issues raised by critics have been addressed as XP practice matures.
Among the issues that continue to trouble some critics of XP are:
 Requirements volatility. Because the customer is an active member of the XP team, changes to requirements
are requested informally.
 Conflicting customer needs. Many projects have multiple customers, each with his own set of needs. In XP,
the team itself is tasked with assimilating the needs of different customers, a job that may be beyond their
scope of authority.
 Requirements are expressed informally. User stories and acceptance tests are the only explicit manifestation of
requirements in XP. Critics argue that a more formal model or specification is often needed to ensure that
omissions, inconsistencies, and errors are uncovered before the system is built. Proponents counter that the
changing nature of requirements makes such models and specification obsolete almost as soon as they are
developed.
 Lack of formal design. XP deemphasizes the need for architectural design and in many instances, suggests that
design of all kinds should be relatively informal. Critics argue that when complex systems are built, design
must be emphasized to ensure that the overall structure of the software will exhibit quality and maintainability.
XP proponents suggest that the incremental nature of the XP process limits complexity (simplicity is a core
value) and therefore reduces the need for extensive design.

4. Demonstrate all the Agile Modeling (AM) principles and Agile unified process (AUP) activities.

a) 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.
 Model with a purpose. A developer who uses AM should have a specific goal in mind before creating the
model. Once the goal for the model is identified, the type of notation to be used and level of detail
required will be more obvious.
 Use multiple models. There are many different models and notations that can be used to describe
software. Only a small subset is essential for most projects.
  Travel light. As software engineering work proceeds, keep only those models that will provide long-term
value and jettison the rest. Every work product that is kept must be maintained as changes occur.
 Content is more important than representation. Modeling should impart information to its intended
audience. A syntactically perfect model that imparts little useful content is not as valuable as a model with
flawed notation that nevertheless provides valuable content for its audience.
 Know the models and the tools you use to create them. Understand the strengths and weaknesses of each
model and the tools that are used to create it.
 Adapt locally. The modeling approach should be adapted to the needs of the agile team.

b) Agile Unified Process (AUP) The Agile Unified Process (AUP) adopts a “serial in the large” and “iterative in
the small” [Amb06] philosophy for building computer-based systems. By adopting the classic UP phased
activities—inception, elaboration, construction, and transition—AUP provides a serial overlay (i.e., a linear
sequence of software engineering activities) that enables a team to visualize the overall process flow for a
software project.
 Modeling. UML representations of the business and problem domains are created. However, to stay agile,
these models should be “just barely good enough” [Amb06] to allow the team to proceed.
 Implementation. Models are translated into source code.
 Testing. Like XP, the team designs and executes a series of tests to uncover errors and ensure that the source
code meets its requirements.
 Deployment. Deployment in this context focuses on the delivery of a software increment and the acquisition
of feedback from end users.
 Configuration and project management. In the context of AUP, configuration management addresses change
management, risk management, and the control of any persistent work products that are produced by the team.
Project management tracks and controls the progress of the team and coordinates team activities.
 Environment management. Environment management coordinates a process infrastructure that includes
standards, tools, and other support technology available to the team.

5. Briefly explain UML Models with use Case.

There are many requirements modeling situations in which a text-based model— even one as simple as a use case
—may not impart information in a clear and con cise manner. In such cases, you can choose from a broad array of
UML graphical models.
Developing an Activity Diagram: The UML activity diagram supplements the use case by providing a graphical
representation of the flow of interaction within a specific scenario. Similar to the flowchart, an activity diagram
uses rounded rectangles to imply a specific system function, arrows to represent flow through the system, decision
diamonds to depict a branching decision (each arrow emanating from the diamond is labelled), and solid
horizontal lines to indicate that parallel activities are occurring. An activity diagram for the ACS-DCV use case is
shown in Figure 6.5.
Swimlane Diagrams: 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. Three analysis classes—Homeowner, Camera, and
Interface—have direct or indirect responsibilities in the context of the activity diagram represented in Figure 6.5.
Referring to Figure 6.6, the activity diagram is rearranged so that activities associated with a particular analysis
class fall inside the swimlane for that class. For example, the Interface class represents the user interface as seen
by the homeowner. The activity diagram notes two prompts that are the responsibility of the interface— “prompt
for re-entry” and “prompt for another view.” These prompts and the decisions associated with them fall within the
Interface swimlane. However, arrows lead from that swim lane back to the Homeowner swimlane, where
homeowner actions occur.

6. Illustrate the Data Modeling Concepts with an Example.

Data modeling is used to describe the information space that will be constructed or manipulated by the software.
Data modeling begins by representing data objects—composite information that must be understood by the
software. The attributes of each data object are identified and relationships between data objects are described. If
software requirements include the need to create, extend, or interface with a data base or if complex data
structures must be constructed and manipulated, the software team may choose to create a data model as part of
overall requirements modeling. A software engineer or analyst defines all data objects that are processed within
the system, the relationships between the data objects, and other information that is pertinent to the relationships.
The entity-relationship diagram (ERD) addresses these issues and represents all data objects that are entered,
stored, transformed, and produced within an application.

Data Objects: A data object is a representation of composite information that must be understood by software. By
composite information, I mean something that has a number of dif ferent properties or attributes. Therefore, width
(a single value) would not be a valid data object, but dimensions (incorporating height, width, and depth) could be
defined as an object. A data object can be an external entity (e.g., anything that produces or consumes
information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a
role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a
structure (e.g., a file). For example, a person or a car can be viewed as a data object in the sense that either can be
defined in terms of a set of attributes. The description of the data object incorporates the data object and all of its
attributes.

Data Attributes: Data attributes define the properties of a data object and take on one of three different
characteristics. They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make
reference to another instance in another table. In addition, one or more of the attributes must be defined as an
identifier—that is, the identifier attribute becomes a “key” when we want to find an instance of the data object. In
some cases, values for the identifier(s) are unique, although this is not a requirement. Refer ring to the data object
car, a reasonable identifier might be the ID number.

Relationships: Data objects are connected to one another in different ways. Consider the two data objects, person
and car. These objects can be represented using the simple notation illustrated in Figure 6.8a. A connection is
established between person and car because the two objects are related. But what are the relationships? To
determine the answer, you should understand the role of people (owners, in this case) and cars within the context
of the software to be built. You can establish a set of object/ relationship pairs that define the relevant
relationships. For example, • A person owns a car. • A person is insured to drive a car.

7. Narrate the different elements of the Communication Principles.

Before customer requirements can be analyzed, modeled, or specified they must be gathered through the
communication activity. A customer has a problem that may be amenable to a computer-based solution. You
respond to the customer’s request for help. Communication has begun. But the road from communication to
understanding is often full of potholes.
 Principle 1. Listen. Try to focus on the speaker’s words, rather than formulating your response to those words.
Never become contentious in your words or actions as a person is talking.
 Principle 2. Prepare before you communicate. Spend the time to understand the problem before you meet with
others. If necessary, do some research to understand business domain jargon.
 Principle 3. Someone should facilitate the activity. Every communication meeting should have a leader (a
facilitator) to keep the conversation moving in a productive direction, (2) to mediate any conflict that does
occur, and (3) to ensure than other principles are followed.
 Principle 4. Face-to-face communication is best. But it usually works better when some other representation
of the relevant information is present
 Principle 5. Take notes and document decisions. Things have a way of falling into the cracks. Someone
participating in the communication should serve as a “recorder” and write down all important points and
decisions.
 Principle 6. Strive for collaboration. Collaboration and consensus occur when the collective knowledge of
members of the team is used to describe product or system functions or features.
 Principle 7. Stay focused; modularize your discussion. The more people involved in any communication, the
more likely that discussion will bounce from one topic to the next. The facilitator should keep the
conversation modular, leaving one topic only after it has been resolved.
 Principle 8. If something is unclear, draw a picture. Verbal communication goes only so far. A sketch or
drawing can often provide clarity when words fail to do the job.
 Principle 9. (a) Once you agree to something, move on. (b) If you can’t agree to something, move on. (c) If a
feature or function is unclear and cannot be clarified at the moment, move on. Communication, like any
software engineering activity, takes time. Rather than iterating endlessly, the people who participate should
recognize that many topics require discussion and that “moving on” is sometimes the best way to achieve
communication agility.
 Principle 10. Negotiation is not a contest or a game. It works best when both parties win. There are many
instances in which you and other stakeholders must negotiate functions and features, priorities, and delivery
dates. If the team has collaborated well, all parties have a common goal. Still, negotiation will demand
compromise from all parties.