Page 2:

• 1.1. Defining A System

• System: an orderly grouping/arrangement of interdependent components/parts/elements
which interact & integrate together to achieve a specific goal/objective.
• Example 1: a computer system: consists of input, processor, output & storage devices;
objective - Produce information.
• Example 2: An organization/company - a system made up of methods, procedures +
policies, people, infrastructure; Objective to provide service/generate profit.
• Subsystem: a system that is part of a larger system (e.g., Registrar of AASTU)
• 1.2. Characteristics of A System
• Key characteristics common to all systems: organization/order, interaction,
interdependence, integration & a central objective.
• 1.2.1. Organization/order:
* Implies structure, order/arrangement of components to help achieve objectives.

Page 3:

• 1.2. Characteristics of A System ...

• Example: 1. A University: hierarchical relationships
• President office => vice presidents offices => directors/deans offices => departments =>
staff, students
• This arrangement portrays:
* a system - subsystem relationship,
* defines authority structure,
* specifies formal flow of communication & chain of command.
• 1.2.2. Interaction: manner in which each component functions.
* E.g., 1. Departments must send course offerings to the Registrar.
* 2. A Comp. Syst: CPU must interact with keyboard to capture input.
• 1.2.3. Interdependence: no subsystem can function in isolation;
* dependent on inputs from other subsystems to perform its tasks.
* E.g.: CPU depends on input from the Keyboard

Page 4:

• 1.2. Characteristics of A System ...

• 1.2.4. Integration:
* Refers to holism of systems.
* Concerned with how a system is tied together.
* More than sharing a physical part or location.
* Successful integration produces a synergistic effect & greater total impact than if each
component works separately.
* "The WHOLE is greater than the SUM of the parts", Aristotle.
• 1.2.5. Central objective:
* The purpose for which the system is in place.
* Example: 1. University's main Objectives: produce trained manpower
* 2. Computer - produce information.

Page 5:

• 1.3. Elements/Components/Parts of A System

• I/Os; Processor(s); Control;
• Feedback; Environment; Boundaries & interfaces
• 1.3.1. Inputs and Outputs
* Outputs: can be goods, services, or info;
 * System feeds on input to produce output.
* Output specs determine what & how much input is needed.
* Inputs can be material, human resource, & data.
* Determining output: is a 1st step in specifying the nature, amount, & regularity of
input needed to operate a system.
* Example.: In systems analysis:
* 1st determine users' requirements of a proposed system.

Page 6:

• 1.3. Elements/Components/Parts of A System ...

• 1.3.2. Processor(s):
* Does actual transformation of input into output.
* Modify input totally/partially, depending on output specification
* As output specs change so does processing.
• 1.3.3. Control: Guides system-making decisions to control pattern of activities governing
input, processing, and output.
* Example:
* Management controls inflow, handling & outflow of business activities.
* Computer's control unit:
* controls and manages the execution of instructions;
* Determines sequence of operations, directs flow of data, and ensures proper
coordination among different components.

Page 7:

• 1.3. Elements of A System ...

• 1.3.4. Feedback:
* measures output against a standard in some form of cybernetic procedure that
includes communication & control.
* After output is compared against performance standards,
* Changes may result in input or processing & hence, the output.
* +Ve feedback:
* reinforces system performance; it is routine in nature.
* -Ve feedback:
* generally provides the controller with info for action.
* Example: System Post implementation feedback:
* The user informs analyst about the performance of the new installation - leading to
possible enhancements.

Page 8:

• 1.3. Elements of A System ...

• 1.3.5. Environment: a "supra-system" within which an organization operates.
* External factors impacting system.
* E.g., Suppliers/vendors, competitors, consumers/customers, gov't etc, may provide
constraints &, hence, influence actual business performance.
• 1.3.6. Boundaries & interface:
* Limits that identify its components, processes & interrelationship when it interfaces
with another system.
* Boundaries determine a system's sphere of influence & control.
* Examples:
* 1. Public Relations Office: interacts with entities outside of an organization
* 2. Min. of Foreign Affairs: a nation's legal interface with global community
 * 3. A teller system in a com. Bank: is restricted to deposits, withdrawals & related
activities of customers' checking & savings accounts;
* may exclude mortgage foreclosures, other activities.

Page 9:

• 1.4. Types of systems: can have several classifications of systems

