ISI3195_Sofware Engineering – INGE3_ISI

Instructor: Ytembe Dankam Therese

I. Agile Software Engineering

The meaning of Agile is swift or versatile. "Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into smaller
iterations, or parts do not directly involve long term planning. The project scope and
requirements are laid down at the beginning of the development process. Plans regarding the
number of iterations, the duration and the scope of each iteration are clearly defined in advance.

Each iteration is considered as a short time "frame" in the Agile process model, which typically
lasts from one to four weeks. The division of the entire project into smaller parts helps to
minimize the project risk and to reduce the overall project delivery time requirements. Each
iteration involves a team working through a full software development life cycle including
planning, requirements analysis, design, coding, and testing before a working product is
demonstrated to the client.
Phases of Agile Model:

Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing / Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project. Based
on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders to
define requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and
looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.
 II. Agile Development Methods

o Scrum
o Crystal
o Dynamic Software Development Method(DSDM)
o Feature Driven Development(FDD)
o Lean Software Development
o eXtreme Programming(XP)

Scrum

SCRUM is an agile development process focused primarily on ways to manage tasks in team-
based development conditions.

There are three roles in it, and their responsibilities are:

o Scrum Master: The scrum can set up the master team, arrange the meeting and remove
obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes the delay
and is responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete the sprint
or cycle.

eXtreme Programming(XP)

XP is also a lightweight methodology or what Alistair Cockburn calls a “Crystal Methodology”.

In short, methodologies of this family have high productivity and high tolerance.
Communication is usually strong with short paths, especially informal (not documented). There
is only a small range of deliverables (artifacts), but these are delivered frequently (releases).
Processes of the Crystal family identify only a few roles and activities.

This type of methodology is used when customers are constantly changing demands or
requirements, or when they are not sure about the system's performance.
Crystal:

There are three concepts of this method-

1. Chartering: Multi activities are involved in this phase such as making a development
team, performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
A. Team updates the release plan.
B. Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment, post-
deployment.

XP regards a software development project as a system of four control “variables”: Cost, Time,
Quality and Scope. Note that these are only the names of the variables which XP identifies, not
the general terms used Software Engineering.
· Cost: The amount of money to be spent. The resources (how many developers, equipment
etc.) available for the project are directly related to this variable. · Time Determines when the
system (release) should be done.
· Quality: The correctness of the system (as defined by the customer) and how well tested it
will be. · Scope Describes what and how much will be done (functionality). Time is the central
variable in XP. The fundamental dependencies between it and the other variables are:
· Increasing quality can increase the time that is needed because of more testing.
Decreasing quality can reduce time to a certain degree (via reduction of the number of
functional tests).

· Increasing cost (hiring more developers or providing better equipment) can mean less time
but also the opposite effect is possible – for instance hiring more developers late in the project
can increase time because of the overhead of communication.

Decreasing cost increases time dramatically. · Increasing scope means more time is needed
because there is more work to do. Decreasing scope reduces time. This is the core control
relationship in XP.
XP explicitly deals with the first risk: “Embrace Change”.

This means, the customer always has the right and the chance to change the requirements:

 The customer is part of the development team. He or she receives frequent releases so
that he/she can see whether the system is what he wants
 He or she writes the requirements (User Stories)
 The team is honest. For every story it will confidently estimate how long it will take to
implement the story so that the customer can decide how much is to be done or when it
should be finished (see Planning Game).

The process of XP is designed to make a change of direction possible at any stage. However
this means that projects for which most requirements can be determined in advance won’t profit
from XP. These projects should probably be done with more conventional methodologies

Dynamic Software Development Method (DSDM):

DSDM is a rapid application development strategy for software development and gives an agile
project distribution structure. The essential features of DSDM are that users must be actively
connected, and teams have been given the right to make decisions. The techniques used in
DSDM are:

1. Time Boxing
2. MoSCoW Rules
3. Prototyping

The DSDM project contains seven stages:

1. Pre-project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
 6. Implementation
7. Post-project

Feature Driven Development(FDD):

This method focuses on "Designing and Building" features. In contrast to other smart methods,
FDD describes the small steps of the work that should be obtained separately per function.

Lean Software Development:

Lean software development methodology follows the principle "just in time production." The
lean method indicates the increasing speed of software development and reducing costs. Lean
development can be summarized in seven phase

1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole

When to use the Agile Model?

o When frequent changes are required.

o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.
Advantage (Pros) of Agile Method:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages (Cons) of Agile Model:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions
taken throughout various phases can be misinterpreted at any time by different team
members.
2. Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.

III. ISO Standards in Software Engineering

The mission of the International Standard Organization is to market the development of

standardization and its related activities to facilitate the international exchange of products
and services. It also helps to develop cooperation within the different activities like spheres
of intellectual, scientific, technological, and economic activity.

ISO 9000 Quality Standards

It is defined as the quality assurance system in which quality components can be

organizational structure, responsibilities, procedures, processes, and resources for
implementing quality management. Quality assurance systems are created to help
organizations ensure their products and services satisfy customer expectations by meeting
their specifications.

Different types of ISO standards

 ISO 9000: 2000 –

ISO 9000: 2000: contains Quality management systems, fundamentals, and vocabulary.

 ISO 9000-1: 1994 –

This series of standards includes Quality management systems and Quality assurance
standards. It also includes some guidelines for selection and use.

 ISO 9000-2: 1997 –

 This series of standards also includes Quality management systems and Quality assurance
standards. It also includes some guidelines for the application of ISO 9001, ISO 9002, and
ISO 9003.

 ISO 9000-3: 1997 –

This series contains Quality management systems, Quality assurance standards and also
includes guidelines for the application of ISO 9001 to 1994 to the development, supply,
installation, and maintenance of computer installation.

 ISO 9001: 1994 –

This series of standards has Quality systems and a Quality assurance model. This model
helps in design, development, production, installation, and service.

 ISO 9001: 2000 –

This series of standards also includes Quality management systems.

 ISO 9002: 1994 –

This series of standards also includes some Quality systems. This Quality assurance
model used in production, installation, and servicing.
 ISO 9003: 1994 –
This series of standards also includes some Quality systems. This Quality assurance
model used in the final inspection and test.

 ISO 9004: 2000 –

This series of standards include some Quality management systems. It also includes
some guidelines for performance improvements.

 ISO 9039: 1994 –

This series of standards include some Optics and Optical Instruments. It includes quality
evaluation of optical systems and determination of distortion.

 ISO/IEC 9126-1: 2001 –

This series of standards has information technology. It also includes some software
products, quality models.

 ISO/IEC 9040: 1997 –

This series of standards has information technology. It also includes open system
interconnection and Virtual terminal basic class service.

 ISO/IEC 9041-1: 1997 –

This series of standards has information technology. It also includes open system
interconnection, Virtual terminal basic class service protocol, and specification.

 ISO/IEC 9041-2: 1997 –

This series of standards include information technology, open system interconnection,
Virtual terminal basic class protocol, and Protocol implementation conformance
statement (PICS) proforma.

 ISO/IEC 9075-9: 2001 –

This series of standards has information technology, Database languages, and
SQL/MED (Management of External Data).
 ISO/IEC 9075-10: 2000 -|
These series of standards has information technology, Database languages, and
SQL/OLB (Object Language Bindings).

 ISO/IEC 9075-13: 2002

These series of standards has information technology, Database languages, SQL
routines, and Java Programming language. (SQL/JRT).

IV The ISO/EEC 12207 Standard

ISO/IEC/IEEE 12207:2017 is the newest version, published in November 2017. The IEEE
Computer Society joined directly with ISO/IEC JTC 1/SC 7/WG 7 in the editing process for
this version. A significant change is that it adopts a process model identical to
the ISO/IEC/IEEE 15288:2015 process model (there is one name change, the 15288 "System
Requirements Definition" process is renamed to the "System/Software Requirements
Definition" process). This harmonization of the two standards led to the removal of separate
software development and software reuse processes, bringing the total number of 43 processes
from 12207 down to the 30 processes defined in 15288. It also caused changes to the quality
management and quality assurance process activities and outcomes. Additionally, the definition
of "audit" and related audit activities were updated. Annex I of ISO/IEC/IEEE 12207:2017
provides a process mapping between the 2017 version and the previous version, including the
primary process alignments between the two versions; this is intended to enable traceability and
ease transition for users of the previous version.

Prior versions include:

 ISO/IEC 12207:2008, which was published in February 2008

 ISO/IEC 12207:1995/Amd 2:2004, an amended version of the prior, published in
November 2004
 ISO/IEC 12207:1995/Amd 1:2002, an amended version of the prior, published in May 2002
 ISO/IEC 12207:1995, the first iteration, published in July 1995; originally was divided into
five primary processes (acquisition, supply, development, operation, and maintenance),
with eight supporting and four organizational life cycle processes
IEEE versions

Prior to the IEEE Computer Society formally joining the editing process (becoming a major
stakeholder) for the 2017 release, the IEEE maintained its own versions of ISO/IEC 12207,
initially with modifications made jointly with the Electronic Industries Alliance (EIA). With
the 2008 update came a "shared strategy of ISO/IEC JTC 1/SC 7 and the IEEE to harmonize
their respective collections of standards," resulting in identical standards thereon, but with
slightly different names. Those IEEE versions included:

 IEEE Std. 12207-2008: "integrates ISO/IEC 12207:1995 with its two amendments and was
coordinated with the parallel revision of ISO/IEC 15288:2002 (System life cycle processes)
to align structure, terms, and corresponding organizational and project
processes"; superseded by ISO/IEC/IEEE 12207:2017
 IEEE/EIA 12207.2-1997: "provides implementation consideration guidance for the
normative clauses of IEEE/EIA 12207.0"; superseded/made obsolete by IEEE Std. 12207-
2008, which was then superseded by ISO/IEC/IEEE 12207:2017
 IEEE/EIA 12207.1-1997: "provides guidance for recording life cycle data resulting from
the life cycle processes of IEEE/EIA 12207.0"; superseded by ISO/IEC/IEEE 15289:2011,
which was then superseded by ISO/IEC/IEEE 15289:2017
 IEEE/EIA 12207.0-1996: "consists of the clarifications, additions, and changes [to ISO/IEC
12207:1995 for industry implementation] accepted by the Institute of Electrical and
Electronics Engineers (IEEE) and the Electronic Industries Alliance (EIA) as formulated
by a joint project of the two organizations" superseded by IEEE Std. 12207-2008, which
was then superseded by ISO/IEC/IEEE 12207:2017

It's also worth noting that IEEE/EIA 12207 officially replaced MIL-STD-498 (released in
December 1994) for the development of software systems on May 27, 1998.

Processes not stages

The standard establishes a set of processes for managing the lifecycle of software. The standard
"does not prescribe a specific software life cycle model, development methodology, method,
modelling approach, or technique. Instead, the standard (as well as ISO/IEC/IEEE 15288)
distinguishes between a "stage" and "process" as follows:

 Stage: "period within the life cycle of an entity that relates to the state of its description or
realization". A stage is typically a period of time and ends with a "primary decision gate".
 Process: "set of interrelated or interacting activities that transforms inputs into outputs".
The same process often recurs within different stages.

Stages (aka phases) are not the same as processes, and this standard only defines specific
processes - it does not define any particular stages. Instead, the standard acknowledges that
software life cycles vary, and may be divided into stages (also called phases) that represent
major life cycle periods and give rise to primary decision gates. No particular set of stages is
normative, but it does mention two examples:

 The system life cycle stages from ISO/IEC TS 24748-1 could be used (concept,
development, production, utilization, support, and retirement).
 It also notes that a common set of stages for software is concept exploration, development,
sustainment, and retirement.

The life cycle processes the standard defines are not aligned to any specific stage in a software
life cycle. Indeed, the life cycle processes that involve planning, performance, and evaluation
"should be considered for use at every stage". In practice, processes occur whenever they are
needed within any stage.

Processes

ISO/IEC/IEEE 12207:2017 divides software life cycle processes into four main process groups:
agreement, organizational project-enabling, technical management, and technical processes.
Under each of those four process groups are a variety of sub-categories, including the primary
activities of acquisition and supply (agreement); configuration (technical management); and
operation, maintenance, and disposal (technical).

Agreement processes:

Here ISO/IEC/IEEE 12207:2017 includes the acquisition and supply processes,[1][2][16] which
are activities related to establishing an agreement between a supplier and acquirer. Acquisition
covers all the activities involved in initiating a project. The acquisition phase can be divided
into different activities and deliverables that are completed chronologically. During the supply
phase a project management plan is developed. This plan contains information about the project
such as different milestones that need to be reached.
Organizational project-enabling processes.

Detailed here are life cycle model management, infrastructure management, portfolio
management, human resource management, quality management, and knowledge
management processes. These processes help a business or organization enable, control, and
support the system life cycle and related projects. Life cycle model management helps ensure
acquisition and supply efforts are supported, while infrastructure and portfolio management
supports business and project-specific initiatives during the entire system life cycle. The rest
ensure the necessary resources and quality controls are in place to support the business' project
and system endeavors. If an organization does not have an appropriate set of organizational
processes, a project executed by the organization may apply those processes directly to the
project instead.

Technical management processes

ISO/IEC/IEEE 12207:2017 places eight different processes here

 [Project planning]
 Project assessment and control
 Decision management
 Risk management
 Configuration management
 Information management
 Measurement
 Quality assurance

These processes deal with planning, assessment, and control of software and other projects
during the life cycle, ensuring quality along the way.

Technical processes

The technical processes of ISO/IEC/IEEE 12207:2017 encompass 14 different processes, some

of which came from the old software-specific processes that were phased out from the 2008
version.

The full list includes :

 Business or mission analysis

 Stakeholder needs and requirements definition
 Systems/Software requirements definition
 Architecture definition
 Design definition
 System analysis
 Implementation
 Integration
 Verification
 Transition
 Validation
 Operation
 Maintenance
 Disposal

These processes involve technical activities and personnel (information technology,

troubleshooters, software specialists, etc.) during pre-, post- and during operation. The analysis
and definition processes early on set the stage for how software and projects are implemented.
Additional processes of integration, verification, transition, and validation help ensure quality
and readiness. The operation and maintenance phases occur simultaneously, with the operation
phase consisting of activities like assisting users in working with the implemented software
product, and the maintenance phase consisting of maintenance tasks to keep the product up and
running. The disposal process describes how the system/project will be retired and cleaned up,
if necessary.

Conformance

Clause 4 describes the document's intended use and conformance requirements. It is expected
that particular projects "may not need to use all of the processes provided by this document."
In practice, conforming to this standard normally involves selecting and declaring the set of
suitable processes. This can be done through either "full conformance" or "tailored
conformance".

"Full conformance" can be claimed in one of two ways. "Full conformance to tasks" can be
claimed if all requirements of the declared processes' activities and tasks are met. "Full
conformance to outcomes" can be claimed if all required outcomes of the declared processes
are met. The latter permits more variation.
"Tailored conformance" may be declared when specific clauses are selected or modified
through the tailoring process also defined in the document.