System Analysis & Design Chapter 2

Newer class of systems development methodologies that emerged in the 1990s
RAD-based methodologies attempt to address weaknesses of structured design methodologies
By adjusting the SDLC phases to quickly get some part of the system developed and into the users' hands
Allows users to better understand the system and suggest revisions
Recommends analysts use special techniques and tools to speed up analysis, design, and implementation
Examples of tools include CASE tools, Joint Application Design (JAD) sessions, fourth-generation programming languages (e.g., Perl, Python, Ruby, SQL), and code generators

Combination of the changed SDLC phases and tools/techniques improves speed and quality of systems development
Potential problem: managing user expectations
User's understanding of information technology might expand system requirements

Methodology that breaks an overall system into a series of sequentially developed versions
Analysis phase identifies the overall system concept and categorizes requirements into versions
Most important requirements bundled into the first version
Leads into design and implementation, but only for the requirements of version 1
Once version 1 is implemented, work begins on version 2, with new requirements and user experience
Process continues until system is complete or no longer in use

Methodology that performs analysis, design, and implementation concurrently and repeatedly in a cycle until the system is completed
Basics of analysis and design performed immediately, with quick and dirty program development of the initial prototype, which provides a minimal number of features
First prototype shown to users and project sponsor, and comments used to reanalyze, redesign and reimplement until agreement on functionality
After the prototype is installed, refinement occurs until it's accepted as the new system

Very quickly provides a system that users can interact with
Reassures users that project team is working on the system (no long delays)
Quickly refines requirements, allows users to interact with a prototype to better understand what it can and cannot do

Fast-paced system releases challenge attempts to conduct careful, methodical analysis
Significant changes to the prototype may cause initial design decisions to become poor ones
Problems might not be recognized until well into the development process related to complex systems

Prototypes are done at a different point in the SDLC
Different purpose and appearance than previously discussed prototypes
Used for analysis and developing ideas for the system concept
Understanding issues and developing a design prototype
Not a working system, but represents part of the system that needs refinement, with enough detail to understand problems

Serves as a tool for understanding an idea and identifying issues and problems
Users may not completely understand many suggested features, or technical challenges
For example, web page mockups can simulate a system without functionality

Balance well-thought-out analysis and design phases, with advantages of refining key issues before developing the system
Methodologies might take longer to produce the final system (prototypes don't become the final system) but produce more stable and reliable systems

Iterative and flexible approach to software development, emphasizing collaboration, adaptability, and continuous improvement
Includes the following key principles:
- Customer collaboration over contract negotiation
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Responding to change over following a plan
Continuous feedback and adaptation is fundamental. At the end of each iteration, the progress is reviewed, feedback is gathered, and improvements are incorporated into subsequent iterations
Allows for early and frequent delivery to increasing customer satisfaction and reducing risk of large-scale failures
Includes sub-methodologies such as Extreme Programming, Scrum, and Kanban

Founded on four core values: communication, simplicity, feedback, and courage
Developers provide rapid feedback to end users continuously
Developers follow the KISS principle
Developers make incremental changes (not only accepting change but also embracing change).
Developers have a quality-first mentality, which supports team members in developing their own skills.
Uses continuous testing, simple coding performed by pairs, and close interactions with end users.
Phases of analysis, design, and implementation are performed iteratively after a planning process.

Testing and efficient coding practices (code is tested each day and placed into integrative testing environment)
Refactoring (to restructure code and keep it simple)

Suitable for small projects with highly motivated, cohesive, stable, and experienced teams
Project success is doubtful if projects are large or teams are not jelled
Lack of detailed analysis/design documentation with XP can make maintaining large systems challenging

Throwaway prototyping is generally appropriate for projects with unclear user requirements, or high risk technologies
Phased development is a good methodology when early interactions between user and system are valuable or needed, but detailed analysis and design might be less important
Prototyping approaches are good when time to market is key, but system reliability might suffer in critical systems
Traditional structured development methods can handle large and complex systems, but they might be slow in user involvement or feedback