• Physical vs Abstract;
• Open vs Closed;
• Natural vs Man - Made" systems,...
• 1.4.1 Physical or abstract systems
* Physical systems: tangible entities with static/dynamic operation.
* Examples: Computer system
* HW - tangible parts like keyboard, Monitor, CPU,...; they are static.
* Data, programs & output: change as user's demand/priority requested changes;
these are dynamic.
* Abstract systems: conceptual /non-physical entities that may be formulas,
representation/model.
* Describe a system that may not exist/concepts in the mind that can be described as
a system.
* E.g., Entertainment system: art, music, poetry, stories, sports, etc.

Page 10:

• 1.4. Types of systems...

• 1.4.2. Open or Closed Systems: based on degree of independence.
* Open system:
* interacts with the environment;
* receives input/delivers outputs to environment.
* E.g.: Organizations & Computers
* Open Sys. Concerns: computer fraud, privacy, security, & ethics in computing
* Closed system: isolated from environmental influence; closed system is rare.
* Characteristics of open systems:
* 1. Input from outside: used for self - adjusting & -regulating
* Proper functioning leads to a steady state/equilibrium.
* Example: In Retail firm:
* Steady state: goods are purchased & sold without under/over stock
× Rise in cost of goods => increase in prices/decrease in operating costs.
* This response/INPUT/ gives the firm its steady state.

Page 11:

• 1.4.2. Open or Closed Systems... characteristics of open systems ...

• 2. Entropy: dynamic systems tend to run down over time, resulting in entropy/loss of
energy.
* Open Ss resist entropy by seeking new inputs/modifying processes to return to a
steady state.
* E.g., no reaction to increase in cost of merchandise makes business unprofitable -
forcing it into bankruptcy – a state of disorganization/entropy.
• 3. Process, output & cycles: Open systems produce useful output and operate in cycles,
following a continuous flow path.
• 4. Differentiation: Open Ss tend to increase function specialization & greater
differentiation of their components;
* E.g., Business: roles of people & machines tend to greater specialization. This may
call for custom-application dev't than acquiring a generic Software.
Page 12:

• 5. Equifinality: goals are achieved through differing courses of action & a variety of paths;
mostly, there is consensus on goals than on paths.
• A Property that allows different means of achieving same thing.
• During system development look at alternative solutions.
• Considering alternatives may call for changing certain user criteria.
• 1.4.3. Natural Vs. Man - Made Systems
• Natural Systems: follow natural Laws & Processes: E.g., Our body
• Man-Made Systems (MMS): created & controlled by humans for specific purpose.
Example: Information Systems (IS).
• Info, by product of an IS, reduces uncertainty about a state/situation.
• E.g.: Info that wind is calm implies that the boat trip will be pleasant [for a
meteorological system]
• An Information System: set of devices, procedures, [software], people,... designed to
produce info & communicate it to users for planning, control & performance. May be manual
or automated.

Page 13:

• 1.5. Software & Software Engineering

• Software: a set of programs to operate computers & related devices.
• The Nature of Software:
* Intangible: Hard to understand development effort
* Easy to reproduce: Major cost is in its development, as manufacturing is the costly
stage in other engineering products.
* Industry is labor-intensive - 'Hard' to automate; yet there's promising progress
* Easy to modify - People can make changes w/o fully understanding it
* Quality problems are hard to notice
* Does not 'wear out' but 'deteriorates' by having its design changed:
* erroneously, or in ways that were not anticipated, thus making it complex
* Conclusions:
* Much software has poor design & is getting worse; we are in a perpetual 'software
crisis'.
* Demand for software is high and rising
* We have to learn to 'engineer' software

Page 14:

• 1.5. Software & Software Engineering...

• Types of Software:
* Custom - meant for a specific customer
* Generic - Sold on open market (e.g., MS Office suite)
* Often called COTS (Commercial Off The Shelf)/Shrink-wrapped
* Embedded - Built into hardware; Hard to change/to reprogram
* DIFFERENCES AMONG THESE SOFTWARE TYPES

| | Custom | Generic | Embedded |

| :---------------------------- | :----- | :------ | :------- |
| Number of copies in use | low | medium | high |
| Total processing power | low | high | medium |
| devoted to running this type of software | | | |
| Worldwide annual development effort | high | medium | low |
Page 15:

• Real time software: control & monitor real world systems

• Must react immediately
• Safety is often a concern
• Data processing software: Used to run businesses
• Accuracy and security of data are key
• Software Engineering:
• The process of solving customers' problems through the systematic development and
evolution of large, high-quality software systems within cost, time and other constraints
• The goal of SW engineering is Solving customers' problems
* Sometimes the solution is to buy, not build
* Adding unnecessary features does not help solve the problem
* Software engineers must communicate effectively to identify & understand the
problem

Page 16:

• Systematic development and evolution

• An engineering process involves applying well understood, organized & disciplined
techniques.
• Formally accepted standards exist: e.g. by the IEEE or ISO
• Most development work is evolutionary
• Large, high quality software systems
• Software engineering techniques are needed because large systems cannot be completely
understood by one person
• Teamwork and co-ordination are required
• Key challenge: Dividing up the work and ensuring that the parts of the system work
properly together
• The end-product that is produced must be of sufficient quality
• Cost, time and other constraints
• Finite resources & hence benefit must outweigh the cost
• Others are competing to do the job cheaper and faster
• Inaccurate estimates of cost and time have caused many project failures

Page 17:

• Software Engineering and the Engineering Profession

• The term Software Engineering was coined in 1968
• People realize that the principles of engineering are key to SW dev't
• Engineering is a licensed profession
* In order to protect the public
• Engineers design artifacts following well accepted practices which involve the
application of science, mathematics and economics
• Ethical practice is also a key principle of the profession
• Software Quality
• Usability - ease of learning and ease of use by users.
• Efficiency - doesn't waste resources such as CPU time and memory
• Reliability - does what it is required to do without failing
• Maintainability - It can be easily changed
• Reusability - parts can be used in other projects; no need for reprogramming

Page 19:

• 1.6. System Development Approaches/Methodologies

 • A methodology: is a formalized approach to implementing the SDLC (i.e., it is a list of
steps and deliverables).
• Different systems development methodologies exist;
• Each methodology is unique based on the order & focus it places on each SDLC phase.
• Some methodologies are formal standards used by Govt agencies,
• Others have been developed by consulting firms to sell to clients.
• Many organizations have internal methodologies that have been used over the years, and
they may explain exactly how each phase of the SDLC is to be performed in that company.
• There are many ways to categorize methodologies.
* 1. Focus on business processes, data or both. Methodologies based on this:
Structured, Info Eng & O-O
* 2. Sequencing and Amount of time & effort devoted to the SDLC phases.
Methodologies: Waterfall, RAD, Agile & their varieties,

Page 20:

• 1.6. System Development Approaches/Methodologies

• A. Structured Analysis (SA): a model-driven, PROCESS-centered technique used to
analyze existing system/define requirements for new system or both.
* uses pictures to illustrate the system's component pieces:
* processes & their associated inputs, outputs and files.
* Key modeling tool: Data Flow Diagram (DFD).
* depicts existing & /or proposed processes + their inputs, outputs, & data.
* DFDs show data flow b/n processes & places where data is stored.
* Ultimately these process models serve as:
* blueprints for business processes to be implemented and software to be purchased
or constructed.

Page 21:

• 1.6. System Development Approaches/Methodologies

• B. Information Engineering (IE): emphasizes/focuses on structure of stored data in a
system rather than on processes.
* DATA-CENTERED: emphasizes analysis of KNOWLEDGE /data
* Key tool to model data requirements: Entity R/ship Diagram (ERD);
* Widely used in designing relational databases.
* Though originally, competing approaches, SA & IE are actually complementary:
DFDs model processes & ERDs model data.
• C. Object-Oriented
* Traditional, i.e., Structured & Info Eng., approaches artificially separate DATA from
PROCESSES.
* By contrast, object-oriented methodology attempts to balance the focus between
process & data by incorporating both into one model.
* Thus, OO views systems not asdata & processes but as a collection of objects that
encapsulate data & processes using CLASS DIAGRAMS.

Page 22:

• 1.6. System Development Approaches/Methodologies

• Based on such factors as:
* Sequencing of the SDLC phases and
* Amount of: time & effort devoted to each.
• Methodologies fall into:
* Waterfall & its varieties:
* Parallel development
 * V-models
* Rapid Application Development & Varieties
* Iterative/phased/Development
* System & Throwaway prototyping, &
* Rapid Architects Analysis (Reverse Engineering of legacy systems)
* Agile development & varieties
* Extreme Programming (XP)
* Scrum

Page 23:

• 1.6. System Development Approaches/Methodologies

• A. Waterfall Development:
* Project team proceeds sequentially from one phase to the next.
* (Dennis, Wixon & Roth, 2019, p.43)

Page 24:

• 1.6. System Development Approaches/Methodologies

• Waterfall Development...
* Each phases key deliverables are:
* typically voluminous (hundreds of pages) and
* presented to the approval committee & project sponsor for approval as the project
moves from phase to phase.
* Once work produced in a phase is approved, the phase ends & next phase begins.
* Progresses from phase to phase moves forward in same manner as a waterfall.
* Though possible to go backward through the phases (e.g., from design back to
analysis), it is quite difficult;
* this requires major change, leading to increase in cost & time delay
* Imagine trying to swim upstream in a waterfall.

Page 25:

• 1.6. System Development Approaches/Methodologies

• Advantages:
* requirements are identified before programming begins, and
* requirement changes are limited as project progresses.
• Disadvantages:
* must complete design before programming begins
* Long time elapses b/n:
* system proposal (analysis phase) &
* system delivery;
* Users may forget original purpose of the system
* testing may be treated as an afterthought in implementation phase.
* Large documentation leads to:
* overlooked requirements;
* a poor communication mechanism

Page 26:

• 1.6. System Development Approaches/Methodologies

• Waterfall Development... disadvantages...
* Expensive post-implementation programming:
* due to missed important requirement.
* Can't cope up with today's dynamic business environments:
 * deliverables of analysis may need considerable rework to match the changing env't
when it is implemented.
* This rework requires going back to the initial phase & making needed changes
through each of the subsequent phases in turn.
• Major Variants of waterfall:
* Parallel Development (PD) &
* V-Model

Page 27:

• 1.6. System Development Approaches/Methodologies

• A1. Parallel Dev't (PD): ...
* Parallel Dev't (Dennis, Wixon & Roth, 2019, p.49)

Page 28:

• 1.6. System Development Approaches/Methodologies

• A1. Parallel Dev't (PD): .... Evolved to address lengthy time of waterfall
* After analysis phase, a general design for whole system is created.
* Then project is divided into a series of subprojects that can be designed &
implemented in parallel.
* Once all subprojects are complete, there is a final integration of the separate pieces,
and the system is delivered.
* Advantage: Reduces time required to deliver a system, so changes in the business
env't are less likely to produce the need for rework.
* Disadvantage: still suffers from problems caused by voluminous deliverables,
* Adds a new problem (i.e., integration problem)
* if subprojects are not completely independent, design decisions in one subproject
may affect another, & at the end of project, integrating subprojects may be quite challenging.

Page 29:

• 1.6. System Development Approaches/Methodologies

• A2. V-model:
* pays more explicit attention to testing (see fig, next slide)
* Dev't process proceeds down the left-hand slope of the V,
* defining requirements & designing system components.
* At the base of the V, the code is written.
* On the upward-sloping right side of the model,
* testing of components,
* integration testing, and,
* finally, acceptance testing are performed.
* A key concept:
* Requirements are specified & components designed,
* testing for those elements is also defined; each level of testing is linked to a part of
analysis/design phase;

Page 30:

• 1.6. System Analysis & Modeling Approaches/Methodologies

• Benefits:
* Simple, straightforward &
* Ensures to maximize test effectiveness.
* improves overall system quality through earlier focus on test plan dev't & conducting
tests;
 * involves quality assurance expertise to increase overall quality of system design.
• Disadvantage:
* still suffers from rigidity of the waterfall dev't process;
* not always appropriate for the dynamic nature of the business environment.

Page 32:

• 1.6. System Development Approaches/Methodologies

• B. Rapid Application Development (RAD): A collection of methodologies
* Emerged in response to the weaknesses of waterfall dev't & its variations.
* Incorporates special techniques & computer tools to speed up:
* the analysis, design, & implementation phases
* so that portion of system developed quickly handed over to users for evaluation &
feedback.
* Incorporates:
* CASE (Computer Assisted Software Eng) tools,
* Joint Application Development (JAD) sessions,
* 4th generation/visual programming languages (e.g., Visual [Link]),
* Code generators may all play a role in RAD.

Page 33:

• 1.6. System Development Approaches/Methodologies

• Advantage:
* can improve the speed & quality of systems development,.
• Disadvantage:
* As systems are developed more quickly & users gain a better understanding of IT,
* user expectations may dramatically increase &
* May Expand system requirements
* Causing scope creep or feature creep.
• RAD may be conducted in a variety of ways:
* Iterative/phased,
* System & Throw away prototyping
* Rapid Architect Analysis (reverse engineering)

Page 34:

• 1.6. System Development Approaches/Methodologies

