Learning Center
Plans & pricing Sign in
Sign Out

Development Process Flow

VIEWS: 1,245 PAGES: 10

									              Requirements                                                Integration System acceptance Acceptance a
                                         Design               Coding
                    back to the development team for corrective action. A successfulTest                             test gives
                    Phase                                                        Phase - - - - - - -operational - -Test - - - -
                                          Phase- - the - - - - PhaseobjectTest - - - -is ready Phase- - - - - - - use. - - Phase - - - -
                    - - - - - - - - the - - - -                              system -
  - - - - - - - - -confidence-to - - - users- that - - developed- - - - - -/ - -
                                                               ---                             for -                 -
                   Define                                                Phase
Marketing      Marketing
  -----------------------------------------------------------------                                                               --------
Engineering        Requirements
  -----------------------------------------------------------------                                                           --------
Architects                            Design

  -----------------------------------------------------------------                                                               --------
                                                     Low Level                                                         Define
Software                                              Design                                                          Release
Developers                                                                                                            Descripti
                                                                 and Unit
  -----------------------------------------------------------------                                                               --------
Integration                                          Integration Test         Integratio
Test                                               Planning and Design          n Test
  -----------------------------------------------------------------                                                               --------
 -----------------------------------------------------------------                                                           --------
                                            System Test Planning and Design                      Syste       Syste
System                                                                                          m Test        m
Test                                                                                           Readin        Test
  ---------------------------------------------------                                            ---
                                                                                              - review-   ---------           --------
Technical                                                   Documentation
                                                                  Design and Write User Training

                                                            Fig: Software Development Process
To be filled

Systems Engineering:

Systems Engineering defines the project processes that provide the baseline for all development
by defining both the problem and solution spaces. It also defines the high-level solution
processes, process controls and product evaluation criteria. It is a formal process that starts with
the customer's initial business requirements brief and systematically identifies all the business
needs and requirements. It defines the total system boundaries and external interfaces, identifies
the business, technical and/or external constraints and if required, analyses and evaluates the
business impact and potential system risks. These inputs are then analyzed against alternate
solutions and the optimum solution selected. The system is then designed and partitioned into its
various components, such as software, hardware, manual processes, interfaces to external
systems and processes, facilities, services and people.

Systems Engineering is an engineering activity performed during the full life cycle of a product.
It supports project management by integrating technical factors in a controllable way for
effective risk management and it provides configuration management with an explicit and
documented system definition for baseline traceability.

The capabilities within the Systems Engineering discipline are subdivided into System Analysis,
Design and Integration on the one hand and Engineering Management on the other.

Analysis techniques
System Analysis, Design and Integration addresses the activities, methods and tools required to
transform an operational need into a description of system performance parameters and a
preferred system configuration. It does this by means of an iterative process of functional
analysis, synthesis, optimisation, definition, design, test and evaluation. This process is globally
illustrated in the figure. Special attention is paid to assure compatibility of physical, functional
and program interfaces in a manner that optimises the total system and design. The process
integrates system performance, producability, reliability, maintainability, supportability and
other specialities into the overall engineering effort.
Systems Engineering

Keywords in this area are:

      Operational and functional analysis
      Function and requirements flow-down, allocation and traceability
      (Performance) resources allocation and management
      Modularity and interface definition
      Design concept selection and trades
      Sensitivity analysis
      Verification planning and control

Engineering Management addresses the activities, methods and tools required to perform the
engineering effort in a controlled, explicit and documented manner. Keywords are:

      Risk assessment and control based on technical inputs
      Requirements traceability and verification control
      Interface control
      Technical Performance Measurement, including technical resources management
      Trade-off methodologies
      End-to-end performance modelling
      Life cycle cost and design-to-cost techniques
      Work flow logic and work breakdown-structure
      Work package descriptions
      Technical baseline control
Analysis tools
Both System Analysis, Design and Integration and Engineering Management are supported by IT
tools, often optimised or even designed in line with the objectives, scope and size of the specific
project. A limited use is made of commercial off-the-shelf tools. Application of these tools is
however not an absolute objective, essential is that the functions required in the project are

Systems Engineering capabilities are maintained by an in-house training and coaching
programme and by a continuous development and refinement of tools, methods and standards.


