c





 

: incomplete or changing requirements, limited user involvement, lack of
executive support, lack of technical support, poor project planning, unclear
objectives, and lack of required resources.


 : clear system requirement definitions, substantial user involvement,

support from upper management, thorough and detailed project plans,
realistic work schedules and milestones.


     
 
 
Define the problem, produce the project schedule, confirm problem feasibility,
staff the project, and launch the project. (Scope, requirement, schedule,
budget, feasibility)

  
   

 
 
  
 
Project scope is business level. Information system scope is what the system
can do.


   



    : higher levels of automation require substantially more
funds to implement. Frequently, development teams generate several groups
of capabilities and levels of automation and then project costs to develop
those different packages. With more detailed information about requirements
and assessments of difficulty of developing certain capabilities, a more
accurate cost/benefit analysis can be generated.




    not only must project teams review the technical
feasibility of desired alternatives, but they must also carefully consider
whether the organization has in -house expertise to develop and implement
the system. Frequently, organizations hire additional staff or contract with
outside resources to obtain technical expertise. Usually it is more prudent to
select alternatives that do not require pushing the state of the art. Yet, some
companies with substantial funds and broad access or resources do so. For
cutting-edge projects, a detailed risk analysis is critical.



  
  


  to identify the scope of the system, ensure that the project
is feasible, and develop a schedule, resource pla n, and budget for the
reminder of the project. 
  : to understand and document in detail the
business needs and the processing requirements of the new system.   :
to design the solution system based on the requirements defined and
decisions made during analysis. °  
  : to build, test, and install a
reliable information system with trained users ready to benefit as expected
from use the system. : to keep the system running productively, both
initially and during the many years of the system¶s lifetime.

° 
 
 
  
    
° 
 


 in problem solving, iterations are used to divide a very
large, complex problem into smaller, more easily managed problems. Iteration
means that work activities²analysis, design, implementation---are done once,
then again, and yet again; they are repeated. With each iteration, the
developers refine the results so that it is closer to what is ultimately needed.
Iteration assumes that no one get the right result the first time. Yo u can
organize iterations in several ways. One approach is t o define the key
functions that the system must include and the implement those key functions
in the first iteration. After they are completed, the next sets of required, but not
crucial, system functions are implemented. Finally, optional system functions,
those that would be ³nice to have,´ are implemented in the last iteration.
Another approach is to focus on one subsystem at a time. The first subsystem
implemented contains the core functions and data on which the other
subsystems depend. Then the next iteration includes an additional subsystem,
and so on. °
  
    is a type of iteration approach. With
this approach, you complete parts of the system in a few iterations and the put
the system into operation for users. This approach gets part of the system into
users¶ hand as early as possible so they can benefit from it. Then you
complete a few more iterations to develop another part of the system,
integrate it with the first part, and again put it into operation. Finally, you
complete the last part and integrate it with the rest. Today, much of system
development uses varying degrees of iteration. The object -oriented approach
is always described as highly iterative.


  




The traditional approach includes many variations based on techniques used
to develop information system with structured and modular programming. This
approach referred to as structured system development.
 


  : many people have considere d the structures approach to be
weak because the techniques address only some, but not all, of the activities
of analysis and design. Critics desired a more comprehensive and rigorous
set of techniques to make system development more like engineering and
less like an art. In addition, many people thought the transition from the data
flow diagram to the structure chart did not work well in practice. Others
thought that data modelling and the ERD were much more important than
modelling process with the data f low diagram. The structured approach,
despite its inclusion of data modelling and database design, still made
process rather than data the central focus of the system.



  class data methods in one place !
The OO approach views an information system as a collection of interacting
objects that work together to accomplish tasks.

"  

XP, RAD, Scrum, WISDM

Current approaches ± interative/incremental

Unified Process (RUP, OpenUP etc)
Agile - Agile manifesto
Extreme programming
Scrum
AUP




 
#$%
 
 &   

 
are the activities that the system must perform ²that is, the
business uses to which the system will be applied. They derive directly from
the capabilities identified during project planning. Non-functional: are
characteristics of the system other than activities it must perform of support.
There are some types of non-functional requirements: technical R,
performance R, usability R, reliability R, security R.


 
'
a structured walkthrough is a reviews of the findings from your investigation
and of the models built based on those findings. A walkthrough is considered
structured because analysts have formalized the review process into a set
procedure. The objective of a structured walkthrough is to fine errors and
problems. (

  the key input to a SW is one or more analysis or
design models. A SW should be scheduled as soon as possible after the
documents have been created. Who: the two main parties involved in SW are
the person or people who need their work reviewed and the group that
reviews it. How: a SW requires preparation, execution and follow -up.


 & 
 
   &    
Test plan

")*(
  +
 * 

Object management group, which is a consortium of more than 800 software
vendors, developers and organizations that have combines efforts to develop
and foster uniformity in OO system. OMG¶s mission is to promote the theory
and practice of the object techn ology in the development of distributed
computing system. The OMG maintains and approves any changes to the
standards for OO modelling.

,"-
j Use-Case model/Diagram
 Components: Actors, Use-Case etc
 Includes, Uses
j Use-Case (Description)
 Sections
Descriptions, pre-conditions, post-conditions etc
Actors, stakeholders
Basic flows, alternates and exceptions
j Activity diagram
      (is a simply workflow diagram that describes the various
users or system activities, the person who does the activitie s and
the sequential flow of these activities) ,
 Components
 Difference between Use-Case and Activity diagram
j System sequence diagram
 Purpose
 Components
j State Machine diagram
 Purpose
 Components
j Class diagram
  Domain class
 Design class
 Components, methods, visibility etc
 Generalisation/Specialisation
Y

 

    
Gather information, define system requirements, prioritize requirements,
prototype for feasibility and discovery, generate and evaluate alternatives,
reviews recommendations with management.

  

   
Design and integrate the network, design the application architecture and
software, design the user interface, design the system interface, design and
integrate the database, prototype for design details, design and integra te the
system controls.