Table of Contents

Processes

  • Before 1960
  • The wild 60's
  • The 70's - the First Process
  • Iterative Process
  • Phases in a Process
  • Pre-iterative Analysis und Design
  • Further Iterations

  • Business Processes

    • Teamwork

  • What is a Team ?
  • How to communicate
  • Team Hygiene
  • Communication Rules

    • Processes

    Before 1960

    Computers were mainly used by scientists. The industry believed computers are toys in research. A scientist worked generally alone on his program and he was the only user. Coding was done in machine code. Even a assembler was not available. The computers of this time were 'tube machines'. Working with these machines also included the finding and exchanging of defect tubes.

    The development of assember languages made life much more easi. ( Operation names, variables ). The macro technique of assembler languages enabled structuring of programs.

    Coordination between the programmers was necessary only for the access times to the machine (There was no multi user operation.). There was no need to discuss contents or intefaces of programs because everybody worked on his own stuff.

    In such an environment everybody can code in his own style. The only condition for the program is that the programmer herself must be convinced that the program is running correclty , fits into the storage of the machine and did not run too long. Useability was not considered to be a problem. An amount of 128K was huge. All dirty tricks were allowed to archive the goal under this hard hardware restrictions (f.e. self modifying code). Nobody except the programmer herself could read such programs.

    In research this 'one-person-for-her-own' style remained the usual case for long and still exists. In industry it quickly became different.

    The wild 60's

    The industry detected computer in the 60's. This was the start of the first big mythodology change in software development. The industry had very different expectations what software should do. In research an aplication was written for one project and then never used again.

    In industry an application (f.e. finance applications ) must

    1. run without break-downs (reliability) and

    2. will be changed and extended. (f.e. new taxes are introduced) (maintenance)
    The first programmers in industry still produced some sort of 'Throw-Away' software. But the successor in the job had to maintain the code and normally had big problems to understand what was done there. The Throw - Away software became a product with a lifecycle and additional components (documentation, distributuon path).

    Software as a product might include the following:

    1. a running module with or without the source code

    2. installation tools (description and executables)

    3. external documentation

    4. service (help desk etc.)

    5. education and consulting
    Therefore development processes were developed. They defined:

    The 70's - the First Process

    In the 70's the first programming libraries where developed (f.e. for solving linear equations, statistics etc.). This sort of software had to fullfill additional requirements:

    Minimal interfaces
    programs developed in that time were shipped as obectcode an could not easily be adapted to another application. Only interfaces containing the most important parameters has a chance to be useable in another context.
    Constant functional behaviour and constant (only extended) interfaces for all releases.
    if a library module is used in a product this product depends on the behaviour of this module after an upgrade of the library.
    Reliability
    nobody knows where the library will be used. Reliability must be extreemly high.
    This lead to structured programming and the waterfall process.

    The Waterfall Process

    In industrial development the waterfall process was developed. The process from analysis to shipment was decomposed into steps. Each step was ends with a validation to assure quality. If in later steps corrections has to be done on results of prevoius steps they were declared as 'faults' and tracked.

    The applications to deliver at that time were quite homogenious. Most of them were transactions in COBOL or Assembler on a host system. User interface design included design of screen masks only.

    The functional model used in structured programing was represented by:

    HIPO diagrams
    means hierarchical- input-process-output diagram. This is a good method to check that the decompositin is complete in no data gets lost or comes from nowhere.
    Function hierarchies
    describing the decomposition into subroutines.
    Flow diagrams (Nassi-Schneidermann)
    describing the static model.
    1. Specification
      Task
      Analysing the customer problem
      Result
      Functional specification of software, general properties (runtime, platform etc.)
      Documents
      Preversion of user documentation delivered to test department and document writers.
      Validation
      Review of functional specification by customer or tester.

    2. System Level Design (for bigger projects f.e. operation system development)
      Task
      Decomposition into components. Each component will associated to a development team. Interfaces are designed. Shipment process should be decided.
      Result
      Functional specification for each component
      Documents
      • System design document with interface descriptions
      • project plans
      • comunication pathes
      • change request handling
      delevered to all teams and project management.
      Validation
      Review/ Inspection of system design by developers.

    3. High Level Design
      Task
      Each team chooses languages and platforms to be used if not restricted by system level design. Each component will be decomposed into modules to be implemented by one developer. Interfaces between modules will be defined. On this level the details of a screen mask or any other user interface (macro, command) will be defined.

      The team decides which building blocks or software libraries could be used.

      Result
      Functional specification for each component
      Documents
      • high level design document with interface descriptions of modules
      • extensions of functional specification (error messages and codes, details of macros and command/transaction interface ).
      Validation
      Design inspection by the team. Review of user interface definitions by customer, tester and document writer.

    4. Low Level Design
      Task
      The programmers write flowcharts or Nassi-Schneidermann diagrams. The tester define test environments and design test scenarios according to the specifications.
      Result
      Despription of algorithms
      Documents
      • low level design document
      • corrections of functional specification (error messages and codes, details of macros and command/transaction interface ).
      Validation
      Design inspection by the team. Review of test environment design by the developers.

    5. implementation
      Task
      The developers implement their code and do basic tests. The document writers prepare the user's guides. The testers implement the test environment.
      Result
      Code, documents and test environments
      validation
      code inspections, review of user documentation by developers and testers.

    6. Test and corrections in code and documents. This is a validation step in itself. According to the size of the project the test is devides into one or more levels (normally one for each design level).

    7. Shipment of product

    Lifecycle

    All the steps above are done in the sequence describes above. Normally the analysis phase for the next version/ product does not start after shipment of the previous version but during implementation or test phase of the previous version. The last test phases and high level design normally run in parallel. The implementation phase was the longest one in old old days. Only for huge projects where people from different locations work together the test phase might be as long as the implementation phase.

    Often programs were developed by one person alone or in small teams. Normally team structure and communication were no problem.

    Exercise

    The iterative development process

    With OO methods a new process was defined. Prototyping was the new hit. In the old waterfall process a design correction done after codig was defined as a fault and measured like this. The development environments had changed extreemly in the 80's. The computers were much more powerful and the expectations of the customers increased even more. Applications were much more complicated. Nowadays every office application on a PC works with a graphical user interface and a database. Only very few development teams can start from scratch but have to extend old systems or at least use their interfaces. So the design of each system is done on the base of preassumptions about existing systems or customer input which are normally al least incomplete. A design based on incomplete information and more an approximative than a reliable description of the items to be implemented.

    This gives a total different view on changes to be done after coding started. Here no faults are corrected but new insights are evaluated. Which does not mean that ordinary faults do not occur too. In principle the iterative process is a better describtion of the working style the development teams really did when working with the waterfall process. The whole testing phase in the waterfall process contained the 2nd to last iteration you might say. Actually test phases were mostely longer than design and coding.

    Measured with the new process definition most time is spent in design and consolidation phases. Coding and testing time beomes shorter. This partially is effected by the new measurement (corrections or extensions of design where counted as "error correction time" during test in the old process) and partially by new more powerful programming environments (class libraries, code generators).

    Phases of iterative process

    Terms

    The object/class model is described by graphics and diagrams showing class /object relations.

    Entity - Relationship Diagrams
    coming from data base modeling
    Class Hierarchies
    showing inheritance relations
    Class/Object Relation Diagrams (Booch, Yourdon-Coad,..)
    describing the static model.
    State-Transition Diagrams
    describing effects of events to object states. This is more an if-else-anaysis than the description of events in a time sequence.

    Scenarios
    describing the sequence of messages and events through the system.

    Usage scenarios
    describe actions of a user and the reactions of the system. Usage scenarios can help to explain why the user interface was designed in the manner it is.
    ....

    Domain Class
    is a Class belonging to problem domain. (f.e. class Account) Classes needed for implementation (f.e. SortedCollection) are no domain classes.

    Auxiliary Class
    is a class needed for implementation. They are often candidates to be put into a general library.

    Pre-iterative Analyse and Design

    OO Requirement Analysis

    1. Specifying Requirements. This might take long in a customer project and is often a project for itself (consulting project).

    2. OO Model of problem domain from external view. Here it might be convenient not to use traditional OO notation but use free style. Try to describe the problem domain in the language of the customer. From this description first candidates for classes and relations are archieved. But the final matching of the problem domain to the oo paradigma contains already implementation decisions.

    3. If necessary Prototyp of user interfaces. This can be verified by the customer. This is a popular method of verifying and analyzing requirements for database applications.

    Results

    1. Document describing the external behaviour of the system. This will be verified by the customer.

    2. Description of problem domain in free style

    3. User scenarios

    4. Prototyp of user interface if necessary.

    5. first project plan (overall)
    Check
    Verification of documents and prototype by customer.

    Example of a rough domain analysis:

    In a document all planning rules and detailed definitions would be described. Additionally all abstractions necessary to work with the model (f.e. for doing optimization by heuristic methods) will be described.

    Excersise

    Modelling of Problem Domain

    1. Modelling of problem domain using classes and their implementable relations (inheritance, aggregation, collection,.. ). Here OO design tools can be used for describing the model.

    2. Definition of subsystems

    3. revised project plan with input from sub teams (which prototype when?, contents of each prototype, programming language and -environment, tools, class libraries, platforms, shipping path, ...). Here the prototype model to be realized will be decided. The extreem cases of prottyping are:
      1. Each prototype in each iteration is a total reimplementation. This is often done in rapid prototyping. A very fast development environment (f.e. Smalltalk) is used to implement parts of the final functinality. When the prototype works it is reimplemented in the final environment (f.e. C++).
      2. In each iteration the previous prototype will be functionally extended. This extension can be:
        • The problem is divided into subproblems. Each prototype contains the implementation of one subproblem.
        • Refinement of components (f.e. first prototype works with flat files, next one reads data directly from a data base. So the data interface was exchanged).

    Results

    1. Refinement of external description. This is delivered to the testers, information developers, etc.

    2. Domain class model

    3. Refined project plan
    Check

    Iterative Phase

    Subsystem Level Design

    Here the whole project team still works together.

    1. Rough implementation decisions for next prototype; canditates for auxiliary classes.

    2. Definition of workitems for each team member during the next phase including the agreement on interfaces between items ( "contracts between developers").

    3. Consolidation of new auxiliary classes from previous iterations

    4. Modeling of encapsulation of external interfaces

    5. Identify reusable parts / classes

    6. Generation of test plans, design of test environment

    7. Report of changes (test, information development,..)

    8. Refinement of project plan (assignment of defined work items to team members)

    Results

    1. Specificationen of auxiliary classes

    2. Refinement of object/ class model

    3. Refinement of project plan

    4. Specification of test environment, Layout of documents
    Check

    Class Level Design

    Here normally every developer works on his work item.

    1. internal design (data structures, algorithms)

    Results

    1. Refines class specifications

    2. Output from code generators

    3. secondary prototypes for verification of design (f.e. useability of interfaces, algorithms, ...)
    Check

    Coding and Class Test

    1. Implement classes

    Results

    1. Refined specifications

    2. Source code for new / updated classes

    3. Test results

    Check

    Systemintegration and Test

    1. Building next prototype from source code of all sub systems (in the easiest case its a versioning or "check in" done by every developer)

    2. test of prototype

    Results

    1. Problem reports from test.

    2. The new prototype is input for the next iteration.

    The last prototype is the code to be shipped to the customer.

    Check

    Exercise

    Business Processes

    The expectations of IT tools have gown dramatically. Nowadays a company wants all its processes (planing, production, controling,...) be supported by tools. Big parts of the business proceses of a company are nowadays also casted into IT applications. The design of business processes and IT applications supporting them interact. The term business objects appeared. It names objects having a meaning in IT applications and in the business process.

    Here an example: Assume we have a company called "CD Connection" selling CD's. A customer orders a number of copies of a CD. If it is available in storage it is shipped to the customer otherwaise an order must be sent to the supplier of the ordered CD. With the shipment of the CD a bill is sent. Below it is shown the traditional process.

    The company decided to implement a better support via additonal applications.

    Business Objects are objects to be used (perhaps by inherit from them) by all applications supporting a part of the business process working with an item modelled by this business object. Therefore via business objects a powerfull library for creating IT applications in a company or even for a whole business area (f.e. banking, insurance, steel,...) can be developed. Companies selling custmomizable applications or development tools (f.e. SAP) using this possibility of parallel modeling of processes and applications. Not all of them are using object oriented methods. But they become more and more a standard even for consulting companies working in business process reengineereng. When using an object oriented approach business objects are a result of a reengineering process.

    The work wit business objects have a lot of advantages:

    1. Every item modelled by an business object (f.e. contract, customer, deliverable,... ) can have the same view in every application using it. The user interfaces of all IT applications used become more similiar.
    2. Actions done on a business object can be coded once. Not every application using it must include its own implementation. The company has the possibility to clean up their application zoo.
    3. Business objects are a common data model for interactions between different systems. Here developments like CORBA become important. They enable a platform independant description of classes.

    One problem when reengineering processes and applications is the connection of legacy systems to the new concept. Tools for this exist.

    Teamwork

    What is a Team ?

    A Team is more than a group of people. Becoming an effective team takes time and effort.

    From (13) we learn that a common target is a precondition for building a team out of a group. If there exist no clear measurable and well accepted target the group will flow into political discussions without becoming a team.

    There exist the following obstructions becoming a team (giving up individual goals and go after the team goal):

    1. time consuming meetings (overhead will be high in team building phase)
    2. dependency from others (trust)
    3. acceptance of different meanings from others (openess)
    4. effects from faults made by other team members (helping each other)
    For building a team individual and team resonsibility must come into a balance. The sharing of responsibility for archieving the team goal needs the ability to trust into others. On the other habd individuals will be punished or rewarded. When becoming a team everybody must change his or her behaviour - adapt it to the others - finding/changing his/her role. This needs disciplin.

    Another important precondition is that the team combines different skills. If you have a group consisting only of C-programmers (no design skills, no business domain knowledge ....) the view on the problem to be solved would be too one sided. A real team consists of a group of people combining different skills and found a way to put their different views together to a more global one. No team can be complete. But real teams are learning fast by helping each other. The variety of skills also lead to different roles in different phases of the project. Beside technical skills interpersonal skills ( communication, constructive solution of conflicts, risk taking, helpful critics, active lisening, motivation of others, acceptance of interests of others).

    Effective teams are normally not greater than 10-15 people. Above this limit the communication overhead is too high. Therefore it might be necessary for a project to define subgoals and building subteams to archieve the appropriate sizes for teams.

    A good example of a team are flying geese. The common goal is reaching the same destination. Motivation and help in difficult situations makes it possible to trust each other. The leadership is sequenced.

    The combination of teams might influence the design of a product !! Important points:

    1. location of team members: does it lead to subgroups ?
    2. distance between subgroups
    3. skill distribution
    4. language and cultural differences
    If the project team is scattered into several long distance subgroups it might be necessary to decompose the application into components each handled by one subgroup.

    Beside the technical process also communication and decision pathes and rules for subteams has to be defined. The processes should support decisions and communication an not hinder them. A process does not support the teams when the process practised differ from the planed one too much.

    Communication Pathes

    When setting up a project and project team(s) communication and decision pathes have to be defined. The following list gives a slight idea:
    Delegation
    Assignment of taks to existiting persons. Every NN in the list means an incomplete list. Every assignment should be associated with a percentage number telling how much the assigned person will be working on this task. This list is consistent of overall planned people months for this task are assigned to persons.
    Responsibility / Decisions
    Must be consistent with delegated tasks. Everybody needs the correct empowerment for her assigned task. (Thats not everywhere the case.) Everybody must also be conscious about the limits of its empowerment. (f.e. Developer checks if the user's guide is technically correct, but not style and layout. The writer is responsible for these and does the final decision.)
    Handling of change requests
    A checklist has to be prepared for any sort of change request. The list contains all persons / institutions (customer, vendor, other departments, controlling) need to agree to the change request or need to give input ( estimates on costs and resources, description of interface changes, ...). This list must include all parties affected by the change. F.e. an external interface change affects customer, vendors, tester, infomation development and implementors.
    Problem Handling
    Everybody working on a deliverable can run into problems not fixable by herself. Such problems must be reported, analyzed, fixed, and checked. Additional any problem reported will be tracked and measured to check the quality of the product. Normally the person running into a problem reports it. For all other steps rules have to be made to avoid struggles about responsibilities. The goal is to solve a problem and not to push them to the desk of somebody else. Everybody knowing any affected area of the problem should help in analyzing/ solving it. This is difficult in an environment where individuals are strongly measured by problems/ work item. An appropriate handling of faults and problems needs a good "team hygiene".
    Handling of project delays
    this is a special sort of problem where normally also management is involved.
    Tracking of Process
    This is part of project management. But every team has to think about how to track their part of the process, check and measure their performance. F.e. as a implementor I should always know how much time I need for the items still to do (current position in the process) and how good I did items ( quality, performance).

    Exercise

    Team Hygiene

    1. Responsibility The precondition for delegating responsibility to others is confidence and acceptance. The team members accept strength and weakness of each individual and trust in her decisions. (F.e. Different programming styles are permitted. Each style has advantages and disadvantages. Nobody can dictate a style, but the team may agree on coding/ naming conventions.)

    2. Motivation In a team everybody must appreciate the work of any other. Struggling about competecies will destroy the team and makes it ineffective. Very important is that 'Donkey work' is delegated well balanced. Everybody will give the best input to the team if her/his strengths are used well and is supported in her/his weak points (example of the geese).

    3. Delegation In the ideal team the work is distributed by the team itself. Everybody has her/his preferences and experiences. You could say everybody in a team has its "ecologic corner". These will be accepted in an ideal team. Problems occur ifthere are too many persons in one corner and other corners are empty (Donkey work). Here the team must come to a consense. A member feeling cheated will never belong to this team but works against it.

      Important is not to distribute project phases but project components. F.e. Never devide Design and coding totally. In the OO process design and coding flow into eachother and should be done by one person for a component.

    4. Control Managemant and project leader must track the project and if necessary correct its course. Also the team itself does checkings by inpections etc.. These checkings are difficult to manage and need a lot of "team hygiene". This must be learned.

      Inspections are not done to find so many faults in the work of others possible but to recognize possible problems. The goal is not to solve them directly or to dictate solutions. These can only be suggested.

      Does the management not trust into a new implemented process (esp. if old measurements do not apply any more) the process might be blocked or softened. So the management is in some sense part of the team.

    Exercise

    Comunication Rules

    How does communication works ? Every information we get from our senses are filtered subconsciously and addiditionally changed. We add our interpretations, prejudices, expectations and experiences. Often if we do not like somebody this person might tell what he/she wants. There are few chances that we react friendly. Additionally long trained behaviours get control before we get aware of our reactions. F.e. if somebody speaks in an unfriendly manner to us we become automatically aggressive, sad or anxious. Very often we even do not recognize these automatisms and react unfriendly without knowing it. Our words can be friendly. But the manner how we say them can be unfriendly. This undertone is much more recognized by the receiver of our message than by us.

    Everybody has its own experiences and behaviour structures and therefore evreybody has her/his own filter. Normally it is easi to accept information related to things we already know or we are interested in. Positive feedback (all information we mark to be positive) is also easi for us to accept. Normally people have more difficulties to repeat information correctly they feel to be negative. Especially any negative feelings - they might already be there or be a consequence of the received information - block the acceptance of information. So the information is received incomplete and 'completed' by interpretations and expectations. As a result what we understand from a message might be very different from the information the sender wanted to give.

    By the way on the sender side a similiar filter is working. With every sentence we say we have expectations, a reason why to say it and often a lot of preassumed information in our head we do not tell. So there is a wide field of misunderstanding possible.

    There are no recipes for avoiding such misunderstandings and it takes a long training to avoid them. We can first try to understand the mechanisms of our own 'filter' by carefully watching us and our emotions and reactions. After a while we will recognize perhaps some unpleasant properies of ourself. When we recognized and accepted them we can start to find the reasons. F.e. I became angry - but what was hurted in myself? By this e learn more and more to differentiate between emotions and wishes we have and the one otheres have. In a next step we can try to accept that others have such a filter too which might soften our automatic reactions and give us more humor in dealing with others.

    The following rules describe an ideal case which is very difficult to archieve and perhaps never exist in reality. But they give us a hint where communication processes do not work correctly.

    Basic rules for meetings and talks