Download
1 / 17
180 likes | 454 Views
Systems Engineering of Software-Intensive Systems. What is Systems Engineering? - According to the International Council on Systems Engineering.
E N D
What is Systems Engineering?- According to the International Council on Systems Engineering • Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: • Operations • Performance • Test • Manufacturing • Cost and Schedule • Training and Support • Disposal
What is Systems Engineering? (Cont’d)- According to the International Council on Systems Engineering • Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.
Principles of Systems Engineering • Know the problem, know the customer, and know the consumer. • Use effectiveness criteria based on needs to make the system decisions. • Establish and manage requirements. • Identify and assess alternatives so as to converge on a solution. • Verify and validate requirements and solution performance. • Maintain the integrity of the system. • Use an articulated and documented process. • Manage against a plan.
The Decomposition of Complex Systems • The system is successively refined until: • The distribution and partitioning of functionality are optimized to achieve the overall functionality of the system with minimal costs and maximum flexibility. • Each subsystem can be defined, designed, and built by a small, or at least modest-sized team.
The Decomposition of Complex Systems (Cont’d) • Each subsystem can be manufactured within the physical constraints and technologies of the available manufacturing processes. • Each subsystem can be reliably tested as a subsystem, subject to the availability of suitable fixtures and harnesses that simulate the interfaces to the other subsystems. • Appropriate deference is given to the physical domain – the size, weight, location, and distribution of the subsystems – that has been optimized in the overall context.
Derived Requirements • Subsystem requirements are those that must be imposed on the subsystems themselves but do not necessarily provide a direct benefit to the end user. • Interface requirements may arise when the subsystems need to communicate with one another to accomplish an overall result. They will need to share data, power, or a useful computing algorithm.
Changes in Systems Engineering • Software, not hardware, determines the ultimate functionality of the system and the success of the system in the end user’s hands and in the marketplace. • Software, not hardware, consumes the majority of the costs of research and systems development. • Software, not hardware, is on the critical path and, therefore, ultimately determines when the system goes to the marketplace.
Changes in Systems Engineering (Cont’d) • Software, not hardware, absorbs most of the changes that occur during development and can even evolve to meet the changing needs of a system deployed in the field. • The cost of software development and maintenance, taken in the aggregate and amortized over the full life of the produce, has become material to, or in some cases equal to or greater than, the contribution of hardware costs of goods sold to that holy grail of systems manufacturers: total manufacturing costs.
Systems Engineering Recommendations • Develop, understand, and maintain the high-level requirements and use cases that span the subsystems and that describe the overall system functionality. • Do the best possible job of partitioning and isolating functionality within subsystems. • If possible, develop software as a whole, not as several individual pieces, one for each subsystem
Systems Engineering Recommendations (Cont’d) • When coding the interfaces, use common code on both sides of the interface. • Define interface specifications that can do more than would be necessary to simply meet the known conditions • See whether you can find one of those “graybeards” to help you with your systems engineering
Case Study: Systems Engineering for HOLIS • HOLIS stands for Home Lighting automation System. • This is a proposed new product for a company called Lumenations in the professional theater marketplace. • The goal is to acquire new customers by offering a new product.
HOLIS – Well-Understood User Needs • HOLIS will need to support “soft” key switches – individually programmable key switches used to activate the lighting features in various rooms. • Homeowners have requested a means to program HOLIS from a remote center so they can simply call in their needs and not be bothered with “programming” HOLIS at all.
HOLIS Case Study – Well -Understood User Needs (Cont’d) • Other prospective buyers have requested that HOLIS be programmable from their home PCs and that they be provided with the ability to do all the installation, programming, and maintenance themselves. • Still others have requested that the system provide a simple, push-button, control panel-type interface they can use to change HOLIS programming, vacation settings, and so on, without having to use a PC. • HOLIS needs to provide an emergency-contact system of some kind.
