What is a framework?

A framework is a foundation for developing software applications. Software engineers

and developers use a framework as a template to create websites and applications.
Developers do this by adding code to a framework, then personalizing it for their specific
purpose.
A framework can combine multiple resources, such as an image or document file, to
create a package unique to a project. Even after an application is complete, coders can
revise the framework of an application to add new features or edit existing components.
Benefits of a framework
Frameworks are helpful tools for programmers and developers to use during the creation
of websites and other applications. Here are some of the benefits a framework can offer:
1.Saving software developers time and energy.
2.Providing a basic outline for coders to follow.
3.Allowing coders to focus on tasks more specific to their project.
4.Creating clean and adaptable code.
5.Reducing costs by shortening the amount of time a developer spends programming the
application.
6 types of frameworks

There are several types of frameworks. Developers define each by either the framework's
function or the main coding language they add to it. Here are some of the most popular
types of frameworks:
1. Web app framework
Developers use web app frameworks when designing a website. A web app framework
allows a software engineer's creations to function well on the internet, and they usually
have a higher rate of usability, making them inclusive to users. Websites require frequent
updates and changes and developers and coders benefit from using web app frameworks,
as they're easy to adjust.
2. Mobile app framework
A mobile app framework provides a general structure for developers to add onto to create
an application for mobile devices, such as smartphones. These frameworks are often
open-source, and developers can use a variety of coding languages to create them. While
the mobile app framework is often similar to a web app framework, this framework
allows software developers to format the application specifically for easy use on a
smartphone or tablet.
3. Technology framework
Software engineers generally use technology frameworks for business purposes. This
framework allows them to establish information technology (IT) systems within a
company's database. Uses for a technology framework can include security measures for
discrete data, management tools and common applications.
4. Enterprise architecture framework
An enterprise architecture framework provides a blueprint for complex IT systems within
a company. There are four major types of enterprise architecture frameworks, which
developers choose based on the framework's fit for their specific project.
5. Database framework
Software developers use database frameworks to manage a variety of database engines.
They also help developers perform database management tasks quickly and without
spending time and effort on additional programming.
6. Testing framework
Software developers use testing frameworks as guidelines for creating test cases. This
helps supply developers with tools and practices that allow them to complete quality
assurance tasks. Testing frameworks remind developers what to test for and how to
complete tests, and they ensure accuracy and efficiency in quality assurance practices.
Process Assessment and Improvement
The existence of a process is no guarantee that the software will be delivered on time,
meet the needs of the customer, or be of long-term quality.
There are several methods to assess software:
Standard CMMI Assessment Method for Process Improvement (SCAMPI)—provides a
five-step process assessment model : initiating, diagnosing, establishing, acting, and
learning.
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—provides a
diagnostic technique for assessing the relative maturity of a software organization.
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.
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.

Prescriptive Process Model in Software Engineering

Prescriptive process model were originally proposed to bring order to the chaos of
software development. Prescriptive process model define a prescribed set of process
elements and a predictable process work flow.
“prescriptive” because they prescribe a set of process elements framework activities,
software engineering actions, tasks, work products, quality assurance, and change control
mechanisms for each project.
Specialized Process Model in Software Engineering
Component Based Development
The component based development model incorporates many of the characteristics of the
spiral model. It is evolutionary in nature, Specialized process model demanding an
iterative approach to the creation of software.However, the component based
development model constructs 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 specialized process model incorporates the following steps.

1.Available component based products are researched and evaluated for the application
domain in question.
2.Component integration issues are considered.
3.A software architecture is designed to accommodate the components.
4.A software architecture is designed to accommodate the components.
5.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.
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 you to specify,
develop, and verify a computer based system by applying a rigorous, mathematical
notation.A variation on this approach, 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, 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 you to discover and correct errors that might otherwise go undetected.
Draw Backs:
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 models as a communication mechanism for Technically
unsophisticated customers.
The Unified Process in Software Engineering
Unified process (UP) is an architecture centric, use case driven, iterative and incremental
development process. UP is also referred to as the unified software development process.

The Unified Process is an attempt to draw on the best features and characteristics of
traditional software process models, but characterize them in a way that implements
many of the best principles of agile software development.

Phases of the Unified Process

This process divides the development process into five phases:

