Free Essay

System Development Method

In: Other Topics

Submitted By mzdonna
Words 3573
Pages 15
SELECTING A DEVELOPMENT APPROACH
Original Issuance: February 17, 2005

Revalidated: March 27, 2008

Introduction
A system development methodology refers to the framework that is used to structure, plan, and control the process of developing an information system. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations. CMS has considered each of the major prescribed methodologies in context with CMS’ business, applications, organization, and technical environments. As a result, CMS requires the use of any of the following linear and iterative methodologies for CMS systems development, as appropriate.

Acceptable System Development Methodologies
Waterfall
Initial Investigation
Requirements
Definition
System Design
Coding, testing,...
Implementation
Operation &
Support

Framework Type: Linear
Basic Principles:
1. Project is divided into sequential phases, with some overlap and splashback acceptable between phases.
2. Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
3. Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the
_____________________________________________________________________________________________
Office of Information Services
1

user and information technology management occurring at the end of most phases before beginning the next phase.
Strengths:
1. Ideal for supporting less experienced project teams and project managers, or project teams whose composition fluctuates.
2. The orderly sequence of development steps and strict controls for ensuring the adequacy of documentation and design reviews helps ensure the quality, reliability, and maintainability of the developed software.
3. Progress of system development is measurable.
4. Conserves resources.
Weaknesses:
1. Inflexible, slow, costly and cumbersome due to significant structure and tight controls.
2. Project progresses forward, with only slight movement backward.
3. Little room for use of iteration, which can reduce manageability if used.
4. Depends upon early identification and specification of requirements, yet users may not be able to clearly define what they need early in the project.
5. Requirements inconsistencies, missing system components, and unexpected development needs are often discovered during design and coding.
6. Problems are often not discovered until system testing.
7. System performance cannot be tested until the system is almost fully coded, and undercapacity may be difficult to correct.
8. Difficult to respond to changes. Changes that occur later in the life cycle are more costly and are thus discouraged.
9. Produces excessive documentation and keeping it updated as the project progresses is time-consuming. 10. Written specifications are often difficult for users to read and thoroughly appreciate.
11. Promotes the gap between users and developers with clear division of responsibility.
Situations where most appropriate:
1. Project is for development of a mainframe-based or transaction-oriented batch system.
2. Project is large, expensive, and complicated.
3. Project has clear objectives and solution.
4. Pressure does not exist for immediate implementation.
5. Project requirements can be stated unambiguously and comprehensively.
6. Project requirements are stable or unchanging during the system development life cycle.
7. User community is fully knowledgeable in the business and application.
8. Team members may be inexperienced.
9. Team composition is unstable and expected to fluctuate.
10. Project manager may not be fully experienced.
11. Resources need to be conserved.
12. Strict requirement exists for formal approvals at designated milestones.
Situations where least appropriate:
1. Large projects where the requirements are not well understood or are changing for any reasons such as external changes, changing expectations, budget changes or rapidly changing technology.
_____________________________________________________________________________________________
Office of Information Services
2

2. Web Information Systems (WIS) primarily due to the pressure of implementing a WIS project quickly; the continual evolution of the project requirements; the need for experienced, flexible team members drawn from multiple disciplines; and the inability to make assumptions regarding the users’ knowledge level.
3. Real-time systems.
4. Event-driven systems.
5. Leading-edge applications.

Prototyping
Requirements
Definition
Coding, testing,...

Implementation

Initial Investigation

Maintenance

System Design

Framework Type: Iterative
Basic Principles:
1. Not a standalone, complete development methodology, but rather an approach to handling selected portions of a larger, more traditional development methodology (i.e.,
Incremental, Spiral, or Rapid Application Development (RAD)).
2. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
3. User is involved throughout the process, which increases the likelihood of user acceptance of the final implementation.
4. Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users’ requirements.
5. While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.
6. A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.
Strengths:
1. “Addresses the inability of many users to specify their information needs, and the difficulty of systems analysts to understand the user’s environment, by providing the user with a tentative system for experimental purposes at the earliest possible time.” (Janson and Smith, 1985)
2. “Can be used to realistically model important aspects of a system during each phase of the traditional life cycle.” (Huffaker, 1986)
3. Improves both user participation in system development and communication among project stakeholders.
_____________________________________________________________________________________________
Office of Information Services
3