Systems Engineering techniques at Dutch Space have been developed in response to the needs
arising from projects for space applications. However, over the years they also have been applied
successfully in non-space projects. Examples are:

      Automated Wafer Handling System for ASML International
      Nuclear Medicine Handling System for VU Amsterdam
      Control Actuator System for Euromissile
      Industrial Tunnel building Method in co-operation with Heerema and IHC
      Delay lines for the ESO Very Large Telescope
      Several support contracts for Rail Infra Beheer and Holland Rail Consult
      ConeXpress small test satellite
The software architecture of a program or computing system is the structure or structures of the
system, which comprise software components, the externally visible properties of those
components, and the relationships between them. The term also refers to documentation of a
system's software architecture. Documenting software architecture facilitates communication
between stakeholders, documents early decisions about high-level design, and allows reuse of
design components and patterns between projects.

Software architecture is commonly organized in views, which are analogous to the different
types of blueprints made in building architecture.

Some possible views are:

      Functional/logic view
      Code/module view
      Development/structural view
      Concurrency/process/thread view
      Physical/deployment view
      User action/feedback view
      Data view

Software architecture, also described as strategic design, is an activity concerned with global
design constraints, such as programming paradigms, architectural styles, component based
software engineering standards, design principles, and law-governed regularities. Detailed
design, also described as tactical design, is an activity concerned with local design constraints,
such as design patterns, architecture patterns, programming idioms, and refactoring.
Software development is the set of activities that results in software products. Software
development may include research, new development, modification, reuse, re-engineering,
maintenance, or any other activities that result in software products. Especially the first phase in
the software development process may involve many departments, including marketing,
engineering, research and development and general management. There are several different
approaches to software development, much like the various views of political parties toward
governing a country. Some take a more structured, engineering-based approach to developing
business solutions, whereas others may take a more incremental approach, where software
evolves as it is developed piece-by-piece. Most methodologies share some combination of the
following stages of software development:

      Market research
      Gathering requirements for the proposed business solution
      Analyzing the problem
      Devising a plan or design for the software-based solution
      Implementation (coding) of the software
      Testing the software
      Deployment
      Maintenance and bug fixing

These stages are often referred to collectively as the software development lifecycle, or SDLC.
Different approaches to software development may carry out these stages in different orders, or
devote more or less time to different stages. The level of detail of the documentation produced at
each stage of software development may also vary. These stages may also be carried out in turn
(a “waterfall” based approach), or they may be repeated over various cycles or iterations (a more
"extreme" approach). The more extreme approach usually involves less time spent on planning
and documentation, and more time spent on coding and development of automated tests. More
“extreme” approaches also promote continuous testing throughout the development lifecycle, as
well as having a working (or bug-free) product at all times. More structured or “waterfall” based
approaches attempt to assess the majority of risks and develop a detailed plan for the software
before implementation (coding) begins, and avoid significant design changes and re-coding in
later stages of the software development lifecycle.

There are significant advantages and disadvantages to the various methodologies, and the best
approach to solving a problem using software will often depend on the type of problem. If the
problem is well understood and a solution can be effectively planned out ahead of time, the more
"waterfall" based approach may work the best. If, on the other hand, the problem is unique (at
least to the development team) and the structure of the software solution cannot be easily
envisioned, then a more "extreme" incremental approach may work best. A software
development process is a structure imposed on the development of a software product.
Synonyms include software life cycle and software process. There are several models for such
processes, each describing approaches to a variety of tasks or activities that take place during the

Integration testing is the activity of software testing in which individual software modules are
combined and tested as a group. It occurs after unit testing and before system testing.

Integration testing takes as its input modules that have been unit tested, groups them in larger
aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its
output the integrated system ready for system testing.

The purpose of integration testing is to verify functional, performance and reliability
requirements placed on major design items. These "design items", i.e. assemblages (or groups of
units), are exercised through their interfaces using Black Box Testing, success and error cases
being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas
and inter process communication is tested and individual subsystems are exercised through their
input interface. Test cases are constructed to test that all components within assemblages interact
correctly, for example across procedure calls or process activations, and this is done after testing
individual modules, i.e. unit testing.

The overall idea is a "building block" approach, in which verified assemblages are added to a
verified base which is then used to support the integration testing of further assemblages.

Some different types of integration testing are big bang, Top-down and bottom-up.