Inception
Elaboration
Conception
Transition
Production
The inception phase of the UP encompasses both customer communication and planning
activities. By collaborating with stakeholders, business requirements for the software are
identified; a rough architecture for the system is proposed; and a plan for the iterative,
incremental nature of the ensuing project is developed.

The elaboration phase encompasses the communication and modeling activities of the
generic process model.
Elaboration refines and expands the preliminary use cases that were developed as part of
the inception phase and expands the architectural representation to include five different
views of the software the use case model, the requirements model, the design model, the
implementation model, and the deployment model
Elaboration creates an “executable architectural baseline” that represents a “first cut”
executable system.
The construction phase of the UP is identical to the construction activity defined for the
generic software process. Using the architectural model as input, the construction phase
develops or acquires the software components that will make each use case operational
for end users.
To accomplish this, requirements and design models that were started during the
elaboration phase are completed to reflect the final version of the software increment. All
necessary and required features and functions for the software increment (the release) are
then implemented in source code.
The transition phase of the UP encompasses the latter stages of the generic construction
activity and the first part of the generic deployment (delivery and feedback) activity.
Software is given to end users for beta testing and user feedback reports both defects and
necessary changes. At the conclusion of the transition phase, the software increment
becomes a usable software release.
The production phase of the UP coincides with the deployment activity of the generic
process. During this phase, the ongoing use of the software is monitored, support for the
operating environment (infrastructure) is provided, and defect reports and requests for
changes are submitted and evaluated.
Personal and Team Process Model in Software Engineering
The best software process is personal and team process model one that is close to the
people who will be doing the work. Watts Humphrey proposed two process models.
Models “Personal Software Process (PSP)” and “Team Software Process (TSP).” Both
require hard work, training, and coordination, but both are achievable.
Personal Software Process (PSP):
The Personal Software Process (PSP) emphasizes personal measurement of both the work product that is
produced and the resultant quality of the work product.

The PSP model defines five framework activities:

Planning: This activity isolates requirements and develops both size and resource
estimates. In addition, defects estimate (the number of defects projected for the work) is
made. All metrics are recorded on worksheets or templates. Finally, development tasks
are identified and a project schedule is created.
High level design. External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.
High level design review. Formal verification methods are applied to uncover errors in
the design. Metrics are maintained for all important tasks and work results.
Development. The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
Postmortem. Using the measures and metrics collected, the effectiveness of the process
is determined. Measures and metrics should provide guidance for modifying the process
to improve its effectiveness.
Team Software Process (TSP)
Watts Humphrey extended the lessons learned from the introduction of PSP and proposed
a Team Software Process (TSP). The goal of TSP is to build a “self directed” project
team that organizes itself to produce high quality software.Humphrey defines the
following objectives for TSP:

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 CMM23 Level 5 behavior normal
and expected.
Provide improvement guidance to high-maturity organizations.
Facilitate university teaching of industrial-grade team skills
What is agility?
Agility means characteristics of being dynamic, content specific, aggressively change
embracing and growth oriented. Agile Software engineering Agile software engineering
combines a philosophy and a set of development guidelines. The philosophy encourages
customer satisfaction and early incremental delivery of software, small highly motivated
project teams, informal methods, minimal software engineering work products and
overall development simplicity. The development guidelines stress delivery over analysis
and design and active continuous communication between developers and customers. The
team of software engineers and other project stakeholders work together as an agile team
(a team that is self organizing and in control of its own destiny. An agile team fosters
communication and collaboration among all who serve on it. Agile Process The
Processes which are adaptable of changes in requirements, which have incrementality and
work on unpredictability. These processes are based on three assumptions which all do
refer to the unpredictability in different stages of software process development such
unpredictability at time requirements, at analysis and design or at time construction.So
these processes are adaptable at all stages on SDLC. .
Extreme Programming(XP) Extreme Programming uses an object-oriented approach as
its preferred development paradigm and encompasses a set of rules and practices that
occur within the context of four framework activities: planning, design, coding, and
testing. Key XP activities are summarized in the paragraphs that follow Planning. The
planning activity begins with listening—a requirements gathering activity that enables the
technical members of the XP team to understand the business context for the software
and to get a broad feel for required output and major features and functionality. Listening
leads to the creation of a set of “stories” or user stories that describe required output,
features, and functionality for software to be built. Each story is written by the customer
and is placed on an index card. The customer assigns a value (i.e., a priority) to the story
based on the overall business value of the feature or function. Members of the XP team
then assess each story and assign a cost—measured in development weeks—to it. If the
story is estimated to require more than three development weeks, the customer is asked to
split the story into smaller stories and the assignment of value and cost occurs again. It is
important to note that new stories can be written at any time. Customers and developers
work together to decide how to group stories into the next release (the next software
increment) to be developed by the XP team. Once a basic commitment is made for a
release, the XP team orders the stories that will be developed in one of three ways: (1) all
stories will be implemented immediately (within a few weeks), (2) the stories with
highest value will be moved up in the schedule and implemented first, or (3) the riskiest
stories will be moved up in the schedule and implemented first. After the first project
release (also called a software increment) has been delivered, the XP team computes
project velocity. Stated simply, project velocity is the number of customer stories
implemented during the first release. Project velocity can then be used to (1) help
estimate delivery dates and schedule for subsequent releases and (2) determine whether
an overcommitment has been made for all stories across the entire development project.
As development work proceeds, the customer can add stories, change the value of an
existing story, split stories, or eliminate them. The XP team then reconsiders all
remaining releases and modifies its plans accordingly. Design. XP design rigorously
follows the KIS (keep it simple) principle. A simple design is always preferred over a
more complex representation. XP encourages the use of CRC cards as an effective
mechanism for thinking about the software in an object-oriented context. CRC
(classresponsibility collaborator) cards identify and organize the object-oriented classes
that are relevant to the current software increment. The CRC cards are the only design
work product produced as part of the XP process. If a difficult design problem is
encountered as part of the design of a story, XP recommends the immediate creation of
an operational prototype of that portion of the design. Called a spike solution, the design
prototype is implemented and evaluated. The intent is to lower risk when true
implementation starts and to validate the original estimates for the story containing the
design problem A central notion in XP is that design occurs both before and after coding
commences. Refactoring means that design occurs continuously as the system is
constructed. In fact, the construction activity itself will provide the XP team with
guidance on how to improve the design. Coding. After stories are developed and
preliminary design work is done, the team does not move to code, but rather develops a
series of unit tests that will exercise each of the stories that is to be included in the current
release (software increment).8 Once the unit test9 has been created, the developer is
better able to focus on what must be implemented to pass the test. Nothing extraneous is
added (KIS). Once the code is complete, it can be unit-tested immediately, thereby
providing instantaneous feedback to the developers. A key concept during the coding
activity is pair programming. XP recommends that two people work together at one
computer workstation to create code for a story. This provides a mechanism for realtime
problem solving and real-time quality assurance It also keeps the developers focused on
the problem at hand. In practice, each person takes on a slightly different role. For
example, one person might think about the coding details of a particular portion of the
design while the other ensures that coding standards are being followed or that the code
for the story will satisfy the unit test that has been developed to validate the code against
the story. As pair programmers complete their work, the code they develop is integrated
with the work of others. In some cases this is performed on a daily basis by an integration
team. In other cases, the pair programmers have integration responsibility. This
“continuous integration” strategy helps to avoid compatibility and interfacing problems
and provides a “smoke testing” environment that helps to uncover errors early. Testing
The unit tests that are created should be implemented using a framework that enables
them to be automated This encourages a regression testing strategy whenever code is
modified As the individual unit tests are organized into a “universal testing suite”
[Wel99], integration and validation testing of the system can occur on a daily basis. This
provides the XP team with a continual indication of progress and also can raise warning
flags early if things go awry. Wells [Wel99] states: “Fixing small problems every few
hours takes less time than fixing huge problems just before the deadline.” XP acceptance
tests, also called customer tests, are specified by the customer and focus on overall
system features and functionality that are visible and reviewable by the customer.
Acceptance tests are derived from user stories that have been implemented as part of a
software release.
 Psychology in Software Engineering
Psychology plays an important role in the performance of this discipline, e.g. from team
management to requirements elicitation. However, our field can receive even more
benefits from this science.

From the very beginning of the project, we need to establish a communication with the
customer and try to elicit the requirements, which sometimes is difficult due to the differences
in the language that a technical person uses with respect to the customer. Many times we get
frustrated because requirements change a lot but, in my experience, a considerable amount of
times those changes are caused by communication problems.