4. Especially useful for resolving unclear objectives; developing and validating user requirements; experimenting with or comparing various design solutions; or investigating both performance and the human computer interface.
5. Potential exists for exploiting knowledge gained in an early iteration as later iterations are developed. 6. Helps to easily identify confusing or difficult functions and missing functionality.
7. May generate specifications for a production application.
8. Encourages innovation and flexible designs.
9. Provides quick implementation of an incomplete, but functional, application.
Weaknesses:
1. Approval process and control is not strict.
2. Incomplete or inadequate problem analysis may occur whereby only the most obvious and superficial needs will be addressed, resulting in current inefficient practices being easily built into the new system.
3. Requirements may frequently change significantly.
4. Identification of non-functional elements is difficult to document.
5. Designers may prototype too quickly, without sufficient up-front user needs analysis, resulting in an inflexible design with narrow focus that limits future system potential.
6. Designers may neglect documentation, resulting in insufficient justification for the final product and inadequate records for the future.
7. Can lead to poorly designed systems. Unskilled designers may substitute prototyping for sound design, which can lead to a “quick and dirty system” without global consideration of the integration of all other components. While initial software development is often built to be a “throwaway”, attempting to retroactively produce a solid system design can sometimes be problematic.
8. Can lead to false expectations, where the customer mistakenly believes that the system is
“finished” when in fact it is not; the system looks good and has adequate user interfaces, but is not truly functional.
9. Iterations add to project budgets and schedules, thus the added costs must be weighed against the potential benefits. Very small projects may not be able to justify the added time and money, while only the high-risk portions of very large, complex projects may gain benefit from prototyping.
10. Prototype may not have sufficient checks and balances incorporated.
Situations where most appropriate:
1. Project is for development of an online system requiring extensive user dialog, or for a less well-defined expert and decision support system.
2. Project is large with many users, interrelationships, and functions, where project risk relating to requirements definition needs to be reduced.
3. Project objectives are unclear.
4. Pressure exists for immediate implementation of something.
5. Functional requirements may change frequently and significantly.
6. User is not fully knowledgeable.
7. Team members are experienced (particularly if the prototype is not a throw-away).
8. Team composition is stable.
9. Project manager is experienced.
10. No need exists to absolutely minimize resource consumption.
_____________________________________________________________________________________________
Office of Information Services
4

11. No strict requirement exists for approvals at designated milestones.
12. Analysts/users appreciate the business problems involved, before they begin the project.
13. Innovative, flexible designs that will accommodate future changes are not critical.
Situations where least appropriate:
1. Mainframe-based or transaction-oriented batch systems.
2. Web-enabled e-business systems.
3. Project team composition is unstable.
4. Future scalability of design is critical.
5. Project objectives are very clear; project risk regarding requirements definition is low.

Incremental
Framework Type: Combination Linear and Iterative
Basic Principles:
Various methods are acceptable for combining linear and iterative system development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process:
1. A series of mini-Waterfalls are performed, where all phases of the Waterfall development model are completed for a small part of the system, before proceeding to the next increment; OR
2. Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual increments of the system, OR
3. The initial software concept, requirements analysis, and design of architecture and system core are defined using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the final prototype (i.e., working system).
Strengths:
1. Potential exists for exploiting knowledge gained in an early increment as later increments are developed.
2. Moderate control is maintained over the life of the project through the use of written documentation and the formal review and approval/signoff by the user and information technology management at designated major milestones.
3. Stakeholders can be given concrete evidence of project status throughout the life cycle.
4. Helps to mitigate integration and architectural risks earlier in the project.
5. Allows delivery of a series of implementations that are gradually more complete and can go into production more quickly as incremental releases.
6. Gradual implementation provides the ability to monitor the effect of incremental changes, isolate issues and make adjustments before the organization is negatively impacted.
Weaknesses:
1. When utilizing a series of mini-Waterfalls for a small part of the system before moving on to the next increment, there is usually a lack of overall consideration of the business problem and technical requirements for the overall system.
_____________________________________________________________________________________________
Office of Information Services
5

