System Development


Published on

Phasen der Systementwicklung

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

System Development

  1. 1. System development System Development From SDLC to RAD and JAD. Collected and composed by Stefan Ziegler. November 2001. Phases of System Development Systems Development Life Cycle Principles - SDLC SDLC is a process by which system analysts software engineers, programmers and end-users build information systems and computer applications. It is a project management tool used to plan execute and control systems development projects. There are eight basic priciples: 1. get the users of the system involved 2. use a problem solving approach • identify the problem opportunity or directive • understand the problem's environment and the problem's causes and effects • define the rquirements of a suitable solution • identify lternative solutions • select the quot;bestquot; solution • design and implement the solution • observe ad evaluate the solution's impact Refine the solution accordingly. 3. establish phases and activities • systems planning • systems analysis • systems design • systems implementation • systems support 1
  2. 2. System development 4. establish standards for consistent development and documentation • activities • responsibilities • documentation guidelines or requirements • quality checks 5. justify systems as capital investments • look at several alternativ solutions • evaluate each solution for feasibiity, especially cost-effectiveness 6. don't be afraid to cancel or revise scope • cancel project if no longer feasible • reevaluate costs and schedule if projct scope is to be increased • reduce scope if projct budget and schedule are frozen, but not sufficient to cover all project objectives 7. divide and conquer 8. design systems for growth and change Alternatives to SLDC Prototyping A prototype is quot;an original or model which something is patternedquot; and/or quot;a firstquot;. A full-scale and usually functional form of a new type for design of a construction (as an airplane). Prototyping allows for isolation of problems if both requirements and designs. The prototyping approach is an iterative process involving a close relationship between the designer and the users. Rapid Application Development (RAD) Implements automated systems development tools that have become commonly available in recent years. These advances have allowed developers, in some instances, to forgot the classical quot;life cyclequot; approach and instead use a technique called rapid application development - RAD. It relies upon automated development tools and a restructuring in the way projects are planned and managed. Such an approach was not possible before the advent of automated tools such as those called for CASE tools used for constructing systems. Such tools support traditional development methodology also - the difference is not in the tools themselves but the way they are applied in RAD. Joint Application Development (JAD) Technique that complements other systems analysis and design techniques by emphasizing participative development. It happens among system owners, users, desigers and builders. During JAD sessions for system design, the systems designer will take on the role of facilitator for possibly several full-day workshops intended to address different design issues and deliverables. Going Deeper into Joint Application development (JAD) for Requirements Collection and Management 2
  3. 3. System development JAD is a technique that allows the develoment management, and customer groups to work together to build a product. JAD is still the best method for collecting requirements from the users, customers, or customer advocates (henceforth called user). JAD refers to the joint process of collecting requirements and resolving issues as early as possible through a series of meetings. In early days these meetings were off-site, multiple-day quot;marathon sessionsquot;. The JAD team consists of a mixture of customer functional experts to system professionals in the ratios from 2:1 up to 3:1. The following description of the Traditional System Design may sound familiar to you: In most organizations, the system development life cycle begins with the identification of a need, assignment of a project leader and team, and often the selection of a catchy acronym for the project. The leader pursues a series of seperate meetings with the people who will use the system or will be affected by it. The leader continues these meetings over time. Often the key people involved are not so easy to reach. But eventually, having documented everything possible, the leader translates copious notes into a personal terminology. That's when it becomes that the requirements from, say Accouting, don't mesh with what the Sales departement wants. So the leader calls Sales and finds out the person there is in the field and will not be back until tomorrow. Next day the leader reaches Sales, gets the infomation, calls Accounting, and of course the person in Accounting is now out of office, and so on. When everyone is finally in agreement, alas, the leader discovers that even more people should have been consulted because their needs require something entirely different. In the end, everyone is reluctant to quot;sign offquot; on the specifications. Other times, signing off comes easily. But when the system is delivered, it often has little to do with what the users really need: quot;A user sign off is a powerless piece of paperquot; when matched against the fury of top management. General JAD Principles Involve the stakeholders, including the project sponsor and manager, tech writer and subject matter experts as part of the project team. JAD teams must have support from upper management, both to allow the time and effort spent, and to accept the teams conclusions and results. A technical facilitator with skills in both systems analysis and group dynamic is essential; someone who can speak both the languages of customer and developer. With a neutral facilitator, scribe, high level business sponsor, projet manager, end users, and programmers, this schematic results in faster and more exact application. Ensure that each stakeholder has a representative empowered with decision-making - JAD sessions are working sessions. Mid-level managers are preferred over executives. The sessions may rotate-in special workers to answer detailed questions. Users drive the speed of the project in this phase. Sessions are scheduled at the discretion of the user, but weekly meetings are recommended. Each session should last about 2 hrs (effectiveness drops quickly after the 2hr point). JAD teams should not be more than 15 people, and should be properly selected. Each session must produce JAD minutes, which contains attendess' resolutions action items, and open issues. The facilitator sends copies to all team members and their managers. This is a critically important deliverable to maintain project momentum, accountability, political visibility, and to avoid rework and priority shifting. JAD Tasks To implement the PLC needs a Technical Analyst, a person experienced in group facilitation, systems analysis colleting requirements, and who can speak the languages of both the technical group and users. The Technical Analyst must perform certain tasks and produce associated deliverables complain with the PLC, as follows: • Identify all stakeholders and clarify executive goal. • Scope out the general requirements (project mission and product features) from each of the users' perspectives (business abstract). • Reconcile each user's view of the product with the executive goal into one summary (project abstract). • Define the interaction of the product with users, other products or systems, and the organization (context diagram). 3
  4. 4. System development • Concur on business justification, time box, and cost box for project (preliminary business plan). • Define the ways in which the users will interact or use the new product (use cases). Collect samples of desired inputs and outputs from users. Stick to business processes first, then drill down for data needed and known (quot;knows and doesquot; list). • Prioritize the use cases by collective user preference and risk (Delphi technique). • Validate and review the use case scenarios. • Organize the use cases, constraints, assumptions, and other requirements into a rigorous Software Requirements Specification (SRS). • Design (with technical help) the screen and report layouts. Prototypes are handy for this. Other tasks do not stricly relate to Requirements Collection but the joint team is still responsible for continuing the effort with these items (the user effort is emphasized here): • Review final business plan, which contains cost/benefit analysis and high level design. • Develop a Release Plan and an Acceptance test plan. • Review and sign off the Project Plan, which cotains costs, schedules, test plans, and personnel comitted. This signature is essential to project success, and is signed by the entire project team, including the executive sponsor. • Perform acceptance testing on pre-production (feature releases) and post-production releases of the product. • Define the user documentation style and approve content regularly. • Participate in the change management committee to monitor defects, resolve issues and propose changes. • Sign off on the project when the product is completed. 4
  5. 5. System development Stakeholder Analysis Be prepared for your stakeholders! Process: How can I best discover the needs of my stakeholders? Preparation: What information do you need to collect from stakeholders, and how do you plan to use thisinformation? Performance: What is the most effective way to act upon the information gleaned from the stakeholder analysis? Stakeholder assessment map Stakeholder Goals, Power Importance Role on Win-Win motivations and to and project strategies and interest influence impact on project ... Stakeholder reporting matrix Stakeholder Reports to Amount of Best Frequency Delivery receive detail formatting of reporting mechanism (scope of format interest) ... Use them for best interaction to the stakeholders. 5