0% found this document useful (0 votes)
9 views79 pages

Unit 1.1.the Systems Development Environment

The document provides an overview of System Analysis and Design, detailing the components and characteristics of systems, including inputs, outputs, processes, and feedback mechanisms. It discusses various types of information systems, such as Transaction Processing Systems and Management Information Systems, and outlines the System Development Life Cycle (SDLC) phases. Additionally, it highlights the roles of systems analysts and the use of CASE tools in the development process.

Uploaded by

chaturbhuj bhatt
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views79 pages

Unit 1.1.the Systems Development Environment

The document provides an overview of System Analysis and Design, detailing the components and characteristics of systems, including inputs, outputs, processes, and feedback mechanisms. It discusses various types of information systems, such as Transaction Processing Systems and Management Information Systems, and outlines the System Development Life Cycle (SDLC) phases. Additionally, it highlights the roles of systems analysts and the use of CASE tools in the development process.

Uploaded by

chaturbhuj bhatt
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 79

System Analysis and Design

Unit 1: Introduction to System Development

Instructor
Chaturbhuj Bhatt
[email protected]
Introduction: System
2

 A system is a set of components that interact to accomplish


some purpose.
 For examples, College system, Economic system, Language
system, a Business and its parts - Marketing, Sales, Research,
Shipping, Accounting, Government and so on.

Subsystem Subsystem

Inputs Outputs
Subsystem

Feedback
System boundary
System environment
Introduction: Element of the System
3

 Output and Inputs:


 A major objective of a system is to produce an output that has
value to its user.
 Whatever the nature of the output, it must be in line with the
expectations of the intended users.
 Inputs are the elements that the system for processing and
output is the outcome of the processing.
 Processors:
 It is the element of the system that involves the actual
transformation of input into output.
 It is the operational components of the system.
Introduction: Element of the System
4

 Control :
 The control elements guide the system.
 It is the decision-making subsystem that controls the pattern
of activities governing input ,processing and output.
 Feedback:
 Control in a dynamic system is achieved by feedback.
 It measures output against a standard in some form that
includes communication and control.
 It may be positive or negative routine or information.
Introduction: Element of the System
5

 Environment:
 It is the sources of the external elements that influence on the
system.
 It determines how a system must function.
 Boundaries and interface:
 A system should be defined by its boundaries- the limits that
identify its components, process and interrelationship when it
interfaces with another system.
Introduction: System Characteristics
6

 Organisation:
 It implies structure and order. It is the arrangement of components
that helps to achieve objectives.
 Interaction:
 It refers to the manner in which each component functions with
other component of the system.
 In an organisation, for example, purchasing must interact with
production, advertising with sales, etc.
 Interdependence:
 It means that parts of the organisation or computer system depend
on one another.
 They are coordinated and linked together according to a plan.
 One subsystem depends on the input of another subsystem for
proper functioning.
Introduction: System Characteristics
7

 Integration:
 it refers to completeness of systems.
 It is concerned with how a system is tied together.
 It is more than sharing a physical part or location.
 It means that part of a system work together within the system
even though each part performs a unique function.
 Central Objective:
 Objective may be real or stated.
Introduction: Information System
8

 It is interrelated components working together to collect,


process, store, and disseminate information to support
decision making, coordination control analysis and
visualization in an organization.
 Many information systems now use computer systems for
manipulating information and are sometimes called
computer-based information systems.
 Information systems in organizations capture and manage
data to produce useful information that supports an
organization and its employees, customers, suppliers and
partners.
 So, many organizations consider information system to be
the essential one.
Introduction: Information System
9
Introduction: Information System
10

 Activities to produce information in an IS


 Input: Captures raw data from organization or
external environment
 Processing: Converts data into meaningful form
 Output: Transfers processed information to people
or activities that use it
 Feedback: Output returned to appropriate
members of organization to help evaluate or
correct input stage
Introduction: Typical Component of IS
11

 Hardware: Computer-based information systems use


computer hardware, such as processors, monitors, keyboard
and printers.
 Software: These are the programs used to organize, process,
and analyze data.
 Databases: Information systems work with data, organized
into tables and files.
 Network: Different elements need to be connected to each
other, especially if many different people in an organization
use the same information system.
 Procedures: These describe how specific data are processed