2. Since some modules will be completed much earlier than others, well-defined interfaces are required.
3. Difficult problems tend to be pushed to the future to demonstrate early success to management. Situations where most appropriate:
1. Large projects where requirements are not well understood or are changing due to external changes, changing expectations, budget changes or rapidly changing technology.
2. Web Information Systems (WIS) and event-driven systems.
3. Leading-edge applications.
Situations where least appropriate:
1. Very small projects of very short duration.
2. Integration and architectural risks are very low.
3. Highly interactive applications where the data for the project already exists (completely or in part), and the project largely comprises analysis or reporting of the data.

Spiral

Determine Objectives,
Alternatives, Constraints

Evaluate Alternatives
Identify, Resolve Risks

Develop, Verify
Next Level Product
Plan Next Phases

Framework Type: Combination Linear and Iterative
Basic Principles:
1. Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.
2. “Each cycle involves a progression through the same sequence of steps, for each portion of the product and for each of its levels of elaboration, from an overall concept-ofoperation document down to the coding of each individual program.” (Boehm, 1986)
3. Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives; identify and resolve
_____________________________________________________________________________________________
Office of Information Services
6

risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration. (Boehm, 1986 and 1988)
4. Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment. (Boehm, 2000)
Strengths:
1. Enhances risk avoidance.
2. Useful in helping to select the best methodology to follow for development of a given software iteration, based on project risk.
3. Can incorporate Waterfall, Prototyping, and Incremental methodologies as special cases in the framework, and provide guidance as to which combination of these models best fits a given software iteration, based upon the type of project risk. For example, a project with low risk of not meeting user requirements, but high risk of missing budget or schedule targets would essentially follow a linear Waterfall approach for a given software iteration. Conversely, if the risk factors were reversed, the Spiral methodology could yield an iterative Prototyping approach.
Weaknesses:
1. Challenging to determine the exact composition of development methodologies to use for each iteration around the Spiral.
2. Highly customized to each project, and thus is quite complex, limiting reusability.
3. A skilled and experienced project manager is required to determine how to apply it to any given project.
4. There are no established controls for moving from one cycle to another cycle. Without controls, each cycle may generate more work for the next cycle.
5. There are no firm deadlines. Cycles continue with no clear termination condition, so there is an inherent risk of not meeting budget or schedule.
6. Possibility exists that project ends up implemented following a Waterfall framework.
Situations where most appropriate:
1. Real-time or safety-critical systems.
2. Risk avoidance is a high priority.
3. Minimizing resource consumption is not an absolute priority.
4. Project manager is highly skilled and experienced.
5. Requirement exists for strong approval and documentation control.
6. Project might benefit from a mix of other development methodologies.
7. A high degree of accuracy is essential.
8. Implementation has priority over functionality, which can be added in later versions.
Situations where least appropriate:
1. Risk avoidance is a low priority.
2. A high degree of accuracy is not essential.
3. Functionality has priority over implementation.
4. Minimizing resource consumption is an absolute priority.

_____________________________________________________________________________________________
Office of Information Services
7

Rapid Application Development (RAD)
Framework Type: Iterative
Basic Principles:
1. Key objective is for fast development and delivery of a high quality system at a relatively low investment cost.
2. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
3. Aims to produce high quality systems quickly, primarily through the use of iterative
Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders,
Computer Aided Software Engineering (CASE) tools, Database Management Systems
(DBMS), fourth-generation programming languages, code generators, and object-oriented techniques. 4. Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance.
5. Project control involves prioritizing development and defining delivery deadlines or
“timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.
6. Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interaction.
7. Active user involvement is imperative.
8. Iteratively produces production software, as opposed to a throwaway prototype.
9. Produces documentation necessary to facilitate future development and maintenance.
10. Standard systems analysis and design techniques can be fitted into this framework.
Strengths:
1. The operational version of an application is available much earlier than with Waterfall,
Incremental, or Spiral frameworks.
2. Because RAD produces systems more quickly and to a business focus, this approach tends to produce systems at a lower cost.
3. Engenders a greater level of commitment from stakeholders, both business and technical, than Waterfall, Incremental, or Spiral frameworks. Users are seen as gaining more of a sense of ownership of a system, while developers are seen as gaining more satisfaction from producing successful systems quickly.
4. Concentrates on essential system elements from user viewpoint.
5. Provides the ability to rapidly change system design as demanded by users.
6. Produces a tighter fit between user requirements and system specifications.
7. Generally produces a dramatic savings in time, money, and human effort.
Weaknesses:
1. More speed and lower cost may lead to lower overall system quality.
2. Danger of misalignment of developed system with the business due to missing information. 3. Project may end up with more requirements than needed (gold-plating).
_____________________________________________________________________________________________
Office of Information Services
8

