System Analysis and Design (SAD) UNITI What is a system? System is an interrelated set of components, with identifiable boundary, working together for some purpose. Examples + Solar system + Digestive systems * Public transport system + Central heating system + Computer system + Information system A set of objects and relationships among the objects viewed as a whole and designed to achieve a purpose A system has nine characteristics: * Components or Subsystems + Interrelated components + Aboundary + Apurpose + Anenvironment + Interfaces + Input + Output + Constraints Component: An irreducible part or aggregation of parts that make up a system, also called a subsystem. A subsystem is simply a system within a system. Automobile is a system composed of subsystems: + Engine system + Body system + Frame system + Each of these subsystem is composed of sub-sub ~systems. + Engine system: carburetor system, generator system, fuel system, and so son Interrelated components + Dependence of one subsystem on one or more subsystemsBoundary + The line that marks the inside and outside of a system and that sets off the system form its environment * The overall goal or function of a system Environment + Everything external to a system that interacts with the system Interface + Point of contact where a system meets its environment or where subsystems meet each other. + A limit to what a system can accomplish Input + Whatever a system takes from its environment in order to fulfill its purpose Output + Whatever a system returns from its environment in order to fulfill its purpose sa system: srs, food Storage Office i. Outputs: Inputs: Prepared Food Kitche . food labor. am, Dining freely cash, Riou taking te. Trash Contour is from its not Boundary u —— interrelationship Fig: A Fast food Restaurants as a system Environments: customers, food, distribution, banks, etc Bad System + Fail to meet requirements + Poor performance + Poor reliabilitywww.bcanotesnepal.com+ Lack of usability + Example difficulties: + Not to schedule + Not to budget + Runaway = 100% over budget or schedule + Some problems are simply “wicked” problems Then, what is good system? What is an Information System? O’Brien Defines: Any organized combination of people, hardware, software, communications networks, and data resources that stores, retrieves, transforms, and disseminates information in an organization. HICKS Defins: IS as a formalised computer information system that can collect, store, process, and report data from various sources to provide the information necessary for management decision making Laudon and Laudon (1995) defines: IS as a set of interrelated components that collect (or retrieve), process, store and disseminate information to support decision making, control, analysis and visualisation in an organisation. Components of an Information System * People Network Software Hardware Data Levels of Information System a) Operational-level Systems Support operational managers by keeping track of the elementary activities and of the organisation. The principle purpose of systems at this level is to answer routine questions and track the flow of transactions through the organisation. Covers things such as sales, receipts, cash deposits, payroll, credit decisions, flow of materials. Knowledge-level Systems Support knowledge and data workers in an organisation. The purpose of these systems to help the organisation discover, organise and integrate new and existing knowledge in to the business, and to help control the flow of paperwork. These b)systems, specially in the form of collaboration tools, workstations, and office systems, are the fastest growing applications in business today. Management-level Systems Designed to serve the monitoring, controlling, decision-making, and administrative activities of middle managers. These typically provide periodic reports rather than instant information on operations. Some of these systems support non-routine decision-making, focusing on less-structured decisions for which information requirements are not always clear. This will often require information from outwith the organisation, as well as from normal operational-level data. ©) d) Strategic Level Systems Help senior management tackle and address strategic issues and long-term trends, both within the organisation and in the external environment. Principal concem is matching organisational capability to changes, and opportunities, occurring in the medium to long term (i.e. 5 - 10 years) in the external environment. + Typically, an organisation might have operational, knowledge, management and strategic level systems for each functional area within the organisation. This would be based on the management model adopted by the organisation, so, while the most commonly- adopted systems structure would simply follow the standard functional model, structures reflecting bureaucratic, product and matrix models are also possible. ‘TYPES OF SYSTEMS Executive Support Systems (ESS) o feretasting plan orecastion Management Tnfermation Systems (MIS) Sales av Ma a management contre! budget investment analysis analysis Decision. Salesregion Prodvction Cast Pricingpofitailiy Contract cost ‘Support Systems (DSS) _analyas—_schedullng_anayss_anaiss anti Knowledge Work Systems (KWS) otfice ‘Automation Systems (OAS) Transaction us Processing Systems | order processing Material movement Cash nanayerent Accounts rcehable Enlaye recordkeeping eS oat e ) Salesané —-Wanwfacturing ———Finarce ‘ecoantiog Human Marketing Resources } As identified before, enterprise level information systems attempt to encompass the whole organisation in one system( GEELEDED characteristics of Information Processing systems ‘Typeot System Information Inputs Processing Information Outputs Users 55 Graphics; simestoes;Prjcctions:responses. Senior manages inenetive toquenes ss. Special epars; Profesiomls sat i _ managers Operational-level Systems Transaction-Processing Systems (TPS) © Basic business systems . Perform daily routne transactions necessary fr business functions Atthe peg pPoratonel level, take, resources ‘end goals are predefined and highly Benefit systeris Funds managemert Career path systems systems Knowledge-level Systemswww.bcanotesnepal.comOffice Automation Systems (OAS) Targeted at meeting the knowledge needs of data workers within the organisation * Dat ata workers tend to process rather than create information. Primarily involved in information use, manipulation or dissemination. Typical OAS handle and manage documents, scheduling and communication. Knowledge Work Systems (KWS) + Targeted at meeting the knowledge needs of knowledge workers within the organisation + In general, knowledge workers hold degree-level professional qualifications (e.g. engineers, scientists, lawyers), their jobs consist primarily in creating new fneraton and knoweage pinay $ +KWS, such as scientific or engineering design workstations, promote the creation of new knowledge, and its dissemination and integration throughout the organisation. Management-level Systems Management Information Systems (MIS) MIS provide managers with reports and, in some cases, on-ine access to the organisations current performance and historical records Typically these systems foous entirely on internal events, providing the information for short-term planning and decision making. MIS summarise and report on the basic operations of the organisation, dependent on the underlying TPS for their data, Decision-Support Systems (DSS) * as Mis, these serve the needs of the management level of the organisation * Focus on helping managers make decisions that are semi-structured, unique, or rapidly changing, and not easily specified in advance * Use nema infomation ftom TPS and lS, ut als informaton rom extemal sources Greater analytical power than other systems, incorporate modeling tools, aggregation and analysis ool, and support whatifscenarios, Must provide user-friendly, interactive tools Voyage-estimating Decision Support System Strategictevel Systems Executive Support/Information Systems (ESS/EIS) + Serve the strategic level of the organisation + ESS/EIS address unstructured decisions and create a generalised computing and communications environment, rather than providing any fixed application or specific capability. Such systems are not designed to solve specific problems, but to tackle a changing array of problems+ ESS/EIS are designed to incorporate data about external events, such as new tax laws or competitors, and also draw summarised information from internal MIS and DSS + These systems filter, compress, and track critical data, emphasising the reduction of time and effort required to obtain information useful to executive management + ESS/EIS employ advanced graphics software to provide highly visual and easy-to- use representations of complex information and current trends, but they tend not to provide analytical models http:/www.cba.edu.kw/abo/pdf/SAD-chapter-1 ppt Information systems analysis and design is a complex, challenging, and stimulating organizational process that a team of business and systems professionals uses to develop and maintain computer-based information systems. Although advances in information technology continually give us new capabilities, the analysis and design of information systems is driven from an organizational perspective. Information systems analysis and design is therefore an organizational improvement process. Systems are built and rebuilt for organizational benefits. Benefits result from adding value during the process of creating, producing, and supporting the organization's products and services. Thus the analysis and design of information systems is based on your understanding of the organization's objectives, structure, and processes, as well as your knowledge of how to exploit information technology for advantage. In the current business environment, the Internet, especially the World Wide Web, has been firmly integrated into an organization's way of doing business. Although you are probably most familiar with marketing done on the web and web-based retailing sites, such as eBay or Amazon.com, the overwhelming majority of business use of the web is business-to-business applications. Methodologies are comprehensive, multiple-step approaches to systems development that will guide your work and influence the quality of your final product— the information system. A methodology adopted by an organization will be consistent with its general management style (e.g., an organization's orientation toward consensus management will influence its choice of systems development methodology). Most methodologies incorporate several development techniques.Techniques are particular processes that you, as an analyst, wil follow to help ensure that your work is well thought out, complete, and comprehensible to others on your project team. Techniques provide support for a wide range of tasks, including conducting thorough interviews to determine what your system should do, planning and managing the activities in a systems, development project, diagramming the system's logic, and designing the reports your system will generate. Tools are typically computer programs that make it easy to use and benefit from techniques and to faithfully follow the guidelines of the overall development methodology. To be effective, techniques and tools must both be consistent with an organization's systems development methodology. Techniques and tools must make it easy for systems developers to conduct the steps called for in the methodology. These three elements—methodologies, techniques, and tools— work together to form an organizational approach to systems analysis and design (see Figure). Fig: An organizational approach to systems analysis and design is driven by methodologies, techniques, and tools DEVELOPING INFORMATION SYSTEMS AND THE SYSTEMS DEVELOPMENT LIFE CYCLE Most organizations find it beneficial to use a standard set of steps, called a systems development methodology, to develop and support their information systems. Like many processes, the development of information systems often follows a life cycle. For example, a commercial product follows a life cycle in that it is created, tested, and introduced to the market. Its sales increase, peak, and decline. Finally, the product is removed from the market and replaced by something else. The systems development life cyele (SDLC) is a common methodology for systems development in many organizations; it features several phases that mark the progress of the systems analysis and design effort.SDLC Planning SYSTEMS PLANNING The systems planning phase usually begins with a formal request to the IT y department, called a systems request, which describes problems or desired changes in an information system or a business process. In many companies, IT systems planning is an integral part ye uy of overall business planning. When managers and . 4 liaiaiaainai users develop their business plans, they usually include IT requirements that generate systems . iniebaia, requests. A systems request can come from a top hop ae manager, a planning team, a department head, or i) the IT department itself. The request can be very significant or relatively minor. A major request might involve a new information system or the upgrading of an existing system. in contrast, 2 minor request Step {Aaa poet sis, tnd might ask for a new feature or a change to the user pone interface. The purpose of this phase is to perform a fea preliminary investigation to evaluate an IT-related 5 a —_ business opportunity or problem. The preliminary ier investigation is a critical step because the outcome will affect the entire development process. A key part of the preliminary investigation is a feasibility study as fmt rte * that reviews anticipated costs and benefits and —_—_ Tecommends a course of action based on operational, technical, economic, and time factors. Suppose you are a systems analyst and you receive | HaiRELIT kasinspamm mein a request for a system change or improvement. Your first step is to determine whether it makes sense to launch a preliminary investigation at all. Often you will need to lear more about business operations before you can reach a conclusion. After an investigation, you might find that the information system functions properly, but users need more training. In some situations, you might recommend a business process review, rather than an IT solution. In other cases, you might conclude that a full-scale systems review is necessary. If the development process continues, the next step is the systems analysis phase. SYSTEMS ANALYSIS ‘The purpose of the systems analysis phase is to build a logical model of the new system. ‘The first step is requirements modeling, where you investigate business processes and document what the new system must do to satisfy users. Requirements modelingcontinues the investigation that began during the systems planning phase. To understand the system, you perform fact-finding using techniques such as interviews, surveys, document review, observation, and sampling. You use the factfinding results to build business models, data and process models, and object models. The deliverable for the systems analysis phase is the system requirements document. The system requirements document describes management and user requirements, costs and benefits, and outlines alternative development strategies. THE SYSTEMS ANALYST A systems analyst investigates, analyzes, designs, develops, installs, evaluates, and maintains a company’s information systems. To perform those tasks, a systems analyst constantly interacts with users and managers within and outside the company. On large projects, the analyst works as a member of an IT department team; on smaller assignments, he or she might work alone. Most companies assign systems analysts to the IT department, but analysts also can report to a specific user area such as marketing, sales, or accounting. As amember of a functional team, an analyst is better able to understand the needs of that group and how information systems support the department's mission. Smaller companies often use consultants to perform systems analysis work on an as-needed basis. Responsibilities The systems analyst's job overlaps business and technical issues. Analysts help translate business requirements into IT projects. When assigned to a systems development team, an analyst might help document business profiles, review business processes, select hardware and software packages, design information systems, train users, and plan e-commerce Web sites. A systems analyst plans projects, develops schedules, and estimates costs. To keep managers and users informed, the analyst conducts meetings, delivers presentations, and writes memos, reports, and documentation. Knowledge, Skills, and Education ‘A. successful systems analyst needs technical knowledge, oral and written ‘communication skills, an understanding of business operations, and critical thinking skills. Educational requirements vary widely depending on the company and the position. In a rapidly changing IT marketplace, a systems analyst must manage his or her own career and have a plan for professional development.SYSTEMS DESIGN ‘The purpose of the systems design phase is to create a physical model that will satisfy all documented requirements for the system. At this stage, you design the user interface and identify necessary outputs, inputs, and processes. In addition, you design internal and external controls, including computer-based and manual features to guarantee that the system will be reliable, accurate, maintainable, and secure. During the systems design phase, you also determine the application architecture, which programmers will use to transform the logical design into program modules and code. The deliverable for this phase is the system design specification, which is presented to management and users for review and approval. Management and user involvement is critical to avoid any misunderstanding about what the new system will do, how it will do it, and what it will cost. critical to avoid any misunderstanding about what the new system will do, how it will do it, and what it will cost. SYSTEMS IMPLEMENTATION During the systems implementation phase, the new system is constructed. Whether the developers use structured analysis or 0-O methods, the procedure is the same — programs are written, tested, and documented, and the system is installed. If the system was purchased as a package, systems analysts configure the software and perform any necessary modifications. The objective of the systems implementation phase is to deliver a completely functioning and documented information system. At the conclusion of this phase, the system is ready for use. Final preparations include converting data to the new system's files, training users, and performing the actual transition to the new system. The systems implementation phase also includes an assessment, called a systems evaluation, to determine whether the system operates properly and if costs and benefits are within expectations. SYSTEMS DEVELOPMENT GUIDELINES Develop a Plan: Prepare an overall project plan and stick to it. Complete the tasks in a logical sequence. Develop a clear set of ground rules and be sure that everyone on the team understands them clearly. Involve Users and Listen Carefully to Them: Ensure that users are involved in the development process, especially when identifying and modeling system requirements. When you interact with users, listen closely to what they are saying. Use Project Management Tools and Techniques: Try to keep the project on track and avoid surprises. Create a reasonable number of checkpoints — too many can be burdensome, but too few will not provide adequate control. Develop Accurate Cost and Benefit Information: Managers need to know the cost of developing and operating a system, and the value of the benefits it will provide.You must provide accurate, realistic cost and benefit estimates, and update them as necessary. Remain Flexible: Be flexible within the framework of your plan. Systems development is a dynamic process, and overiap often exists among tasks. The ability to react quickly is especially important when you are working on a system that must be developed rapidly. What is methodology in SDLC? ‘A methodology is a comprehensive plan to be followed, multiple-step approach to system development that will guide your work and influence the quality of information system. It Include the model that needs to be followed, plus the tools and techniques that need to be used. It can be purchased or home-grown. Methodology is purchased because many information system organisations cannot afford to dedicate staff to the development and continuous improvement of a home-grown methodology. Whilst, Methodology vendors have a vested interest in keeping their methodologies current with the latest business and technology trends. Methodology is written information in the form of books and other documents by detailing every activity, which needs to be implemented by system developers which includes documentation forms and reports that need to be provided by the project team. Software Process What is it? When you work to build a product or system, it’s important to go through a series of predictable steps—a road map that helps you create a timely, high- quality result. The road map that you follow is called a “software process.” Who does it? Software engineers and their managers adapt the process to their needs and then follow it. In addition, the people who have requested the software have a role to play in the process of defining, building, and testing it. Why is it important? Because it provides stability, control, and organization to an activity that can, if left uncontrolled, become quite chaotic. However, a modem software engineering approach must be “agile.” It must demand only those activities, controls, and work products that are appropriate for the project team and the product that is to be produced. What are the steps? At a detailed level, the process that you adopt depends on the software that you're building. One process might be appropriate for creating software for an aircraft avionics system, while an entirely different process would be indicated for the creation of a website. What is the work product? From the point of view of a software engineer, the work products are the programs, documents, and data that are produced as a consequence of the activities and tasks defined by the process. How do I ensure that I've done it right?There are a number of software process assessment mechanisms that enable organizations to determine the “maturity” of their software process. However, the quality, timeliness, and long-term viability of the product you build are the best indicators of the efficacy of the process that you use. Software process presents a description of a process from some particular perspective as: + Specification. + Design. + Validation. + Evolution. List of General Software Process Models The list of traditional software development models are: |. Waterfall model Prototype model . Rapid application development model . Incremental model. Agile Model . Iterative model. Spiral model. NOORONA ‘The Waterfall Model ‘The waterfall model is the classical model of software engineering. This model is one of the oldest models and is widely used in government projects and in many major companies. As this model emphasizes planning in early stages, it ensures design flaws before they develop. In addition, its intensive document and planning make it work well for projects in which quality control is a major concern. ‘The pure waterfall lifecycle consists of several non-overlapping stages, as shown in the following figure. The model begins with establishing system requirements and software requirements and continues with architectural design, detailed design, coding, testing, and maintenance. ‘The waterfall model serves as a baseline for many other lifecycle models.==) Detaled Design N ~ ve Maintenance Fig. 2Waterfal Model 4. System requirements: Establishes the components for building the system, including the hardware requirements, software tools, and other necessary components. Examples include decisions on hardware, such as plug-in boards (number of channels, acquisition speed, and so on), and decisions on external pieces of software, such as databases or libraries. 2. Software requirements: Establishes the expectations for software functionality and identifies which system requirements the software affects. Requirements analysis includes determining interaction needed with other applications and databases, performance requirements, user interface requirements, and so on. 3. Architectural design: Determines the software framework of a system to meet the specific requirements, This design defines the major components and the interaction of those components, but it does not define the structure of each component. The external. interfaces and tools used in the project can be determined by the designer. 4. Detailed design: Examines the software components defined in the architectural design stage and produces a Specification for how each components implemented. “Architecture is concemed with the selection of architectural elements, their interaction, and the constraints on those elements and their interactions... Design is concerned with the modularization and cetailed interfaces of the design elements, their algorithms. and procedures, and the data types needed. to support the architecture and to satisfy the requirements.” 5. Coding: Implements the detailed —_ design specification.6. Testing: Determines whether the software meets the specified requirements and finds any errors present in the code. 7. Maintenance: Addresses problems and enhancement requests after the software releases. In each stage, documents that explain the objectives and describe the requirements for that phase are created. At the end of each stage, a review to determine whether the project can proceed to the next stage is held. Your prototyping can also be incorporated into any stage from the architectural design and after. The waterfall method does not prohibit returning to an earlier phase, for example, returning from the design phase to the requirements phase. However, this involves costly rework. Each completed phase requires formal review and extensive documentation development. Thus, oversights made in the requirements phase are expensive to correct later. Because the actual development comes late in the process, one does not see results for a long time. This delay can be disconcerting to management and customers. Many people also think that the amount of documertation is excessive and inflexible. Advantages: Easy to understand and implement. Widely used and known (in theory!). Reinforces good habits: define-before- design, cesign-before-code. Identifies deliverables and milestones. Document driven, URD, SRD, ... etc. Published documentation standards Works well on mature products and weak teams. Omens Disadvantages: 1. Idealized, doesn’t match reality well. 2. Doesn't reflect iterative nature of exploratory development. 3. Unrealistic to expect accurate requirements so early in project. 4. Software is delivered late in project, delays discovery of serious errors. 5. Difficult to integrate risk management. 6. Difficult and expensive to make changes to documents, "swimming upstream”. 7. Significant administrative overhead, costly for small teams and projects ‘The 5 Essential Stages of a RAD Model There are several stages to go through when developing a RAD model including analysis, designing, building, and the final testing phase. These steps can be divided to make them more easily understandable and achievable. The following describes the steps included in all RAD models:Stage 1: Business Modeling This step in the RAD model takes information gathered through many business related sources. The analysis takes all the pertinent information from the company. This info is then combined into a useful description of how the information can be used, when it is processed, and what is making this specific information successful for the industry. Stage 2: Data Modeling During the Data Modeling stage, all the information gathered during the Business Modeling phase is analyzed. Through the analysis, the information is grouped together into different groups that can be useful to the company. The quality of every group of information is carefully examined and given an accurate description. A relationship between these groups and their usefulness as defined in the Business Modeling step is also established during this phase of the RAD model. Stage 3: Process Modeling ‘The Process Modeling phase is the step in the RAD model procedure where alll the groups of information gathered during the Data Modeling step are converted into the required usable information. During the Process Modeling stage changes and optimizations can be done and the sets of data can be further defined. Any descriptions for adding, removing, or changing the data objects are also created during this phase. Stage 4: Application Generation ‘The Application Generation step is when all the information gathered is coded, and the system that is going to be used to create the prototype is built. The data models created are tumed into actual prototypes that can be tested in the next step. Stage 5: Testing and Tumover The Testing and Tumover stage allows for a reduced time in the overall testing of the prototypes created. Every model is tested individually so that components can quickly be identified and switched in order to create the most effective product. By this point in the RAD model, most of the components have already been examined, so major problems with the prototype are not likely. Iterative Development: The problems with the Waterfall Model created a demand or a new method of developing systems which could provide faster results, require less up -front information, and offer greater flexibility. With Iterative Development, the project is divided into small parts. This allows the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users. Often, each iteration is actually a mini-Waterfall process with the feedback from one phase providing vital information for the design of the next phase. In a variation of this model, the software products, which are produced at the end of each step (or series of steps), can 0 into production immediately as incremental releases.SofivareRequremers Analysis Fe Ahesine Dereon V-Shaped Model: Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more than the waterfall model. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation. Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase in order to test the pieces of the software systems ability to work together. However, the low-level design phase lies where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use. Advantages 1. Simple and easy to use. 2. Each phase has specific deliverables. 3. Higher chance of success over the waterfall model due to the early development of test plans during the life cycle. 4. Works well for small projects where requirements are easily understood.Acceptance Test Pan Peete] System Test Pn Ce System Testing Imegration Test Plan Cerin —__, Be Unit Test aay Tar} eT V. odel Disadvantages 1. Very rigid like the waterfall model. 2. Little flexibility and adjusting scope is difficult and expensive. 3. Software is developed during the implementation phase, so no early prototypes of the software are produced. 4. This Model does not provide a clear path for problems found during testing phases. Spiral Model The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spiral builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and altemate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. In the spiral model, the angular ‘component represents progress, and the radius of the spiral represents cost.+ Advantages 1. High amount of risk analysis. 2. Good for large and mission-critical projects. 3. Software is produced early in the software life cycle. + Disadvantages 1. Can be a costly model to use. 2. Risk analysis requires highly specific expertise. 3. Project's success is highly dependent on the risk analysis phase. 4. Doesn't work well for smaller projects Deere ajc, on ident sche is Tegarenens pr fee pan Ireegraton andtestlon as ne phase In Summary, spiral consists of: Planning: Define objectives, constraints, and deliverables Risk: analysis Identify tisks and develop acceptable resolutions Engineering: Develop a prototype that includes all deliverables Evaluation: Perform assessment and testing to develop objectives for next iteration Extreme Programming: An approach to development, based on the development and delivery of very small increments of functionality. It relies on constant code improvement, user involvement in the development team and pair wise programming. It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicityrequires extra work. Contracts may be a problem as with other approaches to iterative development. Select user stories for this, Break down release stores to tasks Evaluate Release system software Fig. 8 The XP Release Cycle test software Extreme Programming Practices Incremental planning : Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these stories into development "Tasks". Small Releases: The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release. Simple Design: Enough design is carried out to meet the current requirements and no more. Test first development: An automated unit test framework is used to write tests for a new piece of functionality before functionality itself is implemented. Refactoring: All developers are expected to re-factor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable. Pair Programming: Developers work in pairs, checking each other's work and providing support to do a good job. Collective Ownership : The pairs of developers work on all areas of the system, so that no islands of expertise develop anc all the developers own all the code. Anyone can change anything. Continuous Integration: As soon as work on a task is complete, itis integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace: Large amounts of over-time are not considered acceptable as the net effect is often to reduce code quality and medium term productivity.On-site Customer: A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation. XP and agile principles 1. Incremental development is supported through small, frequent system releases. 2. Customer involvement means full-time customer engagement with the team. 3. People not process through pair programming, collective ownership and a process that avoids long working hours. 4. Change supported through regular system releases. 5. Maintaining simplicity through constant refactoring of code + Advantages 1. Lightweight methods suit small-medium size projects. 2. Produces good team cohesion. 3. Emphasises final product. 4. Iterative. 5. Test based approach to requirements and quality assurance. + Disadvantages 1. Difficult to scale up to large projects where documentation is essential. 2. Needs experience and skill if not to degenerate into code-and-fix. 3. Programming pairs is costly. 4. Test case construction is a difficult and specialized skill. DIFFERENT APPROACHES TO IMPROVING DEVELOPMENT In the continuing effort to improve the systems analysis and design process, several different approaches have been developed. Attempts to make systems development less ofan art and more of a science are usually referred to as systems engineering or software engineering. As the names indicate, rigorous engineering techniques have been applied to systems development. One manifestation of the engineering approach is CASE tools. CASE Tools Other efforts to improve the systems development process have taken advantage of the benefits offered by computing technology itself. The result has been the creation and fairly widespread use of computer-aided software engineering (CASE) tools. CASE tools have been developed for internal use and for sale by several leading firms, but the best known is the series of Rational tools made by IBM. CASE tools are used to support a wide variety of SDLC activities. CASE tools can be used to help in multiple phases of the SDLC: project identification and selection, project initiation and planning, analysis, design, and implementation and maintenance. An integrated and standard database called a repository is the commonmethod for providing product and tool integration, and has been a key factor in enabling CASE to more easily manage larger, more complex projects and to seamlessly integrate data across various tools and products. The idea of a central repository of information about a project is not new—the manual form of such a repository is called a project dictionary or workbook. ‘The general types of CASE tools ae listed below: Diagramming tools enable system process, data, and control structures to be represented graphically. + Computer display and report generators help prototype how systems ‘look and feel.” Display (or form) and report generators make it easier for the ‘systems analyst to identify data requirements and relationships. + Analysis tools automatically check for incomplete, inconsistent, or incorrect specifications in diagrams, forms, and reports. + Acentral repository enables the integrated storage of specifications, diagrams, reports, and project management information. + Documentation generators produce technical and user documentation in standard formats. + Code generators enable the automatic generation of program and database definition code directly from the design documents, diagrams, forms, and reports. Aca ey te (Ast alae Projet idenicaion Dipl ord seve hgh! Dogrmmning ond moro o credo hue inrmaion ond econ ongaizatnl formar Proj ion Develop projedscpe ond ‘Repo and docameraien gener deel poet plas cnd panning ——_‘fesbiliy Andyss Delrine ond sruduexysem Daron cel proces, ond dala madel reqirenels Logialondphyscal Creal new sem designs erm end epor greats peop digs; rah orddeeuenion desig gets fo dln pects Inpemeision Tonle dig iro on Cd geno ord ans, fom an por generar develop ye, ilmton glen Aecimeraengenercors ode sem ond st docmenaion Mnenance Erle inmaion yen. Aloo rue epee yk] Table 1: EXAMPLES OF CASE USAGE WITHIN THE SDLCAGILE METHODOLOGIES Many approaches to systems analysis and design have been developed over the years. In February 2001, many of the proponents of these altemative approaches met in Utah and reached 2 consensus on several of the underlying principles their various approaches contained. This consensus turned into a document they called “The Agile Manifesto’ According to Fowler (2003), the Agile Methodologies share three key principles: (1) a focus on adaptive rather than predictive methodologies, (2) focus on people rather than roles, and (3) a focus on self-adaptive processes. The Agile Methodologies group argues that software development methodologies adapted from engineering generally do not fit with real-world software development (Fowler, 2003). In engineering disciplines, such as civil engineering, requirements tend to be well understood. Once the creative and difficult work of design is completed, construction becomes very predictable. In addition, construction may account for as much as 90 percent of the total project effort. For software, on the other hand, requirements are rarely well understood, and they change continually during the lifetime of the project. Construction may account for as little as 15 percent of the total project effort, with design constituting as much as 50 percent. Applying techniques that work well for predictable, stable projects, such as bridge building, tend not to work well for fluid, design-heavy projects such as writing software, say the Agile Methodology proponents. What is needed are methodologies that embrace change and that are able to deal with a lack of predictability. One mechanism for dealing with a lack of predictability, which all Agile Methodologies share, is iterative development (Martin, 1999). Iterative development focuses on the frequent production of working versions of a system that have a subset of the total number of required features. Iterative development provides feedback to customers and developers alike. ‘The Agile Methodologies’ focus on people is an emphasis on individuals rather than on the roles that people perform (Fowler, 2003). The roles that people fill, of systems analyst or tester or manager, are not as important as the individuals who fll those roles. Fowler argues that the application of engineering principles to systems development has resulted ina view of people as interchangeable urits instead of a view of people as talented individuals, each bringing something unique to the development team. ‘The Agile Methodologies promote a self-adaptive software development process. As software is developed, the process used to develop it should be refined and improved. Development teams can do this through a review process, often associated with the completion of iterations. The implication is that, as processes are adapted, one would not expect to find a single monolithic methodology within a given corporation or enterprise. Instead, one would find many variations of the methodology, each of which reflects the particular talents and experience of the team using it. Ss eo