and analyzed in order to get the answers for which the
information system is designed.
Introduction: Types of IS
13
Transaction Processing System (TPS)

14

The term "transaction processing system" refers to an information


system that processes data arising from business transactions.
 The goal of a Transaction Processing System is to offer

transactions so that data may be updated and reports can be


generated, i.e., to do storekeeping.

 Batch processing and online transaction processing are the two


methods used to complete the transaction.

 Examples include a billing system, a payroll system, and a


stock control system, etc.
Management Information System (MIS)

15

 The purpose of a Management Information System is to turn relatively


raw data available through a Transaction Processing System into a
summarized and aggregated form for the manager, generally in the
form of a report.
 Middle management and operational supervisors are likely to use the
reports.

 In MIS, several distinct types of reports are generated. A summary


report, on-demand report, ad-hoc reports, and an exception report are
among the reports available.

 Examples include Sales Management Systems and Human Resource


Management Systems.
Decision Support System (DSS)
16

 In a semi-structured or unstructured environment, a Choice


Support System is an interactive information system that gives
information, models, and data manipulation tools to assist in
making a decision.

 The end-user is more active in producing DSS than a MIS since


it includes tools and strategies to assist in obtaining relevant
information and analyzing possibilities and alternatives.

 Examples include Financial Planning Systems and Bank Loan


Management Systems.
Experts Systems
17

 Experts Systems include knowledge to assist management in


identifying and fixing problems. These systems are based on
artificial intelligence research concepts.

 Experts Systems is an information system that is built on


knowledge. It acts as an expert counsellor to consumers by
utilizing its expertise in a particular area.

 An expert system's components include a knowledgebase and


software modules. These modules make inferences based on
knowledge and respond to a user's query.
 Example include: CaDet(cancer decision support tool),
DENDRAL(Chemical analysis)
Introduction: Overview of SAD
18

 Systems Analysis and Design is the complex,


challenging, and simulating organizational process that a
team of business and systems professionals uses to
develop and maintain computer-based information
systems.
 System Analysis –
 Process of gathering and interpreting facts, diagnosing
problems, and using the facts to improve the system.
 Systems Design –
 Process of planning a new system to replace or complement the
old.
 Analysis specifies what the system should do and design states
how to achieve the objective.
Introduction: Overview of SAD
19

 In systems analysis and design, we use various


methodologies, techniques and tools.

Methodologies

Techniques Tools

An organizational approach to systems analysis and design is


driven by methodologies, techniques, and tools.
Introduction: Roles of Systems Analyst
20

 The analyst plays many roles, sometimes balancing


several at the same time.
 The three primary roles of the systems analyst are
 Systems Analyst as Consultant
 Systems Analyst as Supporting Expert
 Systems Analyst as Agent of Change
A Modern Approach to SAD
21

 1950s: focus on efficient automation of existing


processes
 1960s: advent of 3GL, faster and more reliable
computers
 1970s: system development becomes more like an
engineering discipline
 1980s: major breakthrough with 4GL, CASE tools,
object oriented methods
 1990s: focus on system integration, GUI
applications, client/server platforms, Internet
 The new century: Web application development,
wireless PDAs, component-based applications
Developing IS and the SDLC
22

 System Development Methodology: SDLC-System


Development Life Cycle.
 SDLC is a traditional methodology for developing,
maintaining, and replacing information systems
 SDLC is the collection of processes which are
followed to develop a software.
 It is a methodology that defines some processes
which are followed to develop a high-quality
software.
 It covers the detailed plan for building, deploying
and maintaining the software.
Developing IS and the SDLC
23

 The main aim of SDLC is to define all the tasks


required for developing and maintaining software.
 It is followed for a software project within a
software developing organization.
Standard process/phases followed in an organization
consists of:
 Planning
 Analysis
 Design
 Implementation
 Maintenance
Developing IS and the SDLC
24

 SDLC includes phases such as planning, analysis, design,


implementation, and maintenance.

Planning

Maintenance Analysis

Implementation Design

The systems development life cycle


Developing IS and the SDLC: Phases
25

 Planning
 Identify, analyze, prioritize and arrange IS needs
 Analysis
 Study and structure system requirements
 Design
 Convert recommended solution to system specifications
 Logical design: functional features described
independently of computer platform
 Physical design: logical specifications transformed to
technology-specific details
Developing IS and the SDLC: Phases
26

 Implementation
 Code, test, install, and support the information system
 Maintenance
 Systematically repair and improve the information system
Developing IS and the SDLC: Product of SDLC
Phases
27
Phase Products, Outputs, or Deliverables
Planning Priorities for systems and projects; an architecture for data, networks, and selection
hardware, and information systems management are the result of associated systems
Detailed steps, or work plan, for project
Specification of system scope and planning and high-level system requirements or features
Assignment of team members and other resources
System justification or business case
Analysis Description of current system and where problems or opportunities exist, with a general
recommendation on how to fix, enhance, or replace current system
Explanation of alternative systems and justification for chosen alternative
Design Functional, detailed specifications of all system elements (data, processes, inputs, and
outputs)
Technical, detailed specifications of all system elements (programs, files, network, system
software, etc.)
Acquisition plan for new technology
Implementation Code, documentation, training procedures, and support capabilities
Maintenance New versions or releases of software with associated updates to documentation, training, and
support
The Heart of the Systems Development Process
28

Analysis Planning

Mainteinance Analysis
Design
Test

Implementation Design
Code

The analysis-design-code-test loop The heart of system development


Traditional Waterfall SDLC
29

 Waterfall model (sometimes called classic life cycle


or the linear sequential model) is the oldest and the
most widely used paradigm for information systems
development.
 This structured approach looks at the system from a
top-down view.
 It is a formalized step by step approach to the SDLC
which consists of phases or activities.
 The activities of one phase must be completed before
moving to the next phase.
Traditional Waterfall SDLC
30

Planning

Analysis

Logical Design

Physical Design

Implementation

Maintenance

Traditional Waterfall SDLC


Traditional Waterfall SDLC: Application
31

 Some situations where the use of Waterfall model is


most appropriate are:
 Requirements are very well documented, clear and fixed
 Product definition is stable
 Technology is understood and is not dynamic
 There are no ambiguous requirements
 Ample resources with required expertise are available to
support the product
 The project is short and cost is low.
Traditional Waterfall SDLC: Advantages
32

 Simple and easy to understand and use.


 Easy to manage due to the rigidity of the model – each
phase has specific deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are
very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.
Traditional Waterfall SDLC: Disadvantages
33

 No working software is produced until late during the


life cycle.
 High amounts of risk and uncertainty.
 Not a good model of complex and object-oriented
projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are
at a moderate to high risk of changing. So risk and
uncertainty is high with this process model.
Traditional Waterfall SDLC: Disadvantages
34

 It is difficult to measure progress within stages.


 Cannot accommodate changing requirements.
Case Tools
35

 Computer-aided systems engineering (CASE), also called


computer-aided software engineering, is a technique that
uses powerful software, called CASE tool, to help systems
analysts develop and maintain information systems.
 CASE tools provide an overall framework for systems
development and support a wide variety of design
methodologies, including structured analysis and object-
oriented analysis.
 After developing a model, many CASE tools can generate
program code, which speeds the implementation process.
 Example products: Oracle Designer, Rational Rose,star
UML, Microsoft visio
Case Tools: Sample for Visual Case Tool Software.
36
Case Tools: Types
37

 Diagram Tools:
 It helps in diagrammatic and graphical representations of
the data and system processes.
 It represents system elements, control flow and data flow
among different software components and system structure
in a pictorial form.
 For example, Flow Chart Maker tool for making state-of-
the-art flowcharts.
 Computer Display and Report Generators:
 It helps in understanding the data requirements and the
relationships involved.
Case Tools: Types
38

 Analysis Tools:
 It focuses on inconsistent, incorrect specifications involved
in the diagram and data flow.
 It helps in collecting requirements; automatically check for
any irregularity, imprecision in the diagrams, data
redundancies or erroneous omissions.
 Central Repository:
 It provides the single point of storage for data diagrams,
reports and documents related to project management.
Case Tools: Types
39

 Documentation Generators:
 It helps in generating user and technical documentation as
per standards.
 It creates documents for technical users and end users.
 For example, Doxygen, DrExplain, Adobe RoboHelp for
documentation.
 Code Generators:
 It aids in the auto generation of code, including definitions,
