1.

0 INTRODUCTION
Software engineering referring to systematic procedure that is used in the context of a
generally accepted set of goals for the analysis, design, implementation, testing and
maintenance of software. The software that have been produced should be efficient,
usable, reliable, modifiable, portable, testable, reusable, interoperable and maintainable.
Software engineering cannot be avoided from the field of software development. The
development of computers introduced the need for software and the quality of software
introduced the need for software engineering. There are many different activities that are
typically part of systematic process of software engineering. The activities can occur in a
rigid sequence, with each activity completed before the next one begins, or several of the
activities can occur simultaneously. The timing of these activities and the choice between
iterative and noniterative methods are often described by what are known as software
development models.
1.1 Overview of Software Development Life Cycle
The software development life cycle or SDLC is used to facilitate the development of
a large software product in a systematic, well defined and cost effective way. An
information system goes through a series of phases from conception to
implementation. Various reasons for using a life cycle model include:
 Helps to understand the entire process
 Enforces a structured approach to development
 Enables planning of resources in advance
 Enables subsequent controls of them
 Aids management to track progress of the system
The SDLC consists of several phases and need to be identified along with defining the
entry and exit criteria for every phase. A phase can begin only when the
corresponding phase entry criteria are satisfied. It becomes very difficult to track the
progress of the project, if there is no clear indication of the entry and exit for every
phase. The SDLC can be divided into 5-9 phases as in Figure 1.0. On average it has
seven or eight phases. These are:
 Project initiation and planning/Recognition of need/Preliminary investigation
The first stage of any project or SDLC is called the preliminary investigation.
 This investigation provides the organization’s steering committee and any
project team a set of terms or references for more detailed work.
 Feasibility study
To investigates the information needs and determines the resource
requirements, costs, benefits, and feasibility of a proposed project. The goal is
to evaluate alternative systems and to propose the most feasible and desirable
systems for development.
 Project Analysis
A detailed study of the various operations performed by a system and their
relationships within and outside the system.
 System Design
System design is the most creative and challenging phase of the SDLC. The
term design describes the final system and process by which it is developed.
 Coding
To translate the design of the system into code in a given programming
language. In this phase the aim is to implement the design in the best possible
manner.
 Testing
Its basic function is to detect errors in the software. The goal of testing is to
uncover requirement, design, and coding errors in the program.
 Implementation
It is mainly concerned with user training, site selection, and preparation and
file conversion. Once the system has been designed, it is ready for
implementation.
 Maintenance
Maintenance is an important part of the SDLC. If there is any error to correct
or change then it is done in the maintenance phase. Many times maintenance
may consume more time than the time consumed in the development.
Figure 1.0 Software Development Life Cycle

Base on the phase above, there are many models of SDLC as below:
 Classical waterfall model
 Rapid prototyping model
 Spiral model
 Market-driven model
 Open source development model
 Agile development model
And the purpose of this assignment is to discuss more on agile methodology as part of
software engineering.
2.0 Description of Agile
2.1 Definition
Agile is a software development methodology to build a software incrementally
using short iterations is to align with the changing business needs, customer focused
and encourage customer guidance and participation. Agile methodologies is a
software development method that is:
 Flexible - Ready to adapt to expected change at any time.
 Speedy - Rapid and iterative development of the product in small releases.
 Lean - Focuses on shortening timeframe and cost and on improved quality
 Responsive - Reacts to expected or unexpected changes.
 Learning - Focuses on improvement during and after product
development.
It is based on iterative and incremental development, where requirements and
solutions evolve through collaboration between self-organizing, cross-functional
teams. It will lead to adaptive planning, evolutionary development and delivery, a
time-boxed iterative approach, and encourages rapid and flexible response to
change. Agile methodology process framework that adopts the iterative approach,
open collaboration, and process adaptability throughout the life cycle of the
project. This iterative agile approach is more flexible and its short time-span
iterations seek improvement for the project in small release, with minimal
planning, rather than plan at length. This helps to minimize the overall risk, and
allows the project to adapt to changes more quickly. Agile development process
follows a different development sequence
2.2 Manifesto
The agile manifesto purpose are:
"We are uncovering better ways of developing software by doing it and helping
others do it. We value:
Individuals and interactions over processes and tools.
- Valuing people are more highly than processes and it is easy to understand
because the people who respond to business needs and drive the
development process. If the process or the tools drive development, the team
is less responsive to change and less likely to meet customer needs. The
 example of this value is communication that is fluid and happens when need
arises.
Working software over comprehensive documentation.
- Agile does not eliminate documentation, but it values working software
more. Agile documents requirements as user stories, which are sufficient for
a software developer to begin the task of building a new function.
Customer collaboration over contract negotiation.
- This manifesto describes a customer who is engaged and collaborates
throughout the development process, making. Agile methods may include
the customer at intervals for periodic demos, but a project could just as
easily have an end-user as a daily part of the team and attending all
meetings, ensuring the product meets the business needs of the customer.
Responding to change over following a plan.”
- With Agile, the shortness of an iteration means priorities can be shifted from
iteration to iteration and new features can be added into the next iteration.
Agile’s view is that changes always improve a project; changes provide
additional value.
2.3 Principles
There are twelve principles of agile development as describe below:
 Highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
- Customers are happier when they receive working software at regular
intervals, rather than waiting extended periods of time between releases.
 Accommodate changing requirements throughout the development process.
- The ability to avoid delays when a requirement or feature request changes.
 Frequent delivery of working software.
- Scrum accommodates this principle since the team operates in software
sprints or iterations that ensure regular delivery of working software.
 Collaboration between the business stakeholders and developers throughout the
project.
- Better decisions are made when the business and technical team are
aligned.
 Support, trust, and motivate the people involved.
- Motivated teams are more likely to deliver their best work than unhappy
teams.
 Enable face-to-face interactions
- Communication is more successful when development teams are co-
located.
 Working software is the primary measure of progress
- Delivering functional software to the customer is the ultimate factor that
measures progress.
 Agile processes to support a consistent development pace
- Teams establish a repeatable and maintainable speed at which they can
deliver working software, and they repeat it with each release.
 Attention to technical detail and design enhances agility
- The right skills and good design ensures the team can maintain the pace,
constantly improve the product, and sustain change.
 Simplicity
- Develop just enough to get the job done for right now.
 Self-organizing teams encourage great architectures, requirements, and designs
- Skilled and motivated team members who have decision-making power,
take ownership, communicate regularly with other team members, and
share ideas that deliver quality products.
 Regular reflections on how to become more effective
- Self-improvement, process improvement, advancing skills, and techniques
help team members work more efficiently.
3.0 Description of Type of Agile
3.1 Type of Agile & Explanation
3.1.1 Extreme Programming (XP)
- Focus on customer satisfaction.
- Requires maximum customer interaction to develop the software.
- It divides the entire software development life cycle into several
number of short development cycles which inherently improves the
productivity of the system and also introduces a checkpoint where any
customer requirements can be easily implemented.
- Very helpful when there is constantly changing requirements from the
customers or when they are not sure about the functionality of the
system.
- Business requirements are gathered in terms of stories.
- There are 5 phases in this method (Exploration, Planning, Iterations to
Release, Productionizing, and Maintenance & Closure).
3.1.2 Scrum
- Refers to adaptive, quick, self-organizing product development
process.
- ‘Scrum’ derives from a strategy in the game of rugby – “getting an out-
of play ball back into the game” with team work.
- An empirical approach applying the ideas of industrial process control
theory to systems development, resulting that reintroduces the ideas of
flexibility, adaptability and productivity.
- No specific software development techniques for the implementation
of a software.
- Concentrates on the team members should function to produce the
system flexibly in a constantly changing environment.
3.1.3 Feature Driven Development (FDD)
- Focused on designing & building phases.
- Designed to work with other activities of software development project
and does not require process model to be used.
 - Emphases quality aspects throughout the process, includes frequent
and tangible deliveries along with accurate monitoring of the progress
of the project.
- Consists five sequential processes and provide the methods, techniques
and guidelines needed by the project stakeholders.
- Include the roles, artifacts, goals and timelines needed in a project.
3.1.4 The Rational Unified Process
- Developed at Rational Corporation to complement UML (an industry-
standard software modelling method.
- An iterative approach for object-oriented systems and embraces use
cases for modelling requirements and building the foundation for a
system.
- It does not implicitly rule out other methods, although the proposed
modelling method, UML, is particularly suited for OO development.
- Consists four phases (Inception, Elaboration, Construction and
Transition)
3.1.5 Dynamic Software Development Method (DSDM)
- Approach to software development and provides an agile project
delivery framework.
- Users are involved actively and the teams are given the power to make
decisions.
- Non-profit and non-proprietary framework for Rapid Application
Development (RAD) and maintained by the DSDM Consortium.
- Focus on fix time, resource and adjust the amount of functionality
accordingly.
4.0 Comparison Between Each Type of Agile
4.1 Extreme Programming (XP)
4.1.1 Process

Figure 4.0 Life Cycle Of XP Process

1. Exploration
 Customers write the story cards that included in the first release and added into the program.
 Takes a few week to months, depending programmers familiar with the technology.
2. Planning
 Sets the priority order for the stories
 Agreement of the contents of the first small release is made.
 Programmers estimate effort for each story and the schedule is the agreed upon.
 3. Iterations to Release
 The first iteration creates a system with the architecture of the whole system.
 The customer decides the stories to be selected for each iteration.
 The functional tests created by the customer are run at the end of every iteration and the last iteration is
ready for production.
4. Productionizing
 Requires extra testing and checking before the system can be released to the customer.
5. Maintenance & Death (Closure)
 When customer no longer have any stories to be implemented.
 The necessary documentation is finally written as no more changes to the architecture, design or code
are made.
4.1.2 Roles & 1. Programmer
Responsibilities  Write tests and keep the program code as simple and definite as possible.
2. Customer
 Writes the stories and functional tests, and decides when each requirement is satisfied.
 Sets the implementation priority for the requirements.
3. Tester
 Run functional tests regularly, broadcast test results and maintain testing tools.
4. Tracker
 Gives feedback to improve future estimations.
 Traces the progress of each iteration
  Evaluates whether the goal is reachable
5. Coach
 Responsible for the process as a whole.
6. Consultant
 Guides the team in solving their specific problems.
7. Manager
 Communicates with the project team.
 Determine the current situation.
 Distinguish any difficulties or deficiencies in the process.
4.1.3 Practice 1. Planning Game
s  Programmers estimate the effort needed for the implementation.
2. Small Release
 A simple system is productionized rapidly.
3. Metaphor
 The system is defined by a metaphor between customer and programmers.
4. Simple design
 Designing the simplest that is implementable.
5. Testing
 Software development is test driven.
6. Refactoring
 Restructuring the system by removing duplication, improving communication, simplifying and adding
 flexibility.
7. Pair Programming
8. Collective ownership
9. Continuous integration
10. On site customer
11. Coding standards
12. Open workspace
4.1.4 Scope  Small and medium sized teams. (3 to 20 members)
 Communication and coordination between project members enabled at all times.
 A technology that does not support demands a long feedback time is not suitable.

4.2 Scrum
4.2.1 Process

Figure 4.1 Scrum Process

1. Pregame Phase
 Planning – Definition of system (a product backlog list is created containing all requirements).
 Architecture Phase – Planned based on current item in the product backlog.
2. Development Phase
 The different environmental and technical variables (such as time frame, quality, requirements, resources,
implementation technologies and tools, and even development methods) identified.
 3. Post-game Phase
 The system ready for the release including the tasks such as the integration, system testing and
documentation.
4.2.2 Roles & 1. Scrum Master
Responsibilitie  Ensuring the project is carried through according to the practices.
s  Ensuring impediments are removed and changed in the process to keep the team working as productively
as possible.
2. Product Owner
 Responsible for the project, managing, controlling and making visible the Product Backlog list.
3. Scrum Team
 Has the authority to decide necessary actions and to organize itself to achieve the goals of each Sprint.
4. Customer
 Participates in the tasks related to product Backlog items
5. Management
 Setting of goals and requirements.

4.2.3 Practices 1. Product Backlog

 Defines everything needed in the final product based on current knowledge.
2. Effort Estimation
 An iterative process, in which the Backlog items estimates are focused on a more accurate level
3. Sprint
  The procedure of adapting to the changing environmental variables (requirements, time, resources,
knowledge, technology etc.).
4. Sprint Planning Meeting
 A two-phase meeting organized by the Scrum Master.
5. Sprint Backlog
 It is a list of Product Backlog items selected to be implemented in the next Sprint.
6. Daily Scrum Meeting
 Organized to keep track of the Scrum Team progress continuously and also serve as planning meetings.
7. Scrum Review Meeting
 May bring out new Backlog items and even change the direction of the system being built.
4.2.4 Scope  Is a method suitable for small teams of less than 10 members (5 to 9 project members).

4.3 FDD
4.3.1 Process

Figure 4.2 Process of FDD

1. Develop and Overall Model
 The domain experts present a so called “walkthrough”, where the team members and the chief architect are
informed of the high-level description of the system.
 The overall domain divided into different domain areas and a more detailed walkthrough is held for each of
them by the domain members.
 The development team discusses and decides upon the appropriate object models for each of the domain
areas.
2. Build a Features List
 The development team presents each of the client valued functions included in the system.
 The functions are presented for each of the domain areas and consist major feature sets.

3. Plan by Feature
  The feature sets are sequenced according to their priority and dependencies and assigned to Chief
Programmers.
 The classes identified in the “developing of an overall model” process are assigned to individual developers.
4. Design by Feature & Build by Feature
 A small group of features is selected from the feature sets and feature teams needed for developing the
selected features are formed by the class owners.
 There can be multiple feature teams concurrently designing and building their own set of features.
 This iterative process includes such tasks as design inspection, coding, unit testing, integration and code
inspection.
4.3.2 Roles & 1. Project Manager
Responsibilitie
 Administrative and financial leader of the project.
s
 Protect the project team from outside distractions.

 Providing team with appropriate working conditions.

2. Chief Architect

 Responsible for the overall design of the system.

3. Development Manager

 Leads daily development activities and solves any conflicts that may occur within the team.

4. Chief Programmers
  Responsible for leading small teams in the analysis, design and development of new features.

5. Class Owner

 Responsible for the development of the class he has been assigned to be the owner for.

6. Domain Expert

 To possess the knowledge of how the different requirements for the system under development should
perform.
4.3.3 Practices 1. Domain Object Modeling
 Exploration and explanation of the domain of the problem. Results in a framework where the features are
added.
2. Developing by Feature
 Developing and tracking the progress through a list of small functionally decomposed and client-valued
functions.
3. Individual Class (Code) Ownership
 Each class has a single person nominated to be the one responsible for the consistency, performance and
conceptual integrity of the class.
4. Feature Teams
 Refers to small, dynamically formed teams

5. Inspection
 Refers to the use of the best-known defect-detection mechanisms.
 6. Regular Builds
 Refers to ensuring that there is always a running, demonstrable system available. Regular builds form the
baseline to which new features are added.
7. Configuration Management
 Enables the identification and historical tracking of the latest versions of each completed source code
file.
8. Progress reporting
 Progress is reported based on complete work to all necessary organizational levels.
4.3.4 Scope  Worthy of serious consideration by any software development organization that needs to deliver quality,
business-critical software systems on time.

4.4 RUP
4.4.1 Process

Figure 4.3 RUP Process

1. Inception
 Critical use cases are identified.
 Candidate architectures are devised, the schedule and cost are estimated for the entire project.
2. Elaboration
 The project plan is defined.
 The process, infrastructure and development environment are described in detail.
 Use cases, actors and the software architecture have been identified and described and an executable
prototype of the architecture created.
3. Construction
 All remaining components and application features are developed and integrated into the product, and
tested.

4. Transition
  Consists of beta testing, piloting, training the users and maintainers of the system, and rolling the product
out to marketing, distribution, and sales teams.
 User documentation also produced.
4.4.2 Roles & 1. Business Process Analyst
Responsibilitie  Leads and coordinates the defining of the business use cases.
s  Defines the business object model.
2. Business Designer
 Identifies and documents the roles and entities within the organization.
3. Business Model Reviewer
 Reviews all of the artifacts produced by the Business-Process Analyst and the Business Designer.
4. Course Developer
 Produces course material (tutorials, slides) for the end users.
5. Toolsmith
 Develops in-house tools to support development, to enhance automation for tedious, repeating tasks, and
to improve the integration between tools.
4.4.3 Practices 1. Develop Software Iteratively
 Software is developed in small increments and short iterations
2. Manage Requirements
 A disciplined approach for managing requirements is required, where the requirements can be prioritized,
filtered and traced.
3. Use Component-based Architectures
 Building reusable components can potentially save a substantial amount of future development effort.
 4. Visually Model Software
 Using UML among the development team, system architecture and design can be captured
unambiguously.
5. Verify Software Quality
 By testing during every iteration, defects can be identified earlier on in the development cycle.
6. Control Changes to Software
 Any changes to requirements must be managed, and their effect on software must be traceable.
4.4.4 Scope The complete RUP, lists over a hundred use cases to be produced in the various process stages, necessitating
rigorous screening, through which only the essential ones are adopted.

4.5 DSDM
4.5.1 Process
4.5.2 Roles &
Responsibilitie
s
4.5.3 Practices
4.5.4 Scope
4.2 Agile Benefits To Software Project
5 Conclusion
References