tipe4 by xiaoyounan


									Tietojärjestelmien peruskurssi
    Software engineering

        Malin Brännback
        Software Engineering
 Use of sound engineering principles
 good management practice
 applicable tools and methods for SD

 Before   it was more like ad-hoc
 More  disciplined approach to programming
 increase time devoted to program design
 increase productivity through savings in
  testing and maintenance

 gooddesign, good documentation, and
 general control of the project
 Begin   with the idea
     where  do ideas come from?
     Don’t ask what should this screen look like or What
      should this system do?
     Turn them into: What can we do to increase sales?
      How can we improve productivity of our sales
      force? How can the user best work with this
     Instead of how can this be done better? Ask how can
      this be done worse!
 Be illogical
 try something different - instead of technical
  journals; try a toy catalogue
   visualise the process
           form a mental model, walk through the model,
            diagram the problem on paper
   The examples: imagine you are the kid playing the
    game; contact management system; imagine you
    are the sales person
 Break  the bounds - why is there a Save
 Talk to someone
 Brainstorm
 Relax
 Formalise and evaluate
         Formalise and evaluate
 Does it make sense?
 Does it fit with the Enterprise-wide or
  marketing goals
 What risks are involved
 What benefits are provided
 What are the projected costs
 Which idea is best
     Establish the Requirements
=  conceptual design
 goal-centred instead of user-centred
 create the project team
     Creating the Project team
 The entire definition and direction of the
  project will come from the project team
 significant responsibility
 must be carefully selected
 teams should include users, because they
  know the business - they are domain
   Selecting the team members
 Too   many cooks spoil the broth
 too many designers spoil the design
 still, when time limits become stressed the
  problem is solved with adding manpower,
  like dousing a fire with more gasoline,
 keep the team small enough to
  collaborate effectively
           The project team
A   full team with full responsibility
 Then, a core team to do day-to-day work of
  the project
 not more than 5-6 persons
 If the project is very large, break it down
  into smaller pieces with one small team
  assigned to each pieces
                   The full team
   Steering and oversight committee; representatives
    from all areas that are directly or indirectly
   regular meetings, responsible for communicating to their
   access to all project documentation
   minimally, users and technical staff
   ideally; current and present users, managers of these,
    support staff, subject matter experts, SW analysts,
    designers, developers, SW quality control, technical
    writers, technical support staff
 Team members and responsibilities

 Record keeper;maintains the formal project
  documents, requirements specifications, architectural
  design documents
 Project manager;directs the project, decides when to
  bring in specialists, etc.
 Decision     maker; provides the authority to make final
 “Evangelist”;the domain expert with the vision - keeps
  the project in focus
            Setting the scope
 The scope identifies and limits the business or
  functional areas affected by the application -
  application domain
 how does the AD inter-operate with other products
 when defining the AD keep the project goal in
  mind. Only those related to the goal should be
  included - not something for everyone
         Identifying the needs
 What  the business needs to achieve and
  what the user needs to accomplish
 task analysis - spend time with the users
       Specify quality standards
 On   top of basic business needs
        ease of use
        conformity to established user interface conventions

        maintainability

        reliability

        performance

        acceptable defect level

        compatibility with other systems
  Defining the technical and marketing
 Minimal   required hardware configurations
 Recommended
 operating systems
 network configuration
 language, database
 portability, reusability
 number of users, volume of data
  Defining the technical and marketing
 Security requirements
 interface to other systems
 current technical standards
 time to market
 internationalisation
   Prioritising the requirements
 Quality
 schedule
 features
 Pick two of these. There is a trade-off, e.g.
  high quality and tight schedule - trade off
  the features list
      “you   must have the new accounting system installed
         by the first quarter”
10 Myths of project planning and
 We   have no time to design the application
        we    will save time and money if we jump into the
          stepping into a train without having time to travel!
 Scheduling        is for the birds
        toplan for a certain amount of time
        make sure there is room in the plan
10 Myths of project planning and
 Estimates   are certain
      estimates are estimates
      to help convert numbers on a schedule, define risk
      add time based on the risk

      make room for changes in the plan
                      10 Myths..
8 hours = 1 Day
 Keep two sets of schedules
 Pump up the pressure
         there is a difference between “How can I best
          implement this?” and “What can I throw together
          the fastest
 If   the project is behind, add programmers
           the project falls apart - look at the why and fix the
         if
          why, Don’t just add resources
                      10 Myths..
 If   we leave Chris alone it will get done
              is always a Chris who can walk on water; only
         there
         everybody else is keeping Chris busy for technical
 Interim     Releases are a waste of time
         how   “done” are things
 We’ll    Catch up!

To top