with the help of the designs, documents and diagrams.
Case Tools: Advantages
40

 As special emphasis is placed on redesign as well as


testing, the servicing cost of a product over its expected
lifetime is considerably reduced.
 The overall quality of the product is improved as an
organized approach is undertaken during the process of
development.
 Chances to meet real-world requirements are more
likely and easier with a computer-aided software
engineering approach.
 CASE indirectly provides an organization with a
competitive advantage by helping ensure the
development of high-quality products.
Case Tools: Disadvantages
41

 Purchasing of CASE tools is Not an Easy Task. The


cost of CASE tools is very high. For this reason
small software development firms do not invest in
CASE tools.
 In general, programmer productivity may fall in the
initial phase of implementation as users need time to
learn this technology.
 It is important to make proper selection of CASE
tools to get maximum benefits from the tools, as the
wrong selection may lead to the wrong results.
Case Tools
42

 Today’s CASE tools provide two distinct ways to develop


system models
 Forward Engineering and Reverse Engineering.
 Forward engineering requires the system analyst to draw
system models, either from scratch or from templates.
 The resulting models are subsequently transformed into program code.
 Reverse engineering, allows a CASE tool to read existing
program code and transform that code into a representative
system model that can be edited and refined by the systems
analyst.
 CASE tools that allow for bi-directional, forward and reverse
engineering are said to provide for “round-trip engineering”.
Other Approaches:
43

 Introduction
 Prototyping
 Spiral
 Rapid Application Development (RAD)
 Introduction to Agile Development
Introduction
44

 The traditional waterfall approach focuses on


categorize project into several phases.
 Alternatives to Traditional Waterfall SDLC are:
 Prototyping
 Spiral
 Rapid Application Development (RAD)
 Agile Methodologies
Prototyping: Introduction
45

 Iterative development process:


 Requirements quickly converted to a working
system
 System is continually revised
 Close collaboration between users and analysts
(trial-and-error method)
Prototyping: Types
46

 Rapid Throwaway Prototyping:


 Developers can explore the ideas as well as get proper
customer feedback.
 Prototype need not be a final one, and so it can be further
iterated to develop new versions of the final product.
 Evolutionary Prototyping:
 Developed prototype will primarily be incremented for
refining on the foundation of customer opinion until the
final one gets accepted.
 It provides an improved way which can save time and
effort.
Prototyping: Model
47

Start Stop

Requirement Engineer
Gathering Product

Refining
Quick Design
Prototype

Building
Prototype User Evaluation

Prototyping Model
Prototyping: Phases
48

 Requirements Gathering:
 Requirements of the system are defined in detail.
 The user is interviewed in order to know the requirements of
the system.
 Quick Design:
 When requirements are known, a preliminary design or quick
design for the system is created.
 It is not a detailed design and includes only the important
aspects of the system, which gives an idea of the system to the
user.
 A quick design helps in developing the prototype.
Prototyping: Phases
49

 Build Prototype:
 Information gathered from quick design is modified to form
the first prototype, which represents the working model of the
required system.
 User Evaluation:
 Proposed system is presented to the user for thorough
evaluation of the prototype to recognize its strengths and
weaknesses.
 Comments and suggestions are collected from the users and
provided to the developer.
Prototyping: Phases
50

 Refining Prototype:
 User evaluates the prototype and if he is not satisfied, the
current prototype is refined according to the requirements.
 A new prototype is developed with the additional information
provided by the user.
 The new prototype is evaluated just like the previous prototype.
 This process continues until all the requirements specified by
the user are met.
 Once the user is satisfied with the developed prototype, a final
system is developed on the basis of the final prototype.
Prototyping: Phases
51

 Engineer Product:
 The user accepts the final prototype.
 The final system is evaluated thoroughly followed by the
routine maintenance on regular basis for preventing large-scale
failures and minimizing downtime.
Prototyping: Advantages
52

 The customers get to see the partial product early in the life
cycle. This ensures a greater level of customer satisfaction and
comfort.
 New requirements can be easily accommodated as there is
scope for refinement.
 Missing functionalities can be easily figured out.
 Errors can be detected much earlier thereby saving a lot of
effort and cost, besides enhancing the quality of the software.
 The developed prototype can be reused by the developer for
more complicated projects in the future.
 Flexibility in design.
