Entries Tagged as 'Architecture '

A Field Study of Technical Debt

Architecture , Technical Debt No Comments »

By Neil Ernst
Member of the Technical Staff
Software Solutions Division

Neil ErnstIn their haste to deliver software capabilities, developers sometimes engage in less-than-optimal coding practices. If not addressed, these shortcuts can ultimately yield unexpected rework costs that offset the benefits of rapid delivery. Technical debt conceptualizes the tradeoff between the short-term benefits of rapid delivery and long-term value. Taking shortcuts to expedite the delivery of features in the short term incurs technical debt, analogous to financial debt, that must be paid off later to optimize long-term success. Managing technical debt is an increasingly critical aspect of producing cost-effective, timely, and high-quality software products, especially in projects that apply agile methods. A delicate balance is needed between the desire to release new software features rapidly to satisfy users and the desire to practice sound software engineering that reduces rework. Too often, however, technical debt focuses on coding issues when a broader perspective—one that incorporates software architectural concerns—is needed. This blog post, the first in a series, highlights the findings of a recent field study to assess the state of the practice and current thinking regarding technical debt and guide the development of a technical debt timeline.

Read more...

The SPRUCE Series: 8 Recommended Practices in the Software-Development of Safety-Critical Systems

Architecture , SEI/SPRUCE Series No Comments »

By Kevin Fall
Deputy Director, Research, and CTO
SEI

Kevin FallThis is the second installment of two blog posts highlighting recommended practices for developing safety-critical systems that was originally published on the Cyber Security & Information Systems Information Analysis Center (CSIAC) website. The first post in the series by Peter Feiler, Julien Delange, and Charles Weinstock explored challenges to developing safety critical systems and presented the first three practices:

  • Use quality attribute scenarios and mission-tread analyses to identify safety-critical requirements.
  • Specify safety-critical requirements, and prioritize them.
  • Conduct hazard and static analyses to guide architectural and design decisions.

This post presents the remaining five best technical best practices.

Read more...

The SPRUCE Series: Recommended Practices in the Software Development of Safety-Critical Systems

Architecture , Mission Thread Workshop , SEI/SPRUCE Series No Comments »

By Kevin Fall 
Deputy Director, Research, and CTO
SEI

Kevin FallSoftware and acquisition professionals often have questions about recommended practices related to modern software development methods, techniques, and tools, such as how to apply agile methods in government acquisition frameworks,systematic verification and validation of safety-critical systems, and operational risk management.  In the Department of Defense (DoD), these techniques are just a few of the options available to face the myriad challenges in producing large, secure software-reliant systems on schedule and within budget.

In an effort to offer our assessment of recommended techniques in these areas, SEI built upon an existing collaborative online environment known as SPRUCE (Systems and Software Producibility Collaboration Environment), hosted on the Cyber Security & Information Systems Information Analysis Center (CSIAC)website. From June 2013 to June 2014, the SEI assembled guidance on a variety of topics based on relevance, maturity of the practices described, and the timeliness with respect to current events.  For example, shortly after the Target security breach of late 2013, we selected Managing Operational Resilience as a topic.

Ultimately, SEI curated recommended practices on five software topics: Agile at ScaleSafety-Critical SystemsMonitoring Software-Intensive System Acquisition ProgramsManaging Intellectual Property in the Acquisition of Software-Intensive Systems, and Managing Operational Resilience. In addition to a recently published paper on SEI efforts and individual posts on the SPRUCE site, these recommended practices will be published in a series of posts on the SEI blog.  This post, the first in a series by Peter Feiler, Julien Delange, and Charles Weinstock, presents the challenges in developing systems for safety-critical systems and then introduces the first three technical best practices for the software development of safety-critical systems. The second post in the series will present the remaining five practices.

Read more...

AADL Code Generation for Avionics Systems

Architecture , Architecture Analysis & Design Language (AADL) No Comments »

By Julien Delange
Member of the Technical Staff
Software Solutions Division

Julien DelangeUsing the Architecture Analysis & Design Language (AADL) modeling notation early in the development process not only helps the development team detect design errors before implementation, but also supports implementation efforts and produces high-quality code. Our recent blog posts and webinar have shown how AADL can identify potential design errors and help avoid propagating them through the development process, where remediation can require massive re-engineering, delay the schedule, and increase costs. Verified specifications, however, are still implemented manually, which can lead to additional errors and might break previously verified assumptions and requirements. For these reasons, code production should be automated to preserve system specifications throughout the development process. This blog post focuses on generating code from AADL and generating configuration files for ARINC653 systems, which are used by the avionics community.

Read more...

Model Driven Engineering: Automatic Code Generation and Beyond

Acquisition , Architecture , Architecture Analysis & Design Language (AADL) , Model-Based Engineering 2 Comments »

By John Klein,
Senior Member of the Technical Staff
Software Solutions Division

John KleinAcquisition executives in domains ranging from modernizing legacy business systems to developing real-time communications systems often face the following challenge:

Vendors claim that model-driven engineering (MDE) tools enable developers to generate software code automatically and achieve extremely high developer productivity.

Are these claims true? The simple answer might be, “Yes, the state of the practice can achieve productivity rates of thousands of function points and millions of lines of code per person-month using MDE tools for automatic code generation.” The complicated reality is that MDE consists of more than code generation tools; it is a software engineering approach that can impact the entire lifecycle from requirements gathering through sustainment. While one can make broad generalizations about these methods and tools, it is more useful to consider them in the context of a particular system acquisition. Aligning MDE methods and tool capabilities with the system acquisition strategy can improve system quality, reduce time to field, and reduce sustainment cost. On the other hand, when MDE methods and tools do not align with the acquisition strategy, using them can result in increased risk and cost in development and sustainment. This blog post highlights the application of MDE tools for automatic code generation (in the context of the full system lifecycle, from concept development through sustainment) and also provides a template that acquirers can use to collect information from MDE tool vendors.

Read more...