• B1. Iterative/Phased/development (ID):
* Breaks overall project into a series of versions, developed sequentially.
* Most important requirements are bundled into 1st version of system.
* 1st version is developed & implemented quickly by a mini-waterfall process,
* Users use 1st version & provide valuable feedback to be incorporated into the next
version
* Advantage:
* Quick 1st version delivery to users, adds business value early
* Additional requirements identified & incorporated into subsequent versions, based
on actual system use of 1st version.
* Disadvantage:
* users begin to work early with an intentionally incomplete system;
* users must be patient with repeated release of new system versions.

Page 36:

• 1.6. System Development Approaches/Methodologies

 • B2. System prototyping (SP):
* Perform analysis, design, & implementation concurrently & repeatedly
* Quickly develop a simplified version of proposed system &
* Gives it to the users for evaluation & feedback.
* Prototype: "quick & dirty" version of system & provides minimal features.
* Following reaction & comments from users:
* developers reanalyze, redesign, & re-implement a 2nd prototype.
* This cycle continues until the analysts, users, & sponsors agree on the prototype's
functionality.
* Advantage:
* quickly provides a system for users to evaluate and reassures users that progress is
being made;
* very useful when users have difficulty in expressing requirements

Page 37:

• 1.6. System Development Approaches/Methodologies

• (Dennis, Wixon & Roth, 2019, p.46)
• Disadvantage:
* lack of careful analysis before design & implementation decisions.
* Sys. prototypes may have some fundamental design limitations due to:
* Inadequate understanding of true requirements early in the project.

Page 38:

• 1.6. System Development Approaches/Methodologies

• B3. Throwaway prototyping (TP):
* Uses prototypes primarily to explore design alternatives rather than as actual new
system
* not intended to be a working system:
* meant only enable users to understand issues under consideration.
* E.g.: Online order Entry System
* Suppose users are not completely clear on how an order entry system should work.
* The analyst team might build a series of HTML pages to be viewed on a Web
browser to help users visualize such a system;
* a series of mock-up screens appear to be a system, but really do nothing.

Page 39:

• 1.6. System Development Approaches/Methodologies

• B3. Throwaway prototyping (TP): ....
* May require several design prototypes during analysis & design;
* Each prototype is used to minimize risk associated with system by:
* Confirming that important issues are understood before the real system is built.
* Once issues are resolved, the project moves into design and implementation.
* At this point, the design prototypes are thrown away:
* which is an important difference b/n:
* this approach &
* system prototyping (the prototypes evolve into the final system).
* Advantage: refine key issues before a system is built.

Page 40:

• 1.6. System Development Approaches/Methodologies

 • Disadvantage: may take longer to deliver final system compared with system
prototyping (because the prototypes do not become the final system), but the approach usually
produces more stable and reliable systems.
• (Dennis, Wixon & Roth, 2019, p.47)

Page 41:

• 1.6. System Development Approaches/Methodologies

• B4. Rapid Architected Analysis:
* Attempts to derive system models from existing systems or discovery prototypes.
* Made possible by reverse-engineering technology including CASE tools.
* Reverse Engineering tools generate system models from existing software
applications (e.g., legacy systems) or system prototypes.
* Resulting models are then edited & improved by analysts & user to provide a blue
print for a new & improved system.

Page 42:

• 1.6. System Development Approaches/Methodologies

• C. Agile Development:
* Programming-centric methodologies - focus on streamlining the SDLC.
* All are based on the agile manifesto & a set of twelve principles.
* Have few rules & practices, all of which are fairly easy to follow.
* Virtually all agile methodologies are used in along with O-O technologies.
* Manifesto's emphasis -
* Focus on addressing:
* Working conditions of developers to deliver working SW to customers,
* Changing requirements
* Instead of detailed systems Development of:
* processes, tools, documentation,
* legal contracts, & detailed plans.

Page 43:

• 1.6. System Development Approaches/Methodologies

