Phasen der Systementwicklung

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. 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. 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. 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. 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