Big Bang
In this approach, all or most of the developed modules are coupled together to form a complete
software system or major part of the system and then used for integration testing. The Big Bang
method is very effective for saving time in the integration testing process. However, if the test
cases and their results are not recorded properly, the entire integration process will be more
complicated and may prevent the testing team from achieving the goal of integration testing.

A type of “Big Bang” Integration testing is called Usage Model testing. Usage Model testing
can be used in both software and hardware integration testing. The basis behind this type of
integration testing is to run user-like workloads in integrated user-like environments. In doing the
testing in this manner, the environment is proofed, while the individual components are proofed
indirectly through their use. Usage Model testing takes an optimistic approach to testing, because
it expects to have few problems with the individual components. The strategy relies heavily on
the component developers to do the isolated unit testing for their product. The goal of the
strategy is to avoid redoing the testing done by the developers, and instead flesh out problems
caused by the interaction of the components in the environment. For integration testing, Usage
Model testing can be more efficient and provides better test coverage than traditional focused
functional integration testing. To be more efficient and accurate, care must be used in defining
the user-like workloads for creating realistic scenarios in exercising the environment. This gives
that the integrated environment will work as expected for the target customers.
Top-down and Bottom-up

Bottom-Up Testing is an approach to integrated testing where the lowest level components are
tested first, then used to facilitate the testing of higher level components. The process is repeated
until the component at the top of the hierarchy is tested.

All the bottom or low-level modules, procedures or functions are integrated and then tested.
After the integration testing of lower level integrated modules, the next level of modules will be
formed and can be used for integration testing. This approach is helpful only when all or most of
the modules of the same development level are ready. This method also helps to determine the
levels of software developed and makes it easier to report testing progress in the form of a

Top-Down Testing is an approach to integrated testing where the top integrated modules are
tested and the branch of the module is tested step by step until the end of the related module.

Sandwich Testing is an approach to combine top down testing with bottom up testing.

The traditional software configuration management (SCM) process is looked upon as the best
solution to handling changes in software projects. It identifies the functional and physical
attributes of software at various points in time, and performs systematic control of changes to the
identified attributes for the purpose of maintaining software integrity and traceability throughout
the software development life cycle.

The SCM process further defines the need to trace changes, and the ability to verify that the final
delivered software has all of the planned enhancements that are supposed to be included in the
release. It identifies four procedures that must be defined for each software project to ensure that
a sound SCM process is implemented. They are:

   1.   Configuration identification
   2.   Configuration control
   3.   Configuration status accounting
   4.   Configuration audits

These terms and definitions change from standard to standard, but are essentially the same.

       Configuration identification is the process of identifying the attributes that define every
        aspect of a configuration item. A configuration item is a product (hardware and/or
        software) that has an end-user purpose. These attributes are recorded in configuration
        documentation and baselined. Baselining an attribute forces formal configuration change
        control processes to be effected in the event that these attributes are changed.

       Configuration change control is a set of processes and approval stages required to change
        a configuration item's attributes and to re-baseline them.

       Configuration status accounting is the ability to record and report on the configuration
        baselines associated with each configuration item at any moment of time.

       Configuration audits are broken into functional and physical configuration audits. They
        occur either at delivery or at the moment of effecting the change. A functional
        configuration audit ensures that functional and performance attributes of a configuration
        item are achieved, while a physical configuration audit ensures that a configuration item
        is installed in accordance with the requirements of its detailed design documentation.

System testing of software is testing conducted on a complete, integrated system to evaluate the
system's compliance with its specified requirements. System testing falls within the scope of
black box testing, and as such, should require no knowledge of the inner design of the code or

As a rule, system testing takes, as its input, all of the "integrated" software components that have
successfully passed integration testing and also the software system itself integrated with any
applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies
between the software units that are integrated together (called assemblages) or between any of
the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to
detect defects both within the "inter-assemblages" and also within the system as a whole.

System testing is performed on the entire system in the context of a Functional Requirement
Specification(s) (FRS) and/or a system Requirement Specification (SRS). System testing is an
investigatory testing phase, where the focus is to have almost a destructive attitude and tests not
only the design, but also the behavior and even the believed expectations of the customer. It is
also intended to test up to and beyond the bounds defined in the software/hardware requirements

To top