4. Potential for feature creep where more and more features are added to the system over the course of development.
5. Potential for inconsistent designs within and across systems.
6. Potential for violation of programming standards related to inconsistent naming conventions and inconsistent documentation.
7. Difficulty with module reuse for future systems.
8. Potential for designed system to lack scalability.
9. Potential for lack of attention to later system administration needs built into system.
10. High cost of commitment on the part of key user personnel.
11. Formal reviews and audits are more difficult to implement than for a complete system.
12. Tendency for difficult problems to be pushed to the future to demonstrate early success to management. 13. Since some modules will be completed much earlier than others, well-defined interfaces are required.
Situations where most appropriate:
1. Project is of small-to-medium scale and of short duration (no more than 6 man-years of development effort).
2. Project scope is focused, such that the business objectives are well defined and narrow.
3. Application is highly interactive, has a clearly defined user group, and is not computationally complex.
4. Functionality of the system is clearly visible at the user interface.
5. Users possess detailed knowledge of the application area.
6. Senior management commitment exists to ensure end-user involvement.
7. Requirements of the system are unknown or uncertain.
8. It is not possible to define requirements accurately ahead of time because the situation is new or the system being employed is highly innovative.
9. Team members are skilled both socially and in terms of business.
10. Team composition is stable; continuity of core development team can be maintained.
11. Effective project control is definitely available.
12. Developers are skilled in the use of advanced tools.
13. Data for the project already exists (completely or in part), and the project largely comprises analysis or reporting of the data.
14. Technical architecture is clearly defined.
15. Key technical components are in place and tested.
16. Technical requirements (e.g., response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used. Targeted performance should be less than 70% of the published limits of the technology.
17. Development team is empowered to make design decisions on a day-to-day basis without the need for consultation with their superiors, and decisions can be made by a small number of people who are available and preferably co-located.
Situations where least appropriate:
1. Very large, infrastructure projects; particularly large, distributed information systems such as corporate-wide databases.
2. Real-time or safety-critical systems.
3. Computationally complex systems, where complex and voluminous data must be analyzed, designed, and created within the scope of the project.
_____________________________________________________________________________________________
Office of Information Services
9

4. Project scope is broad and the business objectives are obscure.
5. Applications in which the functional requirements have to be fully specified before any programs are written.
6. Many people must be involved in the decisions on the project, and the decision makers are not available on a timely basis or they are geographically dispersed.
7. The project team is large or there are multiple teams whose work needs to be coordinated.
8. When user resource and/or commitment is lacking.
9. There is no project champion at the required level to make things happen.
10. Many new technologies are to be introduced within the scope of the project, or the technical architecture is unclear and much of the technology will be used for the first time within the project.
11. Technical requirements (e.g., response times, throughput, database sizes, etc.) are tight for the equipment that is to be used.

References:
“System Development Methodologies for Web Enabled E-Business: A Customization
Paradigm”; Linda Night, Theresa Steinbach, and Vince Kellen; November 2001;
(http://www.kellen.net/SysDev.htm)
“A Survey of System Development Process Models”; Darryl Green and Ann DiCaterino;
Center for Technology in Government; February 1998;
(http://www.ctg.albany.edu/publications/reports/survey_of_sysdev)
“System Development Life Cycle Models and Methodologies”; Paul Fisher, James McDaniel, and Peter Hughes; Canadian Society for International Health Certificate Course in Health
Information Systems, Module 3: System Analysis & Database Development, Part 3: Life Cycle
Models and Methodologies; (http://famed.ufrgs.br/pdf/csih/mod3/Mod_3_3.htm)
“Rapid Application Development: A Review and Case Study”; Paul Beynon-Davies; Kane
Thompson Centre; December 1998;
(http://www.comp.glam.ac.uk/SOC_Server/research/gisc/RADbrf1.htm)
“Introduction to Systems Analysis, Topic 19, Rapid Application Development”; J. R. McBride;
Copyright 2002 Prentice-Hall, Inc.;(http://www.csc.uvic.ca/~jmcbride/c375t19.pdf)

_____________________________________________________________________________________________
Office of Information Services
10…...

Similar Documents

Premium Essay

System Development

...Grantham University August 21, 2012 According to Haag, System development life cycle is a step- by-step approach for developing information systems. Development of systems does create improved database systems for utilization. Written criteria and processes must guide all information systems processing functions. There are several phases that will be discussed such as planning, analysis, design, and implementation. In this paper evidences that will primarily be socially impacted will be discussed as well. System development does have significant impact in any industry. One must be able to strategically plan appropriately in order for it to be a success. Planning within an organization can be very time consuming, planning takes a lot of thought, and consideration. A manager must first put the organization first when planning because it can affect the business if not planned correctly. A manager must determine what the company goals are, and be able to achieve the company’s goal. Organization goals are normally established by the company policies on how they expect their business should run, and the manager is to plan a strategy to meet the company expectation. Analysis places an important role in reconstructing systems using information systems. According to Wikipedia, the goal of system analysis is to determine where the problem is in an attempt to fix the system. This step involves breaking down the system in different pieces to analyze the situation,......

Words: 603 - Pages: 3

Premium Essay

System Development Life Cycle

...SYSTEM ANALYSIS AND DESIGN System development life cycle INTRODUCTION Systems Development: is the entire process of creating an application, gathering user requirements, designing the database, designing the modules, coding the programs, testing the product and implementing it. The historical perspective provides insights that inform today’s work. The history started with business applications created in the 1950’s, develops under the influence of legacy systems, and evolves together with technological and social factors. The significance of system changes has increased. Moreover, many specialists now need certain skills in the analysis, understanding, and evaluation of the system development and evolution processes. Systems are created to solve problems. Early systems development often took place in a rather chaotic and haphazard manner, relying entirely on the skills and experience of the individual people members performing the work. The history of systems development has a different fundamental change agent, a different factor which may be thought of as driving the history, of stimulating long-run changes. All system development efforts engage in some combination of the below tasks, System conceptualization, System requirements and benefits analysis, Project adoption and project scoping, System design, Specification of software requirements, Architectural design, Detailed design, Unit development, Software integration and testing, System integration and testing,......

Words: 4408 - Pages: 18

Premium Essay

System Development Life Cycle

...System Development Life Cycle (SDLC) SDLC is a set of activities which are perform by analyst and developer to create the system for software. SDLC is a conceptual model used in project management that describes the stages involved in information system development project from a preliminary study through maintenance of the complete application. SDLC follows six steps-: 1 Preliminary study 2 Determination of system requirement 3 System design 4 Software development 5 System testing 6 Implementation & Maintenance 1 Preliminary study -: Preliminary investigation is the first step in the system development life cycle. The preliminary investigation is a way of handling the user’s request to change, improve or enhance an existing system. The objective is to determine, whether the request is valid and feasible before any recommendation is made to do nothing, improve or modify the existing system, or build altogether a new one. Preliminary study divided into following 3 categories – A. Request Analysis B. Feasibility study C. Request Approval Request Analysis:- In this category, the users need is clearlyIdentify. Analyst identifies that what are the requirements of the user. Feasibility study:- The aim of the feasibility study is to access alternative systems and to propose the most feasible and desirable system for development. Thus, feasibility study provides an overview of the problem and acts as an important checkpoint that should be completed before committing......

Words: 3076 - Pages: 13

Premium Essay

System Development Life Cycle

...Systems Development Life Cycle The systems development life cycle (SDLC) is the overall process for developing information systems from planning and analysis through implementation and maintenance. The SDLC is the foundation for all systems development methodologies and there are literally hundreds of different activities associated with each phase in the SDLC. Typical activities include determining budgets, gathering system requirements, and writing detailed user documentation. The activities performed during each systems development project will vary. The SDLC begins with a business need, followed by an assessment of the functions a system must have to satisfy the need, and ends when the benefits of the system no longer outweigh its maintenance costs. This is why it is referred to as a ‘lifecycle’. The SDLC is comprised of seven distinct phases: planning, analysis, design, development, testing, implementation, and maintenance. This section takes a detailed look at a few of the more common activities performed during the phases of the systems development life cycle along with common issues facing software development projects (see Figure D.1 and Figure D.2 ). Phase 1: Planning The planning phase involves establishing a high-level plan of the intended project and determining project goals. Planning is the first and most critical phase of any systems development effort an organization undertakes, regardless of whether the effort is to develop a system......

Words: 1437 - Pages: 6

Free Essay

System Development Life Cycle

...Welcome to WritePoint, the automated review system that recognizes errors most commonly made by university students in academic essays. The system embeds comments into your paper and suggests possible changes in grammar and style. Please evaluate each comment carefully to ensure that the suggested change is appropriate for your paper, but remember that your instructor's preferences for style and format prevail. You will also need to review your own citations and references since WritePoint capability in this area is limited. Thank you for using WritePoint. System Development Life Cycle Tina Murray XBIS/219 November 1, 2013 Stefanie Chan System Development Life Cycle System Development Life Cycle is defined as “A method that organizations that use large scale IT Projects, that is a framework that has sequential processes for information that can be developed through the system” (Rainer & Turban, 2009, p. 302). The processes are as follows: investigation, analysis, design, programming, testing, implementation, operations, and maintenance. The teams of these processes are users (employees), systems analyst, programmers, and technical specialists. There are IS......

Words: 418 - Pages: 2

Premium Essay

Soft System Method

...The delivery is not on time and been sent back Root definition A system to delivery clothes on time for customers, by coordinate production, delivery or using new central distribution plant or better logistic management, guided by company policy and management decision, in order to deliver products to customers on time. The system is owned by the company owner and operated by the company, within the constraints of logistics time and company promised time period. It is needed because it is considered that item which people bought from the company should be delivered as company promised. CATWOE C-Customers A- Company, central distribution plant T- Deliver cloths to customers on time – that need met W-The world consider that the item which people bought should be delivered as the company promised. O- Company owner E- Logistics time, company promised time period, financial situation Model activity or step | Does it exist in the real world? If so, how is I carried out now? | How do/ would you measure its performance? How well is it carried out now? | Is there a difference between the model and the real world? If so, shall we take it forward for discussion? | Coordinate production and delivery | No | Production report and annual reports | Yes it does exist nowYes, we need to discuss it | Deliver products on time | No | Feedback from customers | Yes it does exist nowNo we don’t need to discuss it | Use computer programmed delivery-inventory | No |...

Words: 699 - Pages: 3

Premium Essay

Systems Development

...captures how the Systems Development Life Cycle applies to each of the bookstores we have reviewed. Given Amazon’s complexity of products and offerings it will most likely be the most difficult to implement where as Barnes & Noble with its limited product offerings could have a better capability of managing the systems development. Amazon.com Given that Amazon is an internet based company SDLC applies often to its business. Depending on the product Amazon is trying to market they will then develop its strategy. and decide whether hardware or software are necessary to implement the plan depending on their specification plan. A plan must be established with design elements to market the product. Establishing a plan to maintain the new system once it is established wraps us the cycle for Amazon.com. Barnes & Nobles Barnes & Noble is a very similar business model to local stores spread throughout the country, as well as internet sales similar to Amazon.com. Barnes & Noble would naturally follow the SDLC process for selection, development, implementation, and maintenance of new systems including programs and hardware. Barnes & Noble faces all of the same challenges as the other businesses with this process, with a primary issue being the selection and planning process which establishes the system requirements. Teams must be established to proceed with the projects and develop them further including testing of early samples. Once testing and development......

Words: 416 - Pages: 2

Free Essay

Formal System Development Methodologies

...Formal System Development Methodologies Carissa Robinson Grayson June 6, 2010 Formal systems development methodologies, also sometimes referred to as Formal Methods, are used to model systems using mathematics. By using mathematics to model a complex system, properties of the system can be verified without empirical testing. (Collins) Formal systems development methodologies are different from other design systems through formal verification, the principles are proven correct before they are accepted. Traditional design systems have been used to verify behavior but testing is capable of only finite conclusions. (Collins) Formal design is usually a three step process. * Step one is when the engineer decides how a system will be using a modeling language. This step is similar to the formal software engineering technique developed by many others. This step helps the engineer to define their problems, goals and solutions. * Step two is the step that deals with verification. Formal methods put a huge emphasis on provability and correctness. Verification is difficult because even the simplest system has at least a dozen theorems that which all must be proven. * Step three is the implementation step. Once the model has been verified, the implementation must then be converting into code. (Collins) There are two important benefits of formal methods. The benefits would be discipline and precision. In formal systems, an engineer is required to......

Words: 1255 - Pages: 6

Free Essay

System Development

...System Development Life Cycle The system development life cycle is a series of steps in which a team creates, builds and implements a new technology system. This cycle is based on six phases which are: planning, analysis, design, construction, test and rollout. The first phase is planning. This is when the team comes together to brainstorm to determine what type of system needs to be created and what will be required in order to complete this. During this process the team creates a very high level view of the system and its intended goals. The next step is analysis. This is when the team determines what functions the system needs to be able to perform to meet the user’s needs. The third step is the design phase. This is when the team designs the flow of the data that will need to occur within the system. The team will use diagrams and models to determine what the best design should be for the flow of the data. The team will also develop a fake code or pseudocode before the true code is written. The step following design is construction. This is when the execution of the design begins to happen. The database is designed and the code is written. The next phase in the cycle is testing. All aspects of the system is tested and retested multiple times to determine if the system contains all of the requirements needed for its users, that data is being processed accurately, that any existing systems are able to communicate with the new system and that it meets the standards set......

Words: 357 - Pages: 2

Premium Essay

System Development

...Library System a. Identified users of the system i. Student of various universities ii. Library Staff * Library Administrator * Assistant Librarian Core features for library staff * Library Administrator * Adds articles * Updates articles * Deletes articles * Disables user * Verify user details * Set user restrictions * Address user complaints * Assistant Librarian * Cataloging articles * View reports of viewed articles from system * Update Article Status Core features for student * Create user account * Update user account * login * Search for an article on the system * Accept to conform to copyright law protecting article * Access article * Log complain or feedback * Unsubscribe b. System features * Database storage * User account details * Student details * Staff details * Information on articles – title, author, fees, source * Copyright laws of each country associated with an article * Search engine for searching for articles * Link to other university libraries * Reports on user activity * Stimulus and response activities * Require conformity to copyright law for each article searched * Assign privileges to various users per role * Check for account validity upon login Question 1 1.1. Prototyping Prototyping allows the systems developer access to a quick and promptly built working version of the system......

Words: 1878 - Pages: 8

Free Essay

Methodology of Information System Development

...INFORMATION SYSTEM DEVELOPMENT Contents 1.1 Introduction 1 1.2 Methodology 1 1.3 Types of Software developing life cycles (SDLC) 2 1. Waterfall Model 2 2. V-Shaped Model 4 3. Evolutionary Prototyping Model 5 4. Spiral Method (SDM) 7 5. Iterative and Incremental Method 8 6. Extreme programming (Agile development) 10 1.4 CASE (computer-aided software engineering) 11 1.5 Conclusion 16 Introduction System development methodology is a standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems. Organizations use a standard set of steps, called system 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 such as a Nike sneaker or a Honda car follows a life cycle; it is created, tested and introduced to the market. Its sales increase, peak and decline. Finally, the product is removed from the market and is replaced with something else. Many options exist for developing information systems, but the most common methodology for system development in many organizations is system development life cycle. However, it is important to know other alternative development methodology available in order to maximize the development process. there are four important terminologies in information systems, namely......

Words: 2577 - Pages: 11

Premium Essay

System Development

...Information System Development. Information system is a collection of hardware, software, and procedures work together to produce Quality Information. Information system MUST meet the requirements of the SYSTEM USER. SYSTEM DEVELOPMENT is a set of activities that you need to develop an INFORMATION SYSTEM. There are many types of information systems; Ø Office information system; is an information system that lets employees perform tasks electronically using computer and electronic devices instead of manual systems. Ø Transaction processing system; is an information system that captures and processes data generated during an organisations day to day activities. Ø Management information system; while computers were ideal for routine transaction processing, managers soon realized that the computers’ capability of performing rapid calculations and data comparisons could produce meaningful information for management. Ø Decision support systems; Transaction processing and management information systems provide information on a regular basis. Frequently, however, users need information not provided in these reports to help them make decisions. A sales manager, for example, might need to determine how high to set yearly sales quotas based on increased sales and lowered product costs. Decision support systems help provide information to support such decisions. Ø Expert systems; An expert system is an information system that captures and stores the......

Words: 671 - Pages: 3

Premium Essay

System Development

...of the system development Life Cycle include; * System investigation, this is where professionals gather information on what problems a business may have,   the software and programs that are needed, and what problems that may occur.   * System analysis, this stage defines in detail the problem, cause, and solution the organizations plan to solve with its information systems.   * System design, this phase is where the technical design is developed. This includes hardware, software, database, telecommunications and procedures. This is done in logical and physical design which states what the system will do and how the system will perform.   * Programming is the process of turning the system design into specifics * Testing, this is where the system is tested to see if the codes will produce desired results. This is done throughout the programming stage.   * Implementation is where the system is deployed and the old system is out. This is done in three stages, direct conversion: the old system is turned off and the new is turned on. Pilot conversion: the system is operational in small areas of the business. Phased conversions: where components are introduced until the system is fully functional.   * Operations and maintenance, where the system is debugged of any problems. The people who participate in the development of the information system are Users such as employees who will be using the system. System......

Words: 264 - Pages: 2

Premium Essay

System Development Lifecycle

... System Development Life Cycle Models Student’s Name: Institution: Date: System Development Life Cycle (SDL) Models Software development is a process which comprises of different phases. The process entails different steps such as software identification, analysis, specification, software design, programming, testing and maintenance (Kececi & Modarres, 2002). Over the years, different models of systems development have been developed which under a complete cycle before the end product. A systems development life cycle (SDLC) is the framework adopted by software analysts to describe the phases involved while developing IS (Shelly & Rosenblatt, 2010; Shelly & Rosenblatt, 2011). There are different System Development Life Cycle Models used in software development process. The major SDLS are waterfall life cycle, spiral life cycle, the prototyping model, and the incremental build model among many others (Rodríguez-Martínez, Mora, Álvarez, Garza, Durán & Muñoz, 2012). The aforementioned SDLC models are referred to as predictive life cycle models. This implies that the cost of designing can be predicted accurately, the scope articulately determined, and the schedule accurately predicted (Schwalbe, 2011; Shelly & Rosenblatt, 2011). The current research study is an attempt to discuss different models and compare them in detail. It also looks at Baltzan’s seven step model versus other software development models. Types of System Development Life Cycle......

Words: 1515 - Pages: 7

Premium Essay

Software Development System

...What is the Software Development Life Cycle (SDLC)? July 9, 2013 justin in insight The Software Development Life Cycle is a process that ensures good software is built.  Each phase in the life cycle has its own process and deliverables that feed into the next phase.  There are typically 5 phases starting with the analysis and requirements gathering and ending with the implementation.  Let’s look in greater detail at each phase: Requirements Gathering/Analysis This phase is critical to the success of the project.  Expectations (whether of a client or your team) need to be fleshed out in great detail and documented.  This is an iterative process with much communication taking place between stakeholders, end users and the project team.  The following techniques can be used to gather requirements: * Identify and capture stakeholder requirements using customer interviews and surveys. * Build multiple use cases to describe each action that a user will take in the new system. * Prototypes can be built to show the client what the end product will look like.  Tools like Omnigraffle, HotGloo and Balsalmiq are great for this part of the process. In a corporate setting, this means taking a look at your customers, figuring out what they want, and then designing what a successful outcome would look like in a new bit of software. Design  Technical design requirements are prepared in this phase by lead development staff that can include architects and lead developers. ......

Words: 917 - Pages: 4