Unit 5

Software project management

Software project management is an essential part of software engineering. Projects need to
be managed because professional software engineering is always subject to organizational
budget and schedule constraints. The project manager’s job is to ensure that the software
project meets and overcomes these constraints as well as delivering high-quality software.

The success criteria for project management obviously vary from project to project, but, for
most projects, important goals are:

■ to deliver the software to the customer at the agreed time;

■ to keep overall costs within budget;

■ to deliver software that meets the customer’s expectations;

■ to maintain a coherent and well-functioning development team.

It is impossible to write a standard job description for a software project manager. The job
varies tremendously depending on the organization and the software being developed.
Some of the most important factors that affect how software projects are managed are:

1. Company size Small companies can operate with informal management and team
communications and do not need formal policies and management structures. They have
less management overhead than larger organizations. In larger organizations, management
hierarchies, formal reporting and budgeting, and approval processes must be followed.

2. Software customers If the customer is an internal customer (as is the case for software
product development), then customer communications can be informal and there is no
need to fit in with the customer’s ways of working. If custom software is being developed
for an external customer, agreement has to be reached on more formal communication
channels. If the customer is a government agency, the software company must operate
according to the agency’s policies and procedures, which are likely to be bureaucratic.

3. Software size Small systems can be developed by a small team, which can get together in
the same room to discuss progress and other management issues. Large systems usually
need multiple development teams that may be geographically distributed and in different
companies. The project manager has to coordinate the activities of these teams and arrange
for them to communicate with each other.

4. Software type If the software being developed is a consumer product, formal records of
project management decisions are unnecessary. On the other hand, if a safety-critical
system is being developed, all project management decisions should be recorded and
justified as these may affect the safety of the system.

5. Organizational culture Some organizations have a culture that is based on supporting

and encouraging individuals, while others are group focused. Large organizations are often
bureaucratic. Some organizations have a culture of taking risks, whereas others are risk
averse.

6. Software development processes Agile processes typically try to operate with

“lightweight” management. More formal processes require management monitoring to
ensure that the development team is following the defined process.

Fundamental project management activities are common to all organizations:

1. Project planning Project managers are responsible for planning, estimating, and
scheduling project development and assigning people to tasks. They supervise the work to
ensure that it is carried out to the required standards, and they monitor progress to check
that the development is on time and within budget.

2. Risk management Project managers have to assess the risks that may affect a project,
monitor these risks, and take action when problems arise. Risk management is one of the most
important jobs for a project manager. Product risks affect the quality or performance of the software
being developed. An example of a product risk is the failure of a purchased component to performas
expected. This may affect the overall performance of the system so that it is slower than expected.

3. People management Project managers are responsible for managing a team of people.
They have to choose people for their team and establish ways of working that lead to
effective team performance.

4. Reporting Project managers are usually responsible for reporting on the progress of a
project to customers and to the managers of the company developing the software. They
have to be able to communicate at a range of levels, from detailed technical information to
management summaries. They have to write concise, coherent documents that abstract
critical information from detailed project reports. They must be able to present this
information during progress reviews.

5. Proposal writing The first stage in a software project may involve writing a proposal to
win a contract to carry out an item of work. The proposal describes the objectives of the
project and how it will be carried out. It usually includes cost and schedule estimates and
justifies why the project contract should be awarded to a particular organization or team.
Proposal writing is a critical task as the survival of many software companies depends on
having enough proposals accepted and contracts awarded.

Risk management
Risk management is one of the most important jobs for a project manager. You can think of
a risk as something that you’d prefer not to have happen. Risks may threaten the project,
the software that is being developed, or the organization. Risk management involves
anticipating risks that might affect the project schedule or the quality of the software being
developed, and then taking action to avoid these risks.

Types of risk:

1. Project risks affect the project schedule or resources. An example of a project risk is the
loss of an experienced system architect. Finding a replacement architect with appropriate
skills and experience may take a long time; consequently, it will take longer to develop the
software design than originally planned.

2. Product risks affect the quality or performance of the software being developed. An
example of a product risk is the failure of a purchased component to perform as expected.
This may affect the overall performance of the system so that it is slower than expected.

3. Business risks affect the organization developing or procuring the software. For example,
a competitor introducing a new product is a business risk. The introduction of a competitive
product may mean that the assumptions made about sales of existing software products
may be unduly optimistic.

Stages:

1. Risk identification You should identify possible project, product, and business risks.

2. Risk analysis You should assess the likelihood and consequences of these risks.

3. Risk planning You should make plans to address the risk, either by avoiding it or

by minimizing its effects on the project.

4. Risk monitoring You should regularly assess the risk and your plans for risk

mitigation and revise these plans when you learn more about the risk.
Risk identification
Risk identification is the first stage of the risk management process. It is concerned with
identifying the risks that could pose a major threat to the software engineering process, the
software being developed, or the development organization. Risk identification may be a
team process in which a team gets together to brainstorm possible risks. Alternatively,
project managers may identify risks based on their experience of what went wrong on
previous projects.

1. Estimation risks arise from the management estimates of the resources required

to build the system.

2. Organizational risks arise from the organizational environment where the software is
being developed.

3. People risks are associated with the people in the development team.

4. Requirements risks come from changes to the customer requirements and the process
of managing the requirements change.

5. Technology risks come from the software or hardware technologies that are used to
develop the system.

6. Tools risks come from the software tools and other support software used to develop
the system.

1. Risk analysis

During the risk analysis process, you have to consider each identified risk and make a
judgment about the probability and seriousness of that risk. There is no easy way to do so.
You have to rely on your judgment and experience of previous projects and the problems
that arose in them. It is not possible to make precise, numeric assessment of the probability
and seriousness of each risk. Rather, you should assign the risk to one of a number of bands:

1. The probability of the risk might be assessed as insignificant, low, moderate, high, or very
high.

2. The effects of the risk might be assessed as catastrophic (threaten the survival of the
project), serious (would cause major delays), tolerable (delays are within allowed
contingency), or insignificant.

2. Risk planning

The risk planning process develops strategies to manage the key risks that threaten the
project. For each risk, you have to think of actions that you might take to minimize the
disruption to the project if the problem identified in the risk occurs. You should also think
about the information that you need to collect while monitoring the project so that
emerging problems can be detected before they become serious.

1. Avoidance strategies Following these strategies means that the probability that the risk
will arise is reduced. An example of a risk avoidance strategy is the strategy for dealing
with defective components.

2. Minimization strategies Following these strategies means that the impact of the risk is
reduced. An example of a risk minimization strategy is the strategy for staff illness.

3. Contingency plans Following these strategies means that you are prepared for the worst
and have a strategy in place to deal with it. An example of a contingency strategy is the
strategy for organizational financial problems.

3. Risk monitoring

Risk monitoring is the process of checking that your assumptions about the product,
process, and business risks have not changed. You should regularly assess each of the
identified risks to decide whether or not that risk is becoming more or less probable. You
should also think about whether or not the effects of the risk have changed.
MANAGING PEOPLE

software managers to ensure that the engineers working on a project are as productive as
possible. In successful companies and economies, this productivity is achieved when people
are respected by the organization and are assigned responsibilities that reflect their skills
and experience.

It is important that software project managers understand the technical issues that
influence the work of software development.

Software engineers often have strong technical skills but may lack the softer skills that
enable them to motivate and lead a project development team.

critical factors that influence the relationship between a manager and the people that he or
she manages:

1. Consistency: All the people in a project team should be treated in a comparable way. No
one expects all rewards to be identical, but people should not feel that their contribution to
the organization is undervalued.

[Link] :Different people have different skills, and managers should respect these
differences. All members of the team should be given an opportunity to make a
contribution. In some cases, of course, you will find that people simply don’t fit into a team
and they cannot continue, but it is important not to jump to conclusions about them at an
early stage in the project.

[Link] :People contribute effectively when they feel that others listen to them and take
account of their proposals. It is important to develop a working environment where all
views, even those of the least experienced staff, are considered.

[Link]: As a manager, you should always be honest about what is going well and what is
going badly in the team. You should also be honest about your level of technical knowledge
and be willing to defer to staff with more knowledge when necessary. If you try to cover up
ignorance or problems, you will eventually be found out and will lose the respect of the
group.

MOTIVATING PEOPLE

As a project manager, you need to motivate the people who work with you so that

they will contribute to the best of their abilities.

"motivation means organizing work and its environment to encourage people to work as
effectively as possible".

If people are not motivated, they will be less interested in the work they are doing. They will
work slowly, be more likely to make mistakes, and will not contrib_ute to the broader goals
of the team or the organization.

people are motivated by satisfying their needs.

These needs are arranged in a series of levels:

Physiological needs: The lower levels of this hierarchy represent fundamental needs for
food, sleep.

Safety needs: Need to feel secure in an environment.

Social need: It is concerned with the need to feel part of a social grouping.

Esteem need:It represents the need to feel respected by others.

Self-realization need: It is concerned with personal development. People need to satisfy

lower-level needs such as hunger before the more abstract, higher-level needs.

How to satisfy needs of workers

1. To satisfy social needs, you need to give people time to meet their co-workers and
provide places for them to [Link] should arrange some face-to-face meetings early in the
project so that people can directly interact with other members of the team. Through this
direct interaction, people become part of a social group and accept the goals and priorities
of that group.

2. To satisfy esteem needs, you need to show people that they are valued by the
organization. Public recognition of achievements is a simple and effective way of doing this.
Obviously, people must also feel that they are paid at a level that reflects their skills and
experience.

3. Finally, to satisfy self-realization needs, you need to give people responsibility for their
work, assign them demanding (but not impossible) tasks, and provide opportunities for
training and development where people can enhance their skills. Training is an important
motivating influence as people like to gain new knowledge and learn new skills.

Psychological personality type also influences motivation.

Three classifications for professional workers:

1. Task-oriented people, who are motivated by the work they do. In software engineering,
these are people who are motivated by the intellectual challenge of software development.

2. Self-oriented people, who are principally motivated by personal success and recognition.
They are interested in software development as a means of achieving their own goals. They
often have longer-term goals, such as career progression, that motivate them, and they
wish to be successful in their work to help realize these goals.

3. Interaction-oriented people, who are motivated by the presence and actions of co-
workers. As more and more attention is paid to user interface design, interaction-oriented
individuals are becoming more involved in software engineering.

Research has shown that interaction-oriented personalities usually like to work as part of a
group, whereas task-oriented and self-oriented people usually prefer to act as individuals.
Women are more likely to be interaction-oriented than men are.

Team work
Most professional software is developed by project teams that range in size from two to
several hundred people. However, as it is impossible for everyone in a large group to work
together on a single problem, large teams are usually split into a number of smaller groups.
Each group is responsible for developing part of the overall system.

The benefits of creating a cohesive group are:

1. The group can establish its own quality standards Because these standards are
established by consensus, they are more likely to be observed than external standards
imposed on the group.
2. Individuals learn from and support each other Group members learn by working together.
Inhibitions caused by ignorance are minimized as mutual learning is encouraged.

3. Knowledge is shared Continuity can be maintained if a group member leaves. Others in

the group can take over critical tasks and ensure that the project is not unduly disrupted.

4. Refactoring and continual improvement is encouraged Group members work collectively

to deliver high-quality results and fix problems, irrespective of the individuals who originally
created the design or program.

Selecting group members

A manager or team leader’s job is to create a cohesive group and organize that group so
that they work together effectively. This task involves selecting a group with the right
balance of technical skills and personalities.

Many software engineers are motivated primarily by their work. Software development
groups, therefore, are often composed of people who have their own ideas about how
technical problems should be solved.

Technical knowledge and ability should not be the only factor used to select group
members. People who are self-oriented will probably be best at pushing the work forward
to finish the job.

Group organization

The way a group is organized affects the group’s decisions, the ways information is
exchanged, and the interactions between the development group and external project
stakeholders.

 Small programming groups are usually organized in an informal way. The group
leader gets involved in the software development with the other group members. In
an informal group, the group as a whole discusses the work to be carried out, and
tasks are allocated according to ability and experience. More senior group members
may be responsible for the architectural design. However, detailed design and
implementation is the responsibility of the team member who is allocated to a
 particular task. Agile development teams are always informal groups.
 Informal groups can be very successful, particularly when most group members are
experienced and competent. Such a group makes decisions by consensus, which
improves cohesiveness and performance.
 In hierarchical groups the group leader is at the top of the hierarchy. He or she has
more formal authority than the group members and so can direct their work. There
is a clear organizational structure, and decisions are made toward the top of the
hierarchy and implemented by people lower down. Communications are primarily
instructions from senior staff; the people at lower levels of the hierarchy have
relatively little communication with the managers at the upper levels. Hierarchical
groups can work well when a well-understood problem can be easily broken down
into software components that can be developed in different parts of the hierarchy.

Group communications

It is absolutely essential that group members communicate effectively and efficiently with
each other and with other project stakeholders. Group members must exchange
information on the status of their work, the design decisions that have been made, and
changes to previous design decisions.

They have to resolve problems that arise with other stakeholders and inform these
stakeholders of changes to the system, the group, and delivery plans. Good communication
also helps strengthen group cohesiveness. Group members come to understand the
motivations, strengths, and weaknesses of other people in the group.

Effective communication is achieved when communications are two-way and the people
involved can discuss issues and information and establish a common understanding of
proposals and problems. Informal discussions when a manager meets with the team for
coffee are sometimes more effective.

Project planning

Project planning is one of the most important jobs of a software project manager. As a
manager, you have to break down the work into parts and assign them to project team
members, anticipate problems that might arise, and prepare tentative solutions to those
problems. The project plan, which is created at the start of a project and updated as the
project progresses, is used to show how the work will be done and to assess progress on the
project.

 software managers to ensure that the engineers working on a project

Project planning takes place at three stages in a project life cycle:

1. At the proposal stage, when you are bidding for a contract to develop or provide a
software system. You need a plan at this stage to help you decide if you have the resources
to complete the work and to work out the price that you should quote to a customer.

2. During the project startup phase, when you have to plan who will work on the project,
how the project will be broken down into increments, how resources will be allocated
across your company, and so on. Here, you have more information than at the proposal
stage, and you can therefore refine the initial effort estimates that you have prepared.

3. Periodically throughout the project, when you update your plan to reflect new
information about the software and its development. You learn more about the system
being implemented and the capabilities of your development team. As software
requirements change, the work breakdown has to be altered and the schedule extended.
This information allows you to make more accurate esti
mates of how long the work will take.

The project plan always evolves during the development process because of requirements
changes, technology issues, and development problems. Development planning is intended
to ensure that the project plan remains a useful document for staff to understand what is to
be achieved and when it is to be delivered. Therefore, the schedule, cost estimate, and risks
all have to be revised as the software is developed.
 It is important that software project managers understand the technical issues that
influence the work of software development.

The plan should also define project monitoring mechanisms. You must keep track of the
progress of the project and compare actual and planned progress and costs. Although most
companies have formal procedures for monitoring, a good manager should be able to form
a clear picture of what is going on through informal discussions with project staff. Informal
monitoring can predict potential project problems by revealing difficulties as they occur. For
example, daily discussions with project Overhead costs When you estimate the costs of
effort on a software project, you don’t simply multiply the salaries of the people involved by
the time spent on the project. You have to take into account all of the organizational
overheads (office space, administration, etc.) that must be covered by the income from a
project. You calculate the costs by computing these overheads and adding a proportion to
the costs of each engineer working on a project.
Project planning staff might reveal that the team is having problems with a software fault in
the communications systems. The project manager can then immediately assign a
communications expert to the problem to help find and solve the problem.

Software pricing

In principle, the price of a software system developed for a customer is simply the cost of
development plus profit for the developer. In practice, however, the relationship between
the project cost and the price quoted to the customer is not usually so simple. When
calculating a price, you take broader organizational, economic, political, and business
considerations into account You need to think about organizational concerns, the risks
associated with the project, and the type of contract that will be used. These issues may
cause the price to be adjusted upward or downward:
You should use three main parameters when computing the costs of a software
development project:
■ effort costs (the costs of paying software engineers and managers);
■ hardware and software costs, including hardware maintenance and software support;
and
■ travel and training costs

Plan driven development

 Software engineers often have strong technical skills but may lack the softer skills
that enable them to motivate and lead a project development team.

Plan-driven or plan-based development is an approach to software engineering where the

development process is planned in detail. A project plan is created that records the work to
be done, who will do it, the development schedule, and the work products. Managers use
the plan to support project decision making and as a way of measuring progress. Plan-driven
development is based on engineering project management techniques and can be thought
of as the “traditional” way of managing large software development projects.
The problem with plan-driven development is that early decisions have to be revised
because of changes to the environments in which the software is developed and used.

However, the arguments in favor of a plan-driven approach are that early planning allows
organizational issues (availability of staff, other projects, etc.) to be taken into account.
Potential problems and dependencies are discovered before the project starts, rather than
once the project is underway.

The details of project plans vary depending on the type of project and organization but
plans normally include the following sections:

1. Introduction Briefly describes the objectives of the project and sets out the constraints
(e.g., budget, time) that affect the management of the project.

2. Project organization Describes the way in which the development team is organized, the
people involved, and their roles in the team.

3. Risk analysis Describes possible project risks, the likelihood of these risks arising, and the
risk reduction strategies that are proposed.

4. Hardware and software resource requirements Specifies the hardware and support
software required to carry out the development. If hardware has to be purchased, estimates
of the prices and the delivery schedule may be included.

5. Work breakdown Sets out the breakdown of the project into activities and identifies the
inputs to and the outputs from each project activity.

6. Project schedule Shows the dependencies between activities, the estimated time
required to reach each milestone, and the allocation of people to activities

7. Monitoring and reporting mechanisms Defines the management reports that should be
produced, when these should be produced, and the project monitoring mechanisms to be
used.
Project scheduling

Project scheduling is the process of deciding how the work in a project will be organized as
separate tasks, and when and how these tasks will be executed. You estimate the calendar
time needed to complete each task and the effort required, and you suggest who will work
on the tasks that have been identified. You also have to estimate the hardware and
software resources that are needed to complete each task.

Scheduling in plan-driven projects involves breaking down the total work involved in a
project into separate tasks and estimating the time required to complete each task. Tasks
should normally last at least a week and no longer than 2 months. Finer subdivision means
that a disproportionate amount of time must be spent on re-planning and updating the
project plan. The maximum amount of time for any task should be 6 to 8 weeks. If a task will
take longer than this, it should be split into subtasks for project planning and scheduling.
Some of these tasks are carried out in parallel, with different people working on different
components of the system.

 Schedules, therefore, must be continually updated as better progress information

becomes available. If the project being scheduled is similar to a previous project,
previous estimates may be reused. However, projects may use different design
methods and implementation languages, so experience from previous projects may
not be applicable in the planning of a new project.
 Calendar-based bar charts show who is responsible for each activity, the expected
elapsed time, and when the activity is scheduled to begin and end.

Schedule presentation
Project activities are the basic planning element. Each activity has:

■ a duration in calendar days or months;

■ an effort estimate, which shows the number of person-days or person-months to

complete the work;

■ a deadline by which the activity should be complete; and

■ a defined endpoint, which might be a document, the holding of a review meeting, the
successful execution of all tests, or the like.

Algorithmic cost modelling

Algorithmic cost modeling uses a mathematical formula to predict project costs based on
estimates of the project size, the type of software being developed, and other team,
process, and product factors. Algorithmic cost models are developed by analyzing the costs
and attributes of completed projects, then finding the closest-fit formula to the actual costs
incurred.

Most algorithmic models for estimating effort in a software project are based on a simple
formula:

Effort = A 3 SizeB 3 M

A: a constant factor, which depends on local organizational practices and the type of
software that is developed.

Size: an assessment of the code size of the software or a functionality estimate expressed in
function or application points.

B: represents the complexity of the software and usually lies between 1 and 1.5.

M: is a factor that takes into account process, product and development attributes, such as
the dependability requirements for the software and the experience of the development
team. These attributes may increase or decrease the overall difficulty of developing the
system.
 COCOMO (Constructing cost model)

It is used for calculate the effort of workers , development time ,average staff size and
productivity of software.

The best known algorithmic cost modeling technique and tool is the COCOMO II model. This
empirical model was derived by collecting data from a large number of software projects of
different sizes. These data were analysed to discover the formulas that were the best fit to
the observations. These formulas linked the size of the system and product, project, and
team factors to the effort to develop the system. COCOMO II is a freely available model that
is supported with open-source tools.

COCOMO include 3 types:

1. Basic COCOMO model : Used for small size products

2. Intermediate COCOMO model : if some project has some constrains such as time
used, number of staff etc.
3. Complete /detailed COCOMO model : it is used for analyse large project

COCOMO model applied on 3 classes of software project

1. Organic mode : project size -2—50 k line of code, eg .payroll system and other small
size project.

2. Semidetached mode : 50-300k line of code, medium size project,eg. Database

system
3. Embedded mode : over 300k line of [Link] id for large project. Eg. Air traffic control.
It has a time limit.

Basic COCOMO MODEL calculation

E= ab(KLOC)bb //Effort applied

D=Cb(E)dd // Development time

People required P=E/D same equation for both organic mode, semidetached mode and
for embedded mode.

The sub models that are part of the COCOMO II model are:

1. An application composition model This models the effort required to develop

systems that are created from reusable components, scripting, or database
programming. Software size estimates are based on application points, and a simple
size/productivity formula is used to estimate the effort required. This estimate is
then adjusted according to the difficulty of developing each application point.
Productivity depends on the developer’s experience and capability as well as the
capabilities of the software tools (ICASE) used to support development. The
application composition model was introduced into COCOMO II to support for
projects where the software is developed by composing existing components.

Application composition usually relies on reusing existing software and configuring

application systems. Some of the application points in the system will therefore be
implemented using reusable components. Consequently, you have to adjust the estimate to
take into account the percentage of reuse expected. Therefore, the final formula for effort
computation for system prototypes is:

PM = (NAP * (1 - reuse/100)) / PROD

PM: the effort estimate in person-months.

NAP: the total number of application points in the delivered system. %reuse: an estimate of
the amount of reused code in the development.

PROD: the application-point productivity

2. An early design model: This model is used during early stages of the system design after
the requirements have been established. The estimate is based on the standard estimation
formula that with a simplified set of seven multipliers. Estimates are based on function
points, which are then converted to number of lines of source code.

3. A reuse model : This model is used to compute the effort required to integrate reusable
components and/or automatically generated program code. It is normally used in
conjunction with the post-architecture model.

COCOMO II considers two types of reused code. Black-box code is code that can be reused
without understanding the code or making changes to it. Examples of black-box code are
components that are automatically generated from UML models or application libraries
such as graphics libraries.

White-box code is reusable code that has to be adapted to integrate it with new code or
other reused components. Development effort is required for reuse because the code has to
be understood and modified before it can work correctly in the system. White-box code
could be automatically generated code that needs manual changes or additions.

The development effort in the reuse model is calculated using the COCOMO early design
model and is based on the total number of lines of code in the system. The code size
includes new code developed for components that are not reused plus an additional factor
that allows for the effort involved in reusing and integrating existing code.

The development effort in the reuse model is calculated using the COCOMO early design
model and is based on the total number of lines of code in the system. The code size
includes new code developed for components that are not reused plus an additional factor
that allows for the effort involved in reusing and integrating existing code. This additional
factor is called ESLOC, the equivalent number of lines of new source code.

The formula used to calculate the source code equivalence is:

ESLOC = (ASLOC *1-AT/100) *AAM)

ESLOC: the equivalent number of lines of new source code.

ASLOC: an estimate of the number of lines of code in the reused components that have to
be changed.
AT: the percentage of reused code that can be modified automatically.

AAM: an Adaptation Adjustment Multiplier that reflects the additional effort required to
reuse components.

4. A post-architecture model Once the system architecture has been designed, a more
accurate estimate of the software size can be made. Again, this model uses the standard
formula for cost estimation discussed above. However, it includes a more extensive set of
17 multipliers reflecting personnel capability, product, and project characteristics.

The post-architecture model is the most detailed of the COCOMO II models. It is used when
you have an initial architectural design for the system. The starting point for estimates
produced at the post-architecture level is the same basic formula used in the early design
estimates:

PM = A * sizeB*M

By this stage in the process, you should be able to make a more accurate estimate of the
project size, as you know how the system will be decomposed into subsystems and
components.

Project duration and staffing

project managers must also estimate how long the software will take to develop and when
staff will be needed to work on the project. Increasingly, organizations are demanding
shorter development schedules so that their products can be brought to market before their
competitor’s.

The COCOMO model includes a formula to estimate the calendar time required to complete
a project:

TDEV =3 *(PM)(0.33 + 0.2*(B -1.01))

TDEV: the nominal schedule for the project, in calendar months, ignoring any multiplier that
is related to the project schedule. PM: the effort computed by the COCOMO model.
B: a complexity-related exponent, If B = 1.17 and PM = 60 then TDEV =3 * (60)0.36 = 13
months.

People Capability Maturity Model (PCMM)

PCMM is a maturity structure that focuses on continuously improving the management and
development of the human assets of an organization.

The People Capability Maturity Model (PCMM) is a framework that helps the organization
successfully address their critical people issues. Based on the best current study in fields
such as human resources, knowledge management, and organizational development, the
PCMM guides organizations in improving their steps for managing and developing their
workforces.

The PCMM subsists of five maturity levels that lay successive foundations for continuously
improving talent, developing effective methods, and successfully directing the people assets
of the organization.

Initial Level: Maturity Level 1

The Initial Level of maturity includes no process areas. Although workforce practices
implement in Maturity Level, 1 organization tend to be inconsistent or ritualistic, virtually all
of these organizations perform processes that are defined in the Maturity Level 2 process
areas.
Managed Level: Maturity Level 2

To achieve the Managed Level, Maturity Level 2, managers starts to perform necessary
people management practices such as staffing, operating performance, and adjusting
compensation as a repeatable management discipline. The organization establishes a
culture focused at the unit level for ensuring that person can meet their work commitments.
In achieving Maturity Level 2, the organization develops the capability to handle skills and
performance at the unit level. The process areas at Maturity Level 2 are Staffing,
Communication and Coordination, Work Environment, Performance Management, Training
and Development, and Compensation.

Defined Level: Maturity Level 3

The software process for both management and engineering activities are documented,
standardized, and integrated into a standard software process for the entire organization
and all projects across the organization use an approved, tailored version of the
organization's standard software process for developing,testing and maintaining the
application.

Predictable Level: Maturity Level 4

At the Predictable Level, the organization handles and exploits the capability developed by
its framework of workforce competencies. The organization is now able to handle its
capacity and performance quantitatively. The organization can predict its capability for
performing work because it can quantify the ability of its workforce and of the competency-
based methods they use performing in their assignments.

Optimizing Level: Maturity Level 5

At the Optimizing Level, the integrated organization is focused on continual improvement.

These improvements are made to the efficiency of individuals and workgroups, to the act of
competency-based processes, and workforce practices and activities.
 Process and product quality

Process quality is a measure of excellence of interrelated work items (like tasks, procedures,
steps). It is a measurement characteristic that indicates whether a given process is carried
out with tolerant defects, minimized deficiencies, and insignificant variations. Higher quality
of a process means that relationships between the process’s components are successfully
built and sustained throughout the process lifecycle so the entire process is fulfilled
according to needs and requirements of the customer.

Process quality is measured, monitored and managed by undertaking a range of control and
assurance activities. The primary goal of such activities is to reduce variations around a
targeted process and its components. In order to implement a process in a qualitative
manner, there should be a quality management plan created to assess, anticipate and full fill
implied needs and requirements stated by the customer.

Process quality measurements are widely used in project and business management to
control, monitor and assure higher quality levels of final products. There are various
methodologies and techniques to control, manage and improve quality. For example:

 Six Sigma, a project management methodology

 TQM (Total Quality Management)
 BPR (Business Process Reengineering)
 PDCA (Plan-Do-Check-Act) cycle
 OQM (Object-oriented Quality Management).

Plan – Identify the problem, collect relevant data, and understand the problem's
root cause, develop hypotheses about what the issues may be, and decide which one
to test.

Do – Develop and implement a solution; decide upon a measurement to gauge its

effectiveness, test the potential solution, and measure the results.
 Check – Confirm the results through before-and-after data comparison. Study the
result, measure effectiveness, and decide whether the hypothesis is supported or
not.

Act – Document the results, inform others about process changes, and make
recommendations for the future PDCA cycles. If the solution was successful,
implement it. If not, tackle the next problem and repeat the PDCA cycle again.

Objective of process quality

 FUNCTIONALITY-This involves accuracy, interoperability, compliance, and security.

All of these influence the extent to which software satisfies user needs.

 RELIABILTY- This refers to the longevity of product performance or in other terms the
amount of time the software is available for use.

 USABILITY- This factor refers to how easy it is to use the software as influenced by
learnability and operability.

 EFFICIENCY-This refers to the extent to which software optimizes system resources.

 MAINTAINABILITY-This refers to the ease at which a repair may be made. This is

influenced by stability and testability.

 PORTABILITY- This refers to the ease at which software can be transported or carried
from one environment to another as indicated by adaptability, installability and
replaceability.

Product quality

Software quality product is defined in term of its fitness of purpose. That is, a quality
product does precisely what the users want it to do. For software products, the fitness of
use is generally explained in terms of satisfaction of the requirements laid down in the SRS
document. Although "fitness of purpose" is a satisfactory interpretation of quality for many
devices such as a car, a table fan, a grinding machine, etc. for software products, "fitness of
purpose" is not a wholly satisfactory definition of quality.

Example: Consider a functionally correct software product. That is, it performs all tasks as
specified in the SRS document. But, has an almost unusable user interface. Even though it
may be functionally right, we cannot consider it to be a quality product.
The modern view of a quality associated with a software product several quality methods
such as the following:

Portability: A software device is said to be portable, if it can be freely made to work in

various operating system environments, in multiple machines, with other software
products, etc.

Usability: A software product has better usability if various categories of users can easily
invoke the functions of the product.

Reusability: A software product has excellent reusability if different modules of the product
can quickly be reused to develop new products.

Correctness: A software product is correct if various requirements as specified in the SRS

document have been correctly implemented.

Maintainability: A software product is maintainable if bugs can be easily corrected as and

when they show up, new tasks can be easily added to the product, and the functionalities of
the product can be easily modified, etc.
 Process measurement

Software Measurement: A measurement is an manifestation of the size, quantity, amount

or dimension of a particular attributes of a product or process.

Need of Software Measurement:

Software is measured to:

1. Create the quality of the current product or process.

2. Anticipate future qualities of the product or process.
3. Enhance the quality of a product or process.
4. Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement:

There are 2 types of software measurement:

1. Direct Measurement:
In direct measurement the product, process or thing is measured directly using
standard scale.
2. Indirect Measurement:
In indirect measurement the quantity or quality to be measured is measured using
related parameter i.e. by use of reference.

Metrics:

A metrics is a measurement of the level that any impute belongs to a system product or
process. There are 4 functions related to software metrics:

o Planning
 o Organizing
o Controlling
o Improving

Characteristics of software Metrics:

Quantitative:

Metrics must possess quantitative [Link] means metrics can be expressed in values.

Understandable:

Metric computation should be easily understood ,the method of computing metric should
be clearly defined.

Applicability:

Metrics should be applicable in the initial phases of development of the software.

Repeatable:

The metric values should be same when measured repeatedly and consistent in nature.

Economical: Computation of metric should be economical.

Language Independent: Metrics should not depend on any programming language

Classifying the Entities to be Examined:

In software engineering, mainly three classes of entities exist. They are −

Processes
Products
Resources
 All of these entities have internal as well as external entities.

Internal attributes are those that can be measured purely in terms of the process,
product, or resources itself. For example: Size, complexity, dependency among
modules.

External attributes are those that can be measured only with respect to its relation
with the environment. For example: The total number of failures experienced by a
user, the length of time it takes to search the database and retrieve information.

Processes

Processes are collections of software-related activities. Following are some of the internal
attributes that can be measured directly for a process −

The duration of the process or one of its activities

The effort associated with the process or one of its activities
The number of incidents of a specified type arising during the process or one of its
activities
The different external attributes of a process are cost, controllability, effectiveness,
quality and stability.

Process measurement : You measure one or more attributes of the software process or
product. These measurements form a baseline process improvements have been effective.
As you introduce improvements, you re-measure the same attributes, which will hopefully
have improved in some way.
 PROCESS CMM

What is Capability Maturity Model?

The CMM is not a software lifecycle model.

It is a strategy for improving software process. CMM is used to judge the maturity of the
software process of an organization.

CMM helped organization to improve the quality of software they developed.

The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an
increasing series of levels of a software development organization. The higher the level, the
better the software development process, hence reaching each level is an expensive and
time-consuming process.

CMM can be used in two ways:

Capability evaluation: provide a way to access the software process capability.

Software process assessment: it is used by an organization with the objective to improve

the process capability.
Levels of CMM

 Level One : Initial - The software process is characterized as inconsistent. Defined

processes and standard practices that exist are abundoned during a crisis. Success
of the organization majorly depends on an individual effort, talent, and heroics. The
heroes eventually move on to other organizations taking their wealth of knowledge
or lessons learnt with them. Here each engineer follow their own style. So if one
engineer leave , the successor have great difficulty to complete the process. Here
software production proccess are not defined.

 Level Two: Repeatable - This level of Software Development Organization has a

basic and consistent project management processes to track cost, schedule, and
functionality. Size and cost estimation technique such as COCOMO ,function point
analysis . The process is in place to repeat the earlier successes on projects with
similar applications. Program management is a key characteristic of a level two
organization. If a process repeat only when a company produce a family of
products.
  Level Three: Defined - The software process for both management and engineering
activities are documented, standardized, and integrated into a standard software
process for the entire organization. All projects across the organization use an
approved, tailored version of the organization's standard software process
documents for developing, testing and maintaining the application.

Also introduce a training group to provide organization wide knowledge.

ISO 9000 certificate provide this level.

 Level Four: Managed - Management can effectively control the software

development effort using precise measurements. At this level, organization set a
quantitative quality goal for both software process and software maintenance. At
this maturity level, the performance of processes is controlled using statistical and
other quantitative techniques, and is quantitatively predictable.

 Level Five: Optimizing - The Key characteristic of this level is focusing on continually
improving process performance through both incremental and innovative
technological improvements. At this level, changes to the process are to improve
the process performance and at the same time maintaining statistical probability to
achieve the established quantitative process-improvement objectives.

Software costing and pricing

Software development processes are split into a number of separate activities. Cost
estimation of software development project focuses on how associating estimates of effort
and time with the project activities. Estimation involves answering the following questions .

1. How much effort is required to complete each activity?

2. How much calendar time is needed to complete each activity?
3. What is the total cost of each activity?

Project cost estimation and project scheduling are usually carried out together. The costs of
development are primarily the costs of the effort involved, so the effort computation is used
in both the cost and the schedule estimate. The initial cost estimates may be used to
establish a budget for the project and to set a price for the software for a customer. The
total cost of a software development project is the sum of following costs:

1. Hardware and software costs including maintenance.

2. Travel and training costs.
3. Effort costs of paying software developers.

For most projects, the dominant cost is the effort cost. Effort costs are not just the salaries
of the software engineers who are involved in the project. The following overhead costs are
all part of the total effort cost:

1. Costs of heating and lighting offices.

2. Costs of support staff (accountants, administrators, system managers, cleaners,
technicians etc.).
3. Costs of networking and communications.
4. Costs of central facilities (library, recreational facilities, etc.).
5. Costs of social security and employee benefits such as pensions and health
insurance.

The aim of software costing is to accurately predict the cost of developing the software. The
price of software is normally the sum of development cost and profit. During the
development project managers should regularly update their cost and schedule estimates.
This helps with the planning process and the effective use of resources. If actual expenditure
is significantly greater than the estimates, then the project manager must take some action.
This may involve applying for additional resources for the project or modifying the work to
be done.

Development cost estimation techniques

[Link] cost modelling: Relating some software metric a mathematical model is developed to estimate the
project cost

2. Expert judgement : Several experts on the proposed software development techniques and the application domain
are asked to estimate the project cost. The estimation process iterates until an agreed estimate is reached.

3. Estimation by previous projects : The cost of a new project is estimated by a completed project in the same m
application domain.
d
4. Application of Parkinson’s Law : Parkinson’s Law states that work expands to fill the time available and the cost is
e
determined by the resources used.

5. Pricing to win: The software cost is estimated by the price what the customer has available to spend on the project

Algorithmic cost modelling

Algorithmic cost modeling uses a mathematical formula to predict project costs based on
estimates of the project size, the type of software being developed, and other team,
process, and product factors. Algorithmic cost models are developed by analyzing the costs
and attributes of completed projects, then finding the closest-fit formula to the actual costs
incurred.

Most algorithmic models for estimating effort in a software project are based on a simple
formula:

Effort = A 3 SizeB 3 M

A: a constant factor, which depends on local organizational practices and the type of
software that is developed.

Size: an assessment of the code size of the software or a functionality estimate expressed in
function or application points.

B: represents the complexity of the software and usually lies between 1 and 1.5.
M: is a factor that takes into account process, product and development attributes, such as
the dependability requirements for the software and the experience of the development
team. These attributes may increase or decrease the overall difficulty of developing the
system.

Continuous Integration

(CI) is a development practice where developers integrate code into a shared repository
frequently, preferably several times a day. Each integration can then be verified by an
automated build and automated tests. While automated testing is not strictly part of CI it is
typically implied.

Continuous integration (CI) is a development practice where development teams make

small, frequent changes to code. An automated build verifies the code each time developers
check their changes into the version control repository. As a result, development teams can
detect problems early.

Continuous integration is the first part of CI/CD, a practice that enables application
development teams to release incremental code changes to production quickly and
regularly.

One of the key benefits of integrating regularly is that you can detect errors quickly and
locate them more easily. As each change introduced is typically small, pinpointing the
specific change that introduced a defect can be done quickly.

The goal of continuous integration:

 Frequent code commits

 Developer test categorization
 A dedicated integration build machine
 Continuous feedback mechanisms
 Staging builds
Continuous Integration (CI) is a development practice that requires developers to integrate
code into a shared repository several times a day. Each check-in is then verified by an
automated build, allowing teams to detect problems early.

By integrating regularly, you can detect errors quickly, and locate them more easily.

Because you’re integrating so frequently, there is significantly less back-tracking to discover

where things went wrong, so you can spend more time building features.

Continuous Integration is cheap. Not integrating continuously is expensive. If you don’t

follow a continuous approach, you’ll have longer periods between integrations. This makes
it exponentially more difficult to find and fix problems. Such integration problems can easily
knock a project off-schedule, or cause it to fail altogether.

Continuous Integration brings multiple benefits to your organization:

 Say goodbye to long and tense integrations

 Increase visibility enabling greater communication
 Catch issues early and nip them in the bud
 Spend less time debugging and more time adding features
 Build a solid foundation
 Stop waiting to find out if your code’s going to work
 Reduce integration problems allowing you to deliver software more rapidly.

 Frequent code commits;

 Developer test categorization;

 A dedicated integration build machine;

 Continuous feedback mechanisms; and

 Staging builds.

How to do it
 Developers check out code into their private workspaces
 When done, commit the changes to the repository
 The CI server monitors the repository and checks out changes when they occur
 The CI server builds the system and runs unit and integration tests
 The CI server releases deployable artefacts for testing
 The CI server assigns a build label to the version of the code it just built
 The CI server informs the team of the successful build
 If the build or tests fail, the CI server alerts the team
 The team fixes the issue at the earliest opportunity
 Continue to continually integrate and test throughout the project

Team responsibilities

 Check in frequently
 Don’t check in broken code
 Don’t check in untested code
 Don’t check in when the build is broken
 Don’t go home after checking in until the system builds

Continuous integration requires all developers who work on a project to commit to it.
Results need to be transparently available to all team members and build status reported to
developers when they are changing the code.

CI aims to provide rapid feedback so that when a defect is introduced into the code base, it
is identified and corrected as soon as possible.

CI originated from within the Extreme Programming paradigm, which is a subset of the Agile
methodology, but the principles can be applied to any iterative programming model.
Traditional development approaches, such as the Waterfall model, can also benefit from the
use of CI methods for the construction stage. Continuous integration commonly is paired
with continuous delivery, wherein steps to deliver executable code to production occur
rapidly and with automation, for CI/CD.
A development team can use automation in the CI setup to incorporate code integration
and testing, which reduces time to find bugs and enables faster feedback than when these
tasks are carried out manually. Automation tools help teams perform common tests as part
of the CI process, such as unit, application programming interface (API) and functional tests.
A unit test examines the smallest application components. An API test assesses whether or
not an API can reliably perform under its expected load of requests and responses. A
functional test typically evaluates larger pieces of the source code to simulate a user
workflow or function. With full CI automation, scripts or integration engines manage the
movement of new code through tests and build.

software engineering methodologies for mobile and cloud

environment

A mobile application (or just mobile app) is a type of software application developed to run
on a mobile device. Mobile applications are a recent type of software application that
emerged due to the appearance of many handheld devices, like smartphones, which are
considered to be the personal computer of the future (Duffy, 2012), or tablet computers.
Mobile devices are expected to be easily carried, held, and used in the hands; hence, mobile
devices are characterized by being relatively small devices when compared to desktop
computers. For this reason, mobile devices are naturally restricted in several dimensions
that strongly affect the operating characteristics of an application that executes on this type
of devices. In many cases, the challenges for the software or systems engineer when
developing a mobile application are similar to the ones to develop other types of embedded
applications (Wasserman, 2010). Common issues include integration with hardware,
security, performance, reliability, and storage limitations.

Mobile applications are software systems that have specific characteristics when compared
with normal desktop applications. Mobile applications differ from desktop applications by
having to deal with limitations on specific hardware resources, like display size, processing
power and memory to name a few. Probably the most significant difference is that mobile
applications run on mobile devices with energy consumption limitations. Increase battery
lifetime is a significant concern for both mobile applications developers and hardware
manufacturers, namely in what concerns multimedia applications running on mobile
devices. Mobile applications can now take advantage of new hardware capabilities, meaning
that they can provide a wider set of functions or use, which inevitably results in more
complex software solutions. Development of mobile applications is now closer than before
to the development of desktop applications in terms of complexity (examples are Android
OS, Apple iOS and Windows Phone mobile operating systems); however the hardware is still
a relevant differentiator. These differences motivate the need to understand clearly how
the hardware constraints impact the software design decisions. For that purpose, one must
understand which quality attributes are more relevant for mobile applications, providing an
inevitable link to constraints imposed by the hardware itself.

MOBILE DEVICES CHARACTERISTICS

Small Display Size: Mobile devices have relatively small displays when compared to desktop
computers or laptops. Small mobile devices, in particular small smartphones, have display
sizes of 4 to 4.5 inches but these can go down to 2.45 inches. Typical smartphones have
display sizes between 4.5 to 6 inches and tablets range from 5 up to 13 inches. Mobile
applications must be designed to successfully provide the desired functionality in a limited
screen size. These conditions contrast greatly with normal applications that are designed to
use larger screens. Small screen sizes pose great constraints to usability of mobile apps.

Small Battery Capacity: Batteries provide the necessary power for mobile devices to work.
While hardware manufactures struggle to increase the capacity of the batteries, mobile
application developers struggle to make a more efficient use of them. Recent advancements
in software technology revolutionized the way mobile devices are used. Multi-purpose
mobile devices (smartphones or tablets) that allow access to email, browse the Internet,
watch videos, and play games replaced basic mobile phones. Typical smartphones use
batteries that can range from 1,570 to 3,400 mAh for smartphones and around 7,000 mAh
for high-end tablets. Energy consumption impacts greatly mobile users.

Small Memory Size: Normally, mobile devices have less memory available than desktop
computers. Mobile devices, as any computing device, have both ROM (Read-Only Memory)
and RAM (Random Access Memory). ROM, which technically is EEPROM, i.e., Electrically-
Erasable Programmable ROM, and so is both readable and writeable by the end user, does
not require power to maintain its (non-volatile) data and is basically used by a mobile device
to store the operating system, mobile applications, media (photos and video) and files. ROM
memory sizes go up to 128 GB (Gigabytes), but typical sizes are around 8 to 16 GB. However,
some mobiles devices allow the ROM size to be increased, by using nonvolatile memory
cards, e.g., SD (Secure Digital) memory cards. Due to memory size restrictions, most mobile
applications are relatively small, when compared with desktop applications (e.g., Microsoft
Word).

Real-World Interaction: Mobile applications provide real-world interaction by interfacing

with context information, like user location, time of day, neighboring users and devices.
Mobile devices are capable of acquiring and using context information by using built-in
sensors, like GPS and accelerometers, and complementing this information with data
acquired from the network.

TYPES OF MOBILE APPLICATIONS

Mobile applications can be classified according to two main types: native applications and
web-based applications.

Mobile web applications consist of web pages specifically developed for taking into account
the characteristics of mobile devices. Mobile web apps are developed using technologies
that one uses to build websites, such as HTML, CSS, and Javascript. A mobile web
application is simply accessed by its URL in a web browser (that runs on the mobile device).
In most cases, a web app can be seen as a website that mimics a native app. A major
characteristic that distinguishes a mobile web application from a standard website is the
fact that it is designed to be accessible in a small display, most of the cases with touch-
screen interface capabilities. Hence, operations that in websites are operated with mouse
clicks are operated using fingers in a mobile web app.

Native apps are designed and coded for a specific kind of device. For instance, iPhone apps
are written in Objective-C and Android apps in Java. Native apps can usually be found in an
app store, such as Google Play, and require the store’s approval. They are downloaded from
the store and installed on that mobile device. They run exclusively on that type of mobile
device and interact with and take advantage of the features of the operating system and
other software that is usually installed on that platform.

QUALITY ATTRIBUTES

 Product Requirements characterize aspects of the behavior of the system itself,

including, for example, (i) reliability, (ii) performance, (iii) efficiency, (iv) portability,
(iv) usability, (vi) testability, and (vii) readability.
 Organizational Requirements come from strategies and procedures established in
the context of the manufacturing process of the system or the client organization,
being examples (i) process standards that must be followed, (ii) implementation
requirements, like the programming language to be adopted.
 External Requirements have origin in external factors to the system and the
development process, being examples (i) interoperability requirements that define
how the systems interact with other systems, (ii) legal requirements to guarantee
that the system is compliant with the laws, and (iii) ethical requirements to make
sure that the society in general will accept the system.

• Look and Feel: The visual aspect and the aesthetics of the system, namely the graphical
interface.

• Usability and Humanity: The easiness of utilization of the system and everything that
permits a friendlier user experience.

• Performance: Aspects of speed, real-time, storage capacity, and execution correction.

• Operational: Characteristics about what the system must do to work correctly in the
environment where it is inserted.

• Maintainability and Support: Attributes that allow the system to be repaired or improved
and new functionalities to be anticipated.

• Security: Issues related to access, confidentiality, protection, and integrity of the data.

• Cultural and Political: Factors related to the stakeholders culture and habits.

• Legal: Laws, rules, and standards that apply to the system so that it can operate
RELEVANT QUALITY ATTRIBUTES FOR MOBILE APPLICATIONS

Usability :Usability is a crucial quality for all types of software products. Usability
covers many aspects, like ease of use, personalization, ease of learning, and
accessibility. According to ISO, usability is related to the extent to which a given
product can be used to achieve specified goals with effectiveness, efficiency, and
satisfaction in a specified context of use. A usable system means to the user
increased productivity, quality of work, and user satisfaction. Usability also implies
reductions in support and training costs.
Personalization is associated with the capacity of adapting the system to the tastes
and needs of the users, including the choice of the language, currency, time zone
and other configuration options (colours, backgrounds, icons). Mobile devices are
usually tied to a given person, which wishes to introduce his personal data (phone
number, email, contacts, passwords, bookmarks, etc) in the device to configure and
personalize it.
Ease of learning is concerned with the way users are trained to use the application.
Based on requirements of this type, the development team can prepare training and
help procedures for the users. Associated with the ease of learning is
comprehensibility that determines if the users intuitively capture the functionalities
of the application and how to operate it. In many cases, mobile applications are
expected to be so easy to use that no external help is required. Some applications
must indeed have very high comprehension levels; if this is not the case, the users
resort to other alternatives, i.e., mobile applications provided by the competitors, to
satisfy their needs.
Accessibility indicates how easy it is to use the system, for people who are somehow
physically or mentally disabled. The disabilities can be related with physical, visual,
auditory, or cognitive aspects.
Usability is very likely to be the most crucial aspect of mobile applications, since they
are used in many different contexts and environments. The user shall be able to use
the mobile application in crowded and noisy environments, which imply that
restrictions on the inputs and outputs may apply. In many cases, the device is
supposed to be handled with just one hand, while in others two hands may be
 necessary. This means that mobile applications must be developed with the
possibility of being effectively used with either one or two hands.

Performance

Performance refers to the capacity of a system to respond to its stimulus, that is, the time
necessary to deliver a response to an event or the number of events processed in a specific
time unit. It is the degree to which a system can accomplish its functionalities within a given
set of constraints. The performance of a system is related to the processing time of a task,
response time of an operation, accuracy of the result, reliability, availability, fault-tolerance,
storage capacity, and scalability.

Data storage capacity specifies the amount of data that the system should be able to
process and store. While the function of storing data is a functional requirement, the
respective capacity should be seen as a non-functional requirement.

Scalability is the ability of a system to continue to show high quality of service, even when
subjected to a greater number of requests. Scalability can be related with the ability to
serve more users simultaneously, treat a higher volume of information, or respond to more
requests. In any case, it is assumed that this load increase does not imply significant changes
to the system response in order for it to maintain the performance levels. Scalability of
software systems often needs to be evaluated taking into account the hardware resources,
because it is only possible to determine factors such as response time or number of users
that can be served simultaneously, if both the hardware and the software are analysed as a
set.

Maintainability and Support

Modifiability is an attribute strongly related to maintenance and is dependent on how easy

it is to locate the system components that must be changed. In principle, it is preferable that
the change has impact on a reduced number of components, since it is more costly and
difficult to make modifications in the context of many components.
Portability is also an important characteristic to take into account when developing mobile
applications. A mobile application is said to be portable if it is relatively easy and
straightforward to move it from one mobile device to another. The cost of porting an
application to different platforms is smaller as developers consider it the sooner during the
development.

Android App Development Tools and Technologies

Android SDK (Software Development Kit):

Android SDK is the official software development kit that enables developers to develop
apps for the Android platform. SDK consists of sample projects with source code, an
emulator, development tools, and required libraries to develop Android apps.

Major Android App Programming (development) Languages:

• Java

•C

• C++

• Corona

• Phonegap

• Titanium

• HTML 5

Major Android App Testing Tools:

• Google Android Emulator

• The official Android SDK Emulator

• MobiOne

• eggplant
Mobile platforms

iOS

iOS, an operating system from Apple, was originally developed for the iPhone. Later it was
extended to support iPod Touch, iPad and Apple TV. Apple’s App Store contains more than
500,000 applications and boasts more than 25 billion downloads collectively. It holds the
reputation of intelligent UI creator which is based on the concept of direct manipulation,
using multi-touch gestures.

Android

Android is a Linux based mobile operating system developed by the Open Handset Alliance
led by Google. Android boasts large community of developers writing applications extending
the functionality of the devices. It has 450,000 apps in its Android Market and download
exceeds 10 billion count.

iOS

iOS, an operating system from Apple, was originally developed for the iPhone. Later it was
extended to support iPod Touch, iPad and Apple TV. Apple’s App Store contains more than
500,000 applications and boasts more than 25 billion downloads collectively. It holds the
reputation of intelligent UI creator which is based on the concept of direct manipulation,
using multi-touch gestures.

Android

Android is a Linux based mobile operating system developed by the Open Handset Alliance
led by Google. Android boasts large community of developers writing applications extending
the functionality of the devices. It has 450,000 apps in its Android Market and download
exceeds 10 billion count.
BlackBerry OS

BlackBerry OS is developed by Research In Motion (RIM) for its line of smartphones. This
operating system is known for its native support for corporate e-mail through MIDP allowing
complete wireless activation and synchronization with Microsoft Exchange and Lotus
Domino. Accordingly to one research approximately 45% of mobile developers were using
the platform at the time of publication. It provides BlackBerry API classes for developers to
write applications.

Windows Phone

A successor to Windows Mobile platform, Windows Phone, is a mobile operating system

launched by Microsoft in late 2010. This mobile OS is targeted at consumer market. With
this new operating system Microsoft offered a new user interface, Metro, integrating the
operating system with third party and other Microsoft services, and controls the hardware
on which it runs.

Collaborative Application.

Input is any event (e.g. keyboard, pointer, gesture, speech) generated by a user that is
interpreted by the application and output is any event (e.g. screen update, audio output)
generated by the application that is perceptible to a user.

Some traditional applications that qualify as collaborative applications according to this

definition:

 A mail application--linkage occurs when a user successfully sends a message to one

or more collaborators.
 A talk program-- linkage may occur at each keystroke or when the RETURN key is hit.
  A database application-- linkage occurs when a user retrieves data that were
deposited by another user or when a user is locked out because another user has
acquired the lock needed by the former.
 A whiteboard application allowing users to create a shared drawing -- linkage occurs
when a drawing gesture made by a user is communicated to the other users.
 A video-conferencing application-- linkage occurs when a user's voice or video are
communicated to other users.

The Multiple Layers of Mobile App Architecture Design

One of the most popular multilayer architecture is a three-layer architecture. The main
three important layers are:

 Presentation Layer
 Business Layer
 Data Access Layer

Presentation Layer

The presentation layer pays attention to the components of the User Interface and UI
process components. The primary focus of this layer is how the application would be
presented to the end user. When discussing this layer, the mobile app developer should
define how the mobile app will present itself in front of the end user. The important things
like themes, fonts, colors, etc. should also be decided at this stage.

Business Layer

It represents the core of the mobile app, which exposes functionalities. The business logic
layer can be deployed on the backend server and user remotely by the mobile application to
reduce the load.
Data Access Layer

This layer is created from the combination of data utilities, data access components, and
service agents. Data access layer meets with the application requirements and facilitates
secure data transactions. It is important to design this layer because it could scale in the
future. This is the third stage data as it includes Data access components, data
helpers/utilities, and service agents.

SOLUTIONS AND RECOMMENDATIONS

To achieve portability, current solutions focus on using cross-platform frameworks, but with
this approach developers need to be aware of its limitations. Mainly, these limitations are
related to the quality of the end result in terms of user interface. However, cross-platform
frameworks may lower the barrier for developing mobile applications by allowing the use of
Web technologies like HTML, CSS and JavaScript, along with the widespread of Web
development paradigms. These technologies allow a greater number of developers to easily
start developing mobile application without having the effort required to learn native,
specific, platform languages. Native based mobile applications are probably the best option
for developing rich end user interfaces. Native languages seem to provide more flexibility
and ease of development when creating the user interface. Also, when designing user
interfaces several guiding principles need to be considered to captivate users.

Examples of relevant principles to consider are

(1) users’ limited attention,

(2) minimization of keystrokes to completely perform a given functionality, and

(3) task-orientation with a minimum set of functions.

In the scope of the mobile devices efficiency issue, developers need to design and develop
their software with the mindset of saving computation power, but ensure, at the same time,
the same level of functionality. The path to take may involve designing more efficient
algorithms to save computation resources and thus as result extend battery life for the
same level of functionality. The wide spread of multimedia mobile applications in mobile
devices today is an example where improvements on software can help decrease battery
consumption by improving the software. Current algorithms for processing media were not
designed with the resource limitations in mind and can make a difference .