• Agile focuses on: ...
* Simple, iterative application dev't:
* Every iteration is a complete SW project - planning, analysis, design, coding,
testing, & documentation.
* Short Cycles (1-4 weeks), &
* Team focus on adapting to current business environment.
* Eliminating much of modeling & documentation:
* Prefer face-to-face communication
* Agile Manifesto ([Link]
* Agile Manifest values:
* Interactions & individuals over processes and tools
* Working software over comprehensive documentation
* Customer Collaboration over contract negotiation
* Responding to change over following a plan

Page 44:

• 1.6. System Development Approaches/Methodologies

• Agile Manifesto ....
* The 12 Principles of Agile
 * 1. Priority is Early & continuous delivery of valuable SW to satisfy customer
* 2. Welcome changing requirements, even late in development
* 3. Deliver working SW frequently, in couple of weeks/months
* 4. Customers & developers must work together daily throughout project.
* 5. Build projects around motivated individuals.
* Give them the env't & support needed and
* trust them to get the job done
* 6. Most efficient & effective method of conveying info to & within a development
team is face-to-face conversation.

Page 45:

• 1.6. System Development Approaches/Methodologies

• Agile Development...
* 7. Working software is the primary measure of progress
* 8. Agile processes promote sustainable dev't.
* The sponsors, developers, & users should be able to maintain a constant pace
indefinitely.
* 9. Continuous attention to technical excellence & good design enhances agility
* 10. Simplicity - art of maximizing amount of work not done - is essential
* 11. The best architecture, requirements, and designs emerge from self-organizing
teams
* 12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Page 46:

• 1.6. System Development Approaches/Methodologies

• Agile Development: ... Criticisms:
* 1. Today much of actual IS dev't is off-shored, outsourced, and/or subcontracted.
* Hence, Co-location of dev't team becomes very unrealistic assumption.
* 2. If not carefully managed, it can devolve into a prototyping approach - an env't
where programmers attempt to hack together solutions.
* 3. Lack of documentation: affects audit-ability of system.
* W/O sufficient documentation, neither system nor dev't process can be assured.
* 4. Usability in delivering large mission-critical systems is difficult.

Page 47:

• 1.6. System Development Approaches/Methodologies

• Agile Development: ... Strengths
* However, Agile approaches have the potential to:
* Address the application backlog &
* provide timely solutions to many business problems
* Hence, agile dev't should be considered in certain circumstances.
* Furthermore, attending to underlying purpose of agile manifesto & twelve agile
principles are very useful in:
* object-oriented development.
* Popular agile development methodologies:
* Extreme programming (XP) and
* Scrum.

Page 48:

• 1.6. System Development Approaches/Methodologies

 • C1. Xrammers;
* Teams are kept small.
* Developers must:
* 1. provide rapid feedback to end users continually.
* 2. follow KISS (Keep it Simple Stupid) principle.
* 3. Have the courage to make incremental changes to grow the system,
* they must not only accept change but also embrace change.
* 4. have a quality-first mentality. XP also supports team members in developing
their own skills.

Page 49:

• 1.6. System Development Approaches/Methodologies

* Three of key principles that XP uses to create successful systems:
* continuous testing,
* simple coding performed by pairs of developers, and
* close interactions with end users to build systems very quickly.
* Testing and efficient coding practices are the core of XP.
* Code is tested each day & is placed into an integrative testing environment.
* If bugs exist, code is backed out until it is completely free of errors.
* XP relies heavily on refactoring:
* which is a disciplined way to restructure code to keep it simple.

Page 50:

• 1.6. System Development Approaches/Methodologies

* The process of an XP project:
* 1st, Begins with user stories - that describe what the system needs to do.
* 2nd, Then, programmers code & test in small, simple modules
* Users are required to be onsite to clear up questions/issues as they arise.
* Uses Standards to minimize confusion; XP teams use a common set of names,
descriptions, & coding practices
* XP projects deliver results
* sooner than even RAD approaches, &
* They rarely get bogged down in gathering requirements.

Page 51:

• 1.6. System Development Approaches/Methodologies

* Strengths of XP:
* Improved Programmer-stakeholder communication
* Encourages continuous testing of the evolving system.
* Allows requirements to evolve as the stakeholders understand the potential the
technology has in providing a solution to their problem.
* Estimation is task driven & is performed by the programmer who will implement the
solution.
* Because all programming is done in pairs, a shared responsibility for each software
component develops among the programmers.
* Finally, the quality of the final product increases during each iteration.
* Works well in small projects with highly motivated, cohesive, stable, & experienced
teams.
* criticism on XP:
* Success becomes doubtful when project is not small or teams are not jelled.

Page 52:
• 1.6. System Development Approaches/Methodologies
* Bringing outside contractors into existing team poses serious problems. => outsiders
jelling with insiders might be too optimistic.
* Requires great discipline; otherwise, projects become unfocused & chaotic.
* Recommended only for small groups of developers (<=10);
* Not advised for mission-critical applications: