Contribution 52

From WikiContent

Revision as of 19:59, 17 June 2008 by Elandre (Talk | contribs)
Jump to: navigation, search

Apply Systems Engineering practices

Systems Engineering, defined as the practical application of scientific, engineering, and management skills required to transform a users need into a system configuration that satisfies the need, is much more a philosophy than an engineering discipline. Its basically an approach to solve complex problems.

As modern Systems Engineering largely grew out of NASA's high profile, high-risk projects such as Apollo in the 1960s and 1970s, the foundation is much older. It can be traced back to the late 19th century when traditional reductionism proved not work for biology and nuclear physics. The first formal statements on systems thinking is found in the German Gestalt Theory around 1910. The word gestalt mean an organized whole whose parts belong together.

So, how does this relate to software engineering practices in the 21th century? First of all, agile methods such as SCRUM are based on systems thinking and theory. To understand this, think of the development process as a system whose purpose is to create high quality working software under changing circumstances where learning is a key success criteria.

Secondly, what are the lessons learned in systems engineering that can be directly applied to improve software development practices? From Hitchins book advanced systems, thinking, engineering and management we find:

1. Systems engineering requires a clear singular mission and goal. I.e. to put man on the moon and return him safely to Earth by the end of the tour.

2. There should be a sound concept of operation from start to finish. I.e. The mission will be executed in phases, marked by transitions. The first phase will place three men in earth orbit.

3. There should be an overall system design that addresses the whole mission from start to finish. I.e. An overall system design is required to ensure there are no weak links in the chain.

4. Overall system design can be partitioned into complementary interacting subsystems. Each subsystem should have its own clear mission and concept of operation. I.e. Each subsystem must be clarely defined in terms of form, fit, function, and interfaces to ensure overall system integrity upon integration.

5. Each subsystem might be developed independently and in parallel with the others, provided that fit, form, function, and interfaces are maintained. I.e. As part of development, each subsystem should be rigorously tested in representative environment.

6. Upon integration of the subsystems, the whole systems should be subject to tests and trials, real and simulated that exposes it to extremes of environment and to hazards such as might be experienced during mission. I.e. The whole system, including the operators and crew should be subjected to rigorous tests and trials.

Applied on a software development project this mean:

1. Have a clear scope and purpose of the software. 2. Understand how the software is meant to be used. 3. The software must be designed to support the user in context of the users tasks. 4. Apply sound functional partitioning to the software. 5. Automated build, test first and continuous integration. 6. Provide relevant training and end user documentation.

The key to these practices are found in an understanding of the concept of operation CONOPS, and more can be learnt from IEEE Std 1362-1998 IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document -Description

To be continued....

To be continued

By Einar Landre

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools