LV Thạc sỹ_Software depvelopment process at FSOFT

TABLE OF CONTENTS
EXECUTIVE SUMMARY............................................................................................4
ABBREVIATIONS........................................................................................................6
CHAPTER 1...................................................................................................................8
INTRODUCTION..........................................................................................................8
1.1 Rationale............................................................................................................... 8
1.2 Research Objective...............................................................................................9
1.3 Research Methodology.......................................................................................10
1.4 Scope of research................................................................................................12
1.5 Structure of the thesis.........................................................................................12
CHAPTER 2.................................................................................................................13
LITERATURE REVIEW.............................................................................................13
2.1 Literature Review...............................................................................................13
2.2 Theoretical Background of the product development process............................15
2.2.1 Overview of Product Development Process.................................................15
2.2.2 Software Development Processes................................................................21
CHAPTER 3................................................................................................................. 35
SOFTWARE DEVELOPMENT PROCESS AT FSOFT..............................................35


3.1 Introduction of FSOFT.......................................................................................35
3.2 Software Development Process at FSOFT..........................................................39
3.3 Requirements of FSOFT Process........................................................................47
3.4 Project Organization and Management...............................................................49
3.5 Advantages and disadvantage of FSOFT software development process...........54
Advantages...........................................................................................................56
Disadvantages.......................................................................................................61
CHAPTER 4................................................................................................................. 64
SUGGESTIONS

ON

IMPROVEMENT

OF

SOFTWARE

DEVELOPMENT

PROCESS AT FSOFT..................................................................................................64
4.1Improving the mechanism of transfer of personnel between projects..................64
4.2 Improving the capacity and working conditions for employees..........................65
4.3 Strengthening the employees’ participation in designing product development
process......................................................................................................................67
4.4 Adjusting the current frame product designing process......................................68
CONCLUSION............................................................................................................71
REFERENCES.............................................................................................................73
APPENDICES..............................................................................................................74

2


LIST OF FIGURES
Figure 1: Research Process.............................................................................................1
Figure 2: Generic Product Development Processes......................................................20
Figure 3: Organization level.........................................................................................36
Figure 4: Software Development Process.....................................................................39
Figure 5: General process.............................................................................................41
Figure 6: Project Planning..............................................................................................1
Figure 7: Project Monitoring..........................................................................................1

Figure 8: Project Closing................................................................................................1
Figure 9: Project life cycle............................................................................................47
Figure 10: Experience required......................................................................................1
Figure 11: Study effort....................................................................................................1
Figure 12: Performance..................................................................................................1
Figure 13: Complexity....................................................................................................1
Figure 14: Implementation Time....................................................................................1
Figure 15: Quality..........................................................................................................1
Figure 16: Process information.....................................................................................60
Figure 17: Process notice................................................................................................1
3


4


EXECUTIVE SUMMARY
Software engineering and software process improvement standards are gaining more
and more attention. Standards are recognized by the software industry as a way for
transferring good practice into industrial use. Standards are used as the basis against
which organizations and/or software products are certified. If two organizations follow
the same standards, they will be considerably simplified. A software development
process defines who is doing what, when and how to reach the goal. Usually, three
different categories of processes are identified: Primary life cycle processes are
conducted by prime parties, supporting life cycle processes, and organizational life
cycle that is practiced by an organization to establish

and implement the underlying

structure of the life cycle.

FSOFT is a leading software company in Vietnam. From the beginning, FSOFT
recognized the important of process-oriented method in software development. Process
orientation could significantly reduce administration effort, discover and meet the
customer requirements faster and easier, can automate operations, and enabled an interorganizational Increased Cooperation. So, FSOFT developed a standard process system
which could help them compete and integrate with other company in area. The main
aim of this research study is to analyses the current Software Development Process at
FSOFT and finds the way to improve this process.
Nowadays, FSOFT has built a software development process system, which included
12 processes: six primary processes, four supporting processes and two organizational
processes. Software Development Process at FSOFT is considered a most standard and
professional system in Vietnam. However, there are some weaknesses such as: low
flexibility in implementing the product development process, poor involvement of
employees in designing new product development process, inappropriate working
5


conditions for technical staff, etc. Based on the real conditions of FSOFT, some
solutions for improving the software development process system at the Company are
proposed, including the improvement of the mechanism of transfer of personnel
between projects, improvement of the capacity and working conditions for employees.

6


ABBREVIATIONS

Abbreviations

Description

SC

Subsidiary Companies

DB

Domestic Branches

OB

Overseas Branches

HO

Head Office Units

BA

Business Assurance

BAG

Business Assurance Group

OG

Operation Groups

D

Division

BOM

Board of Manager

FSU

FSOFT Strategic Unit

BU

Business Unit

OM

Operation Manager

SM

Senior Manager

PM

Project Manager

PTL

Project Technical Leader

QAM

Quality Assurance Manager

QA

Quality Assurance

RADIO

Responsibility matrix

CM

Configuration Management

CC

Configuration Controller
7


AN

Acceptance Note

PP

Project Plan

WO

Internal Work Order

8


CHAPTER 1
INTRODUCTION
1.1 Rationale
For over 15 years of development, FSOFT grown with over 3,000 employees and about
10 offices around the world. Currently, the Company has many customers from
developed countries such as Japan, UK, France, Germany, Japan, Malaysia... Key
strategic customers come mostly from Japan, which often require high quality products
and services.
Because the softwares are service/ product, which are often not able to be standardized,
the best way to ensure their quality is the application of process management. Thus, in
order to guarantee the quality of services and meet the requirements of global clients,
FSOFT identifies technological advancement and standardized management process as
top priorities. Using process in product development has many advantages as:
-

Increase business performance

-

Quality is guaranteed

-

Management is easier.

-

Improve customer satisfaction and customer confidence

Currently, FSOFT has built a standard software development process that is widely
applied in its Business Unit. This process system has contributed in making FSOFT
become professional out-sourcing company in software industry. After many years
improvement, this system is still applied in all Subsidiary Company of FSOFT.
9


However, in latest report (end of 2011) of Company, Customer Satisfaction Point got
improved compare to 2010 but not reached the target with main causes are: Customers
lowly appreciated the product quality and indicated lot of unsatisfied points in other
activities.
In addition, as observed, a number of customers, who requests to ignore the process of
FSOFT service provide is increasing in comparison with the last year. The reason is
that the process does not match the characteristic of the project and customer
requirements.
The questions here are: How effective is the process of software development FSOFT
really? How could the service providing process meet customers demands under the
conditions of changing of business environment, increasing competition and
increasingly diverse of customers demands? In order to answer these questions, the
research on Software Development Process at FSOFT is proposed, which aims to
figure out the current status of this process and offer innovative solutions. Based on
survey with managers and staff in organization, this report examines advantages and
disadvantages of those processes and shows some of the suggestions to improve the
software development process at FSOFT.

1.2 Research Objective
The first, this research aim to clarify the requirement of software development process
at FSOFT. FSOFT has built a system of process for software development. So what are
the requirements that one software company needed to satisfy when they want to apply
this system? This report has figured out some critical points to answer that question.
Second, another main objective of this research is to identify the advantages and
disadvantages of software development process at FSOFT and help them to enhance
the strengths and improve the weaknesses.
10


And the last, this research gives suggesting solutions/ actions, which FSOFT should
take in order to improve software development process.

1.3 Research Methodology
A literature study was used to gather relevant information about existing software
development processes and previous research results in the same field. Some of the
information about FSOFT comes from personal experiences, since the author of this
research was an employee of Company.
A survey was conducted to collect primary data for quantitative analysis.
Questionnaires were sent via email to related people in order to collect quantitative
data from employees to evaluate advantages and disadvantages when applying
software development process. The sample was a group of 60 staffs in operation
department, who were directly involved in the software development, such as Senior
Manager, Project Manager, Developer, Tester, Quality Assurance officer.
For quantitative data, the researcher used in-depth interview method. The questions
were designed to gather comments about process in general, organization of human
resource and infrastructure and the management of resource. The interviewees are Ms
Nguyen Thi Kim Chung – Quality Assurance Leader; Ms Phan Thi Hanh Le – Project

Manager; Mr Trinh Van Trong – Vice Business Unit Leader and Mr Ngo Quang Huy–
Developer.

Literature
review

Theories of software
development process,
Software development
process requirements
FSOFT background

Recommendation
Survey

In-depth

Current situation of FSOFT
process
Advantages and disadvantages
of FSOFT process.

Interview
Figure 1: Research Process

11


1.4 Scope of research
The research was finished after 9 months. The location of research is Hanoi branch of

FSOFT Company. The duration of collected information is 5 years (from 2006 to
2011). Time for data collection and analysis was 5 months.
The solutions and actions were proposed for next period between 2013 and 2015.

1.5 Structure of the thesis
An exhaustive review of relevant literature was carried out on various aspect of
Product and software product development process, relevant to this study. The review
starts from the basic concepts and requirements of development product. The literature
review provided a product/software development process knowledge base for the
research study.
The Software Development Process at FSOFT is described in Chapter III. Organization
of Company was to be reviewed with the aim of showing that the general information
and the structure of FSOFT company. After that, the system of development process
was also reviewed and presented. The need to apply FSOFT process and the current
status of the implementation also were identified clearly from this chapter.
The analysis of ability of Software Development Process was to be carried out. The
relative strengths and weaknesses of this system are highlighted.
Conclusions and Recommendations are described in chapter 4 respectively. References
and Appendices are set out afterward.

12


CHAPTER 2
LITERATURE REVIEW
2.1 Literature Review
Process, with common definition is a sequence of interdependent and linked
procedures which, at every stage, consume one or more resources (employee time,
energy, machines, and money) to convert inputs (data, material, parts, etc.) into
outputs. These outputs then serve as inputs for the next stage until a known goal or end

result is reached.
In a research, Erik Perjons (2002) pointed out four reasons why companies should
focus on process orientation: Firstly, it could significantly reduce administration effort.
Secondly, it allows a company to discover and meet the customer requirements faster
and easier. Thirdly, the company can automate operations. Fourthly, the growth of
Internet has enabled an inter-organizational Increased Cooperation.
A software development process defines who is doing what, when and how to reach the
goal: a new software product or a change in an existing one. In this research, a widely
accepted definition is adopted from Capability Maturity Model (Paulk et al., 1991):
“Software process is a set of activities, methods, practices and transformations that
people use to develop and maintain software and the associated products”.
In a research conducted in 2006, the Software Engineering Institute (SEI, 2006) has
found several dimensions that an organization can focus on to improve its business:
People, Procedures/methods, and Tools/equipment. However, the Institute indicated
especially the role of the process applied in each organization: “Processes allow you to
align the way you do business. They allow you to address scalability and provide a way
13


to incorporate knowledge of how to do things better. Processes allow you to leverage
your resources and to examine business trends”.
Modeling methods in the past were not very formal affairs. But for development
projects of increased complexities and huge size, informalities proved to be the major
reasons of failures. When the work was distributed in multiple teams, they could not
interrelate and integrate their individual work because of uncommon assumptions and
bases of developments. Not following standards of work and strategically themes threw
them into pits of failures and crisis. Slowly, the developing industries realized the need
of formal processes of development and they developed these processes as per their
experiences in their fields (Deepak Jain, 2007).
Another research (Unicom, 2007) pointed out that the process oriented management,

also known as horizontal approach, is very widely used. According to this principle, all
the company's activities are considered as the components in a certain process. The
advantages of this process are the high level of interaction between departments,
shortened customer service time. Process oriented approach helps the quality control
system strictly. “Process-oriented approach of quality control makes system more
closely to ensure all processes are monitored and subject to the control of the system.
This aims to improve quality to meet customer needs in the best way. This is the core of
the issue”.
The four classic management processes of analysis, planning, realization and
controlling can be recovered in process-oriented quality management. Quality
management serves to achieve the organizational objectives and to support the
management. Thus, a process- oriented standard cycle was introduced analogous to the
four management processes. The four phases of the standard cycle of quality
management picked up in many variations are: Plan, Do, Check, Act (M. Stracke,
2006).
14


According to (Yack, 2005), “Software Process describes the phases of the software
cycle and the order in which those phases are executed. Each phase produces
deliverables required by the next phase in the life cycle. Requirements are translated
into design. Code is produced during implementation that is driven by the design.
Testing verifies the deliverable of the implementation phase against requirements”.
Yack summarized the traditional software development process models with the
following models:
-

Waterfall Model
V-Shaped Model
Incremental Model

Spiral Model

2.2 Theoretical Background of the product development process
2.2.1 Overview of Product Development Process

Products and requirements on the product development
In general, the product is defined as a "thing produced by labor or effort" or the "result
of an act or a process". In economics and commerce, products belong to a broader
category of goods.
In marketing, a product is anything that can be offered to a market and could satisfy a
want or need. In retailing, products are called merchandise. In manufacturing, products
are produced from different inputs, such as raw materials, labor, etc. and sold
as finished goods. In project management, products are deliverables that make up or
contribute to delivering the objectives of the project.
Product development process enhances quality and reduces both costs and time to
market demand and thus contributing to increasing the competitiveness of enterprises.
However, it is important to note that the process must be properly implemented: faulty
15


implementation can render them practically ineffective. This is not surprising, as the
same is true whenever advanced technological systems are used to improve
competitiveness and the proper company framework and environment do not exist. The
introduction and use of these methodologies require the following on the part of the
company:
1. A long – term commitment, to improving products and production processes.
2. The integration of design methodologies and technologies in production processes
and the implementation of new production methods.
3. The establishment of methods for developing new products in a manner that
optimizes design systems. To do this, the design process, as a whole must be studied,

the proper techniques must be used at each phase of the process, and the different
techniques and tools must be implemented interactively.
4. The adaptation of the company’s structure to the information flow that these
techniques require, in order to obtain maximum effectiveness. Moreover, the design of
new products must be undertaken in accordance with the companies with the
company’s capacities, so that the effort required is coherent with its competitive
strategy, and may thus be assumed by the company.
Basic Considerations on the product development process
A product development process (PDP) is the overall process that occurs in industry
when a product is engineered and brought to market. It is not simply an academic
method that is followed, as from text books, that guarantees an acceptable result. A
PDP is the series of phases that are commonly executed each time a new product is
developed or an existing product is modified. Engineering design is one aspect of a
PDP; some other aspects are manufacturing, business, management, research &
16


development, industrial design, quality assurance, and innovation. However, of all the
aspects of PDPs, engineering design is the most fundamental. Design is the foundation
of the technical side of product development. It also impacts directly upon all the other
aspects of product development.
Defining “Designing”
Based on this foundational role of design in engineering, let introduce the following
definition of the process of designing:
Engineering designing is the synthesis of balanced, implementable artifacts that
resolve poorly understood problems, such that their use in a given context will promote
a preferred situation.
This definition is based on the CEAB’s definition of design, the definition given in the
announcement for the NSERC Design Engineering Chairs program, and aspects of
various other definitions from the literature, but it does require some commentary.

Synthesis. Synthesis involves the bringing together of things to make something new
and greater. Synthesis is the “creative” part of designing, but it is not just creativity.
Creativity is unconstrained and extremely unpredictable. Synthesis is somewhat more
structured and a little more predictable. That is, synthesis can be thought of a creatively
rational thinking, or conversely, as tempered creativity. There are many methods to
stimulate tempered creativity in design engineers.
Balance. A balanced design is one that finds the ideal trade-off between all the major
drivers of the design. Balanced designs are relatively easy to identify in hindsight: the
original Apple Macintosh, the Studebaker, the original VW Beetle, the Boeing 747, the
Aeron Chair, the Apple iPod. None of these products were of particularly high quality,

17


or low cost, or especially light or functional; but all of them found a balance that was
ideally suited to the context, times, and environment into which they were introduced.
Implementable. A design is in many ways a plan for the manufacture or, more
generally, an implementation. If a design cannot be realized, then what is the point in
designing it? It is important to note, however, that design engineers often lack the
expertise to ensure that their designs are implementable. It is important, therefore, to
keep manufacturing experts and other implementation specialists intimately involved in
the design process.
Artifact. Literally, something “made by hand”; something man-made (as opposed to
something that occurs naturally).
Poorly understood problem. While it is usually easy to specify a design problem
superficially (e.g. a new commuter train is needed between Union Station and Pearson
International Airport), it can be extremely difficult to gain an understanding of the
problem that is deep and broad enough, that designers can design a solution easily.
What’s more, customers/clients/users rarely understand the problem themselves. It is
through consultation with clients and users that designers finally gain a sufficient

understanding of the problem, to start designing a solution.
Context. The context of a design is more than just the environment into which the
designed product will be introduced. It includes the companies involved in the
product’s development, the people who will work on the project, government agencies
and regulatory bodies, economic factors, legal and ethical factors, and other
circumstances. It is virtually impossible to track every possible contextual factor in a
design problem, but there is tremendous corporate knowledge available, depending on
the product class and industry, about which factors are the most crucial.

18


Promote. There are few guarantees in design engineering, because design is partly
about predicting the future. Companies and managers who insist on success are only
setting themselves up for failure and will build companies that are brittle – that cannot
handle product or engineering failures. Instead, successful companies are adaptable to
failure; they realize the best they can do is work generally towards what they hope are
better situations.
Preferred situation. We can never reach the 100% perfect solution, but it is important
to have such ideals. With ideals, one knows “where to aim” to achieve success. So long
as new products move an environment towards the ideal we have improved the general
quality of life, and that is the best we can expect.
Generic Product Development Processes
A generic product development process showing the five major stages and the roles
played by different disciplines in each stage:

19


Figure 2: Generic Product Development Processes

The stages and gates indicated on the horizontal axis are taken from the STAGE-GATE
method1.
Horizontally, the figure identifies five stages of product development. (One should
imagine time on the horizontal axis.) Each stage is separated from the next by a gate.
Gates are checkpoints at which the status of a product is reviewed carefully; only
projects that meet the requirements of a gate are allowed to proceed to the next stage.

1

Trademark in Canada, The Product Development Institute, Inc. See:

20


Vertically, down the left side of the figure, the principal sectors of product development
are listed. Each sector covers an area of expertise, and is involved with a variety of
tasks throughout the PDP. Some of the typical tasks undertaken by each sector are
given, running across the five stages.
2.2.2 Software Development Processes

Software engineering and software process improvement standards are gaining more
and more attention. Why is this? First, standards are recognized by the software
industry as a way for transferring good practice into industrial use. Agencies procuring
software are focusing on standards as they want to be sure that a certain level of
quality, associated with the standard, has been followed during the development of the
software and hence has improved the quality of the software itself. Moreover, standards
are used as the basis against which organizations and/or software products are certified.
Finally, if two organizations that enter cooperation for the development of a software
product follow the same standards, the cooperation will be considerably simplified.

In the last few years there have been a number of standardization initiatives from
which software development organizations benefit. Three different directions can be
distinguished:
a) Definition of standard processes. These focus on the key points to be
addressed to provide an effective and well defined quality manual. ISO 9000 [ISO91],
the ESA process standard PSS-05 [MFM+94], and ISO 12207 [ISO95] are some
examples.
b) Definition of assessment method. These provide guidelines to evaluate the
maturity of the process carried out by an organization. The Software Engineering
Institute’s Capability Maturity Model (CMM) [Hum89], the European Bootstrap
Method [KSK+94], and ISO 15504 [ISO97b] are examples of these. They are all based
21


on some model of maturity. These models identify different maturity levels, and an
assessment method, which collocates an organization in one of the maturity levels.
c) Definition of methods supporting the improvement of an existing process. For
instance, the Quality Improvement Paradigm [Bas93] is based on the idea that process
improvement can be accomplished only if the organization is able to learn from
previous experiences. During the execution of a project some suitable measures are
performed, and the collected data are analyzed and packaged for future uses. Some
assessment methods also provide improvement guidelines.
Standard processes
1. ISO 9000
ISO 9000 supplies a set of standards for quality management of production activities.
Organizations are supposed to set up a quality system in order to supervise all phases
of a production and delivery process. Some of the activities carried out by the quality
system are:
a) Auditing the projects to ensure that quality controls are respected,
b) Improving the quality system itself, and

c) Providing input to the development group, such as new notations, procedures,
and standards; producing reports to the high-level management.
The details of the quality system are contained in a quality manual. It contains
standards for the quality and the development activities.
When a new project is planned, the project manager identifies the quality issues
relevant for the project and extracts them. All procedures and standards need to ensure

22


that the defined quality levels are extracted from the quality manual and that a quality
plan is written that identifies the means for quality control.
ISO 9000 has been specialized for software production because it has been recognized
as different from general purpose production processes. The result of this
customization is ISO 9000. The basic ideas are the following:
a) Quality control should be performed during all phases of software production,
procurement and maintenance.
b) The purchaser should always strictly cooperate with the software product
supplier.
c) The supplier should define its quality system and ensure its entire
organization understands and implements the system.
ISO 9000 does not impose a specific life-cycle model. It also does not provide specific
methods for the evaluation of quality ensurance capabilities of organization. It,
therefore, can be coupled with more specific approaches, such as The Capability
Maturity model.
ISO 9000 can be used in contractual situations, when the purchaser and the supplier
establish that some quality elements will be part of the suppliers quality system, and
the supplier commits to follow the quality principles defined in the standard. Moreover,
it can be exploited in non-contractual situations, when the supplier voluntarily applies
the quality standard in order to be competitive and to ensure a good quality of its

products.
2. PSS-05

The European Space Agency (ESA) adopted PSS-05 as a software engineering
standard that is binding for all software that is either procured or developed in-house
23


by ESA. The standard takes two different perspectives; it contains standards, guidelines
and recommendations concerning the software to be defined, implemented, operated
and maintained; it also determines procedures that are to be used to manage a software
project.
The standard is based on the concept of practices. Practices in PSS-05 are mandatory,
recommended or guiding. A mandatory practice must be followed without exception in
all software projects. Recommended practices may or may not be followed. However, a
justification has to provide if a recommended practice is abandoned. Guideline
practices are less crucial; no justification is needed if they are not followed.
PSS-05 does not prescribe a particular lifecycle model. However, any lifecycle model
adopted for a project must be defined in a software project management plan and must
include the following mandatory phases:
a) Definition of user requirements,
b) Definition of software requirements,
c) Definition of architectural design,
d) Detailed design and production of code,
e) Transfer of the software to operations, and
f) Operations and maintenance.

Practices related to management procedures are of concern throughout the different
phases identified earlier. The purpose of these is to ensure that projects are managed in
such a way that the product is built within budget, according to schedule and with the

required quality.
24


The standard recommends the mandatory definition of plans for:
a) Software project management,
b) Software configuration management,
c) Software verification and validation, and
d) Software quality assurance.
To date, the use of PSS-05 is not confined to ESA and its contractors. It is being used
in the automobile industry and for procurements in various European defense projects.
Currently, PSS-05 is being used as one basis for the ISO 15288, a new system
engineering standard.
3. ISO-12207
ISO 9000 is a standard for quality management and improvement, but it provides little
concrete guidance as to how software engineering processes should be performed. The
ISO standard 12207 “software life cycle processes is more concrete in that it identifies
mandatory processes, tasks and activities for software life cycles. Unlike PSS-05,
which has been explicitly defined for one particular domain, ISO-12207 is intended to
be applicable to software development in a broad range of application domains and a
variety of different software systems.
Any ISO standard contains a normative and an informative component. The normative
component in ISO-12207 determines mandatory practices that ought to be followed for
a particular development effort to be compliant to the standard. The informative
component of the standard identifies rationales for the practices required by the
standard and explains their application.

25