Prototyping: Disadvantages
53

 It is a time consuming if customer asks for changes in


prototype.
 This methodology may increase the system complexity as
scope of the system may expand beyond original plans.
 The invested effort in the preparation of prototypes may be
too much if not properly monitored.
 Customer may get confused in the prototypes and real
systems.
Spiral
54

 A risk-driven process model generator that is used to


guide multi-stakeholder concurrent engineering of
software intensive systems.
 The Radius of the spiral at any point represents the
expenses (cost) of the project so far, and the angular
dimension represents the progress made so far in the
current phase.
Spiral: Phases
55

1. Objectives 2. Identify and


determination and resolve risks
identify alternative
solutions

4. Review and 3. Develop next


plan for next version of the
phase product

Different Phases of Spiral Model


Spiral: Phases
56

 Objectives determination and identify alternative


solutions:
 Requirements are gathered from the customers and the objectives
are identified, elaborated and analyzed at the start of every phase.
 Then alternative solutions possible for the phase are proposed in
this quadrant.
 Identify and resolve Risks:
 During the second quadrant all the possible solutions are
evaluated to select the best possible solution.
 Then the risks associated with that solution is identified and the
risks are resolved using the best possible strategy.
 At the end of this quadrant, Prototype is built for the best
possible solution.
Spiral: Phases
57

 Develop next version of the Product:


 During the third quadrant, the identified features are
developed and verified through testing. At the end of the
third quadrant, the next version of the software is available.
 Review and plan for the next Phase:
 In the fourth quadrant, the Customers evaluate the so far
developed version of the software.
 In the end, planning for the next phase is started.
Spiral: Advantages
58

 High amount of risk analysis hence, avoidance of


Risk is enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Spiral: Disadvantages
59

 Can be a costly model to use.


 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk
analysis phase.
 Doesn’t work well for smaller projects.
Rapid Application Development (RAD)
60

 RAD is an object-oriented approach to systems development


that includes a method of development as well as software
tools.

The RAD design workshop is the heart of the interactive development process
RAD: Phases
61

 There are three broad phases to RAD that engage


both users and analysts in assessment, design, and
implementation and they are:
 Requirements Planning
 RAD Design Workshop
 Implementation
RAD: Requirements Planning Phases
62

 In this phase, users and analysts meet


 to identify objectives of the application or system and
 to identify information requirements arising from those objectives.
 This phase requires intense involvement from both groups;
 It is not just signing off on a proposal or document.
 It may involve users from different levels of the organization.
 The orientation in this phase is toward solving business
problems.
 The focus will always remain on reaching business goals.
RAD: RAD Design Workshop Phases
63

 This phase is a design-and-refine phase that can best be


characterized as a workshop.
 Usually participants are seated at round tables or in a U-
shaped configuration of chairs with attached desks
 where each person can see the other and
 where there is space to work on a notebook computer.
 During this phase, users respond to actual working prototypes
and analysts refine designed modules based on user responses.
 The workshop format is very exciting and stimulating
 If experienced users and analysts are present, there is no
question that this creative endeavor can propel development
forward at an accelerated rate.
RAD: Implementation Phases
64

 Analysts work with users intensely during the workshop to


design the business or nontechnical aspects of the system.
 As soon as these aspects are agreed on and the systems are built
and refined, the new systems or part of systems are tested and
then introduced to the organization.
 RAD can be used to create new ecommerce applications
 RAD design workshop will have generated excitement, user
ownership, and acceptance of the new application.
 Typically, change brought about in this manner is far less
wrenching than when a system is delivered with little or no user
participation.
RAD: Advantages
65

 Changing requirements can be accommodated.


 Progress can be measured.
 Iteration time can be sort with use of powerful RAD
tools.
 Productivity with fewer people in short time.
 Reduce development time.
 Increases reusability of components.
RAD: Disadvantages
66

 Dependency on technically strong team members for


identifying business requirements.
 Only system that can be modularized can be built
using RAD.
 Requires highly skilled developers/designers.
 High dependency on modeling skills.
 Inapplicable to cheaper projects as cost.
Introduction to Agile Development
67

 The Agile software development model was mainly


intended for helping developers build a project which
can adapt to transforming requests quickly.
 The most important endeavor for developing the Agile
model is to make easy and rapid project achievement.
 For attaining this task, developers need to preserve the
agility during development.
 Agility can be achieved by correcting the progression
to the project by eliminating activities which may not
be crucial for that specific project.
Development Process of Agile Project
68
 Two words that
characterize a project
done with an agile
approach are interactive
and incremental.
 Five distinct stages:
 Exploration,
 Planning,
 Iterations to the first release
 Productionizing
 Maintenance
The five stages of the agile modeling development process
show that frequent iterations are essential to successful
system development
Development Process of Agile Project:
Phases
69

 Exploration
 During exploration, analyst will explore your environment,
asserting conviction that the problem can and should be
approached with agile development, assemble the team,
and assess team member skills.
 This stage will take anywhere from a few weeks to a few
months.
 Analyst will be actively examining potential technologies
needed to build the new system.
 During this stage analyst should practice estimating the
time needed for a variety of tasks.
Development Process of Agile Project:
Phases
70

 Customers are experimenting with writing user stories.


 The point is to get the customer to refine a story enough so
that analyst can efficiently estimate the amount of time it
will take to build the solution into the system as planning.
 This stage is all about adopting a playful and curious
attitude toward the work environment, its problems,
technologies, and people.
Development Process of Agile Project:
Phases
71

 Planning
 In contrast to the first stage, planning may only take a few
days to accomplish.
 In this stage analyst and the customers agree on a date
anywhere from two months to half a year from the current
date to deliver solutions to their most pressing business
problems.
 If analyst’s exploration activities were sufficient, this stage
should be very short.
Development Process of Agile Project:
Phases
72

 The planning game spells out rules that can help formulate
the agile development team’s relationship with their
business customers.
 They are a basis for building and maintaining a
relationship.
 The goal of the game is to maximize the value of the
system produced by the agile team.
 The strategy pursued by the agile development team is
always one of limiting uncertainty (downplaying risk).
 To do that they design the simplest solution possible, put
the system into production as soon as possible, get
feedback from the business customer about what’s working,
and adapt their design from there.
Development Process of Agile Project:
Phases
73

 Iterations to the First Release


 This stage is composed of iterations to the first release.
 Typically these are iterations (cycles of testing, feedback,
and change) of about three weeks in duration.
 Analyst will be pushing to sketch out the entire architecture
of the system, even though it is just in outline or skeletal
form.
 One goal is to run customer-written functional tests at the
end of each iteration.
Development Process of Agile Project:
Phases
74

 During the iterations stage analyst should also question


whether the schedule needs to be altered or whether analyst
is tackling too many stories.
 Make small rituals out of each successful iteration,
involving customers as well as developers.
 Always celebrate the progress, even if it is small, because
this is part of the culture of motivating everyone to work
extremely hard on the project.
Development Process of Agile Project:
Phases
75

 Productionizing
 The feedback cycle speeds up so that rather than receiving
feedback for an iteration every three weeks, software
revisions are being turned around in one week.
 Analyst may institute daily briefings so, everyone knows
what everyone else is doing.
 The product is released in this phase, but may be improved
by adding other features.
Development Process of Agile Project:
Phases
76

 Getting a system into production is an exciting event.


 Make time to celebrate with your teammates and mark the
occasion.
 One of the watchwords of the agile approach, with which
we heartily agree, is that it is supposed to be fun to develop
systems
Development Process of Agile Project:
Phases
77

 Maintenance
 Once the system has been released, it needs to be kept
running smoothly.
 New features may be added, riskier customer suggestions
may be considered, and team members may be rotated on
or off the team.
 The attitude you take at this point in the developmental
process is more conservative than at any other time.
Introduction to Agile Development:
Advantages
78

 Working through Pair programming produce well written


compact programs which has fewer errors as compared to
programmers working alone.
 It reduces total development time of the whole project.
 Customer representative get the idea of updated software
products after each iteration. So, it is easy for him to change
any requirement if needed.
Introduction to Agile Development:
Disadvantages
79

 Due to lack of formal documents, it creates confusion and


important decisions taken during different phases can be
misinterpreted at any time by different team members.
 Due to absence of proper documentation, when the project
completes and the developers are assigned to another project,
maintenance of the developed project can become a problem.
80

Thank You

You might also like