Security: Working remote?

You might want to take a look on the SANS tips for working remote. Quoting:

"The SANS mission is to empower current and future cybersecurity practitioners through training, education, and skills validation to create a safer global community. …We interrupt our regularly scheduled programing to address the impact that the coronavirus outbreak is having on our daily work life. Working from home may sound like a dream come true for many people, but if this is your first experience taking your workforce virtual, the transition will likely be a bit overwhelming at first. For those given the task of setting up a home office, what should you do first? What technology will you need? How will you stay connected to your co-workers? How will you balance your family and work life? How will I stay productive with the kids home all day?

Download our infographic to help you make the most of working remote here."

Source:

https://www.sans.org/blog/18-tips-to-help-you-make-the-best-of-working-remote/

SW Construction: Good code?

Principles, books, tools for productivity and metrics and more:
https://www.dotnetcurry.com/patterns-practices/1358/code-quality-tools

BOOK: Beautiful Code (Leading Programmers Explain How They Think)

Using a similar idea used for Clean Code, this book talks about... Beautiful Code. (PS. When will the Fluffy Code book come out?)

Beautiful code » nvie.com


Quoting (nvie.com):

""The book's concept is simple: each of the 33 chapters is written by a well-respected professional programmer who answers the question: "What is the most beautiful code you've ever seen?" after which they discuss elaborately why they think it's beautiful."


Quoting Amazon.com (this is the link to buy it):

"How do the experts solve difficult problems in software development? In this unique and insightful book, leading computer scientists offer case studies that reveal how they found unusual, carefully designed solutions to high-profile projects. You will be able to look over the shoulder of major coding and design experts to see problems through their eyes. This is not simply another design patterns book, or another software engineering treatise on the right and wrong way to do things. The authors think aloud as they work through their project's architecture, the tradeoffs made in its construction, and when it was important to break rules. Beautiful Code is an opportunity for master coders to tell their story. All author royalties will be donated to Amnesty International."

BOOK: Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series): Robert C. Martin: 9780134494166: Amazon.com: Books

Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series): Robert C. Martin: 9780134494166: Amazon.com: Books

Quoting:

"Practical Software Architecture Solutions from the Legendary Robert C. Martin (“Uncle Bob”)

By applying universal rules of software architecture, you can dramatically improve developer productivity throughout the life of any software system. Now, building upon the success of his best-selling books Clean Code and The Clean Coder, legendary software craftsman Robert C. Martin (“Uncle Bob”) reveals those rules and helps you apply them.

Martin’s Clean Architecture doesn’t merely present options. Drawing on over a half-century of experience in software environments of every imaginable type, Martin tells you what choices to make and why they are critical to your success. As you’ve come to expect from Uncle Bob, this book is packed with direct, no-nonsense solutions for the real challenges you’ll face—the ones that will make or break your projects.

• Learn what software architects need to achieve—and core disciplines and practices for achieving it
• Master essential software design principles for addressing function, component separation, and data management
• See how programming paradigms impose discipline by restricting what developers can do
• Understand what’s critically important and what’s merely a “detail”
• Implement optimal, high-level structures for web, database, thick-client, console, and embedded applications
• Define appropriate boundaries and layers, and organize components and services
• See why designs and architectures go wrong, and how to prevent (or fix) these failures

Clean Architecture is essential reading for every current or aspiring software architect, systems analyst, system designer, and software manager—and for every programmer who must execute someone else’s designs."

MAGAZINE: DNC magazine (PDF)

Freely downloadable twice per month (requires subscription):
http://www.dotnetcurry.com/magazine/

SW Testing: 64 Essential Test Metrics For Measuring Software Quality, Testing & More

Should you measure things while testing? Sure. In order to be able to manage the phase (and the resources available to execute it) it is mandatory... What should you measure? Here is an interesting article on the topic:

• 64 Essential Test Metrics For Measuring Software Quality, Testing & More!

Quoting:

"Software testing metrics are a way to measure and monitor your test activities. More importantly, they give insights into your team’s test progress, productivity, and the quality of the system under test. When we ask ourselves “What have we tested?”, metrics will give us better answers than just “we have tested it.” Different teams measure various aspects depending on what they want to track and control or improve.

A metric usually conveys a result or a prediction based on the combination of data.

Result Metrics:  metrics that are mostly an absolute measure of an activity/process completed.

Example: Time taken to run a set of test cases in a suite

Predictive Metrics:  metrics that are derivatives and act as early warning signs of an unfavorable result.

Example: Defects created vs. Resolved chart shows the rate of defect fixing.  This grabs the team’s attention if this rate is slower than the rate desired.

Are you using the right software test metrics? Get answers, best practices and strategies in our 14-page guide to improving your software quality through data and analytics.

Why Test Metrics? Why Should You Care?

The aim of collecting test metrics is to use the data for improving the test process, rather than to just show fancy reports. This includes finding tangible answers to the questions:

• How long will it take to test?
• How much money will it take to test?
• How bad are the bugs?
• How many bugs found were fixed? reopened? closed? deferred?
• How many bugs did the test team did not find?
• How much of the software was tested?
• Will testing be done on time? Can the software be shipped on time?
• How good were the tests? Are we using low-value test cases?
• What is the cost of testing?
• Was the test effort adequate? Could we have fit more testing in this release?

Good answers to these questions need measurement. This post includes 64 of the absolute, derivative, result, and predictive metrics that testers and QA managers use the most often.

The Fundamental Metrics 

As a tester, your road to metric creation has to start somewhere.  Fundamental QA metrics are a combination of absolute numbers that can then be used to produce derivative metrics.

Absolute Numbers:

• Total number of test cases
• Number of test cases passed
• Number of test cases failed
• Number of test cases blocked
• Number of defects found
• Number of defects accepted
• Number of defects rejected
• Number of defects deferred
• Number of critical defects
• Number of planned test hours
• Number of actual test hours
• Number of bugs found after shipping"

For the derivative and other type of metrics, follow the link above.

REUSE: The Elements of Reusable Code (Chris Wash)

An excellent (oldie but goldie) article summing up the elements of reusable code:
The Elements of Reusable Code

More from Chris Wash:
https://www.captechconsulting.com/search#q=Chris Wash

BOOK: C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (Herb Sutter, Andrei Alexandrescu)

Amazon.com: C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (9780321113580): Herb Sutter, Andrei Alexandrescu: Books

Quoting:
"Consistent, high-quality coding standards improve software quality, reduce time-to-market, promote teamwork, eliminate time wasted on inconsequential matters, and simplify maintenance. Now, two of the world's most respected C++ experts distill the rich collective experience of the global C++ community into a set of coding standards that every developer and development team can understand and use as a basis for their own coding standards.

The authors cover virtually every facet of C++ programming: design and coding style, functions, operators, class design, inheritance, construction/destruction, copying, assignment, namespaces, modules, templates, genericity, exceptions, STL containers and algorithms, and more. Each standard is described concisely, with practical examples. From type definition to error handling, this book presents C++ best practices, including some that have only recently been identified and standardized-techniques you may not know even if you've used C++ for years. Along the way, you'll find answers to questions like

• What's worth standardizing--and what isn't?
• What are the best ways to code for scalability?
• What are the elements of a rational error handling policy?
• How (and why) do you avoid unnecessary initialization, cyclic, and definitional dependencies?
• When (and how) should you use static and dynamic polymorphism together?
• How do you practice "safe" overriding?
• When should you provide a no-fail swap?
• Why and how should you prevent exceptions from propagating across module boundaries?
• Why shouldn't you write namespace declarations or directives in a header file?
• Why should you use STL vector and string instead of arrays?
• How do you choose the right STL search or sort algorithm?
• What rules should you follow to ensure type-safe code?
• Whether you're working alone or with others, C++ Coding Standards will help you write cleaner code--and write it faster, with fewer hassles and less frustration."

STANDARDS: Recommended approach to software development, revision 3 : Landis, Linda : Free Download & Streaming : Internet Archive

The NASA JPL recommended approach to SW development (PDF) is "oldie but goldie" and stated as consistent with NASA/GSFC standards:

Recommended approach to software development, revision 3 : Landis, Linda : Free Download & Streaming : Internet Archive

Quoting:
"Guidelines for an organized, disciplined approach to software development that is based on studies conducted by the Software Engineering Laboratory (SEL) since 1976 are presented.

It describes methods and practices for each phase of a software development life cycle that starts with requirements definition and ends with acceptance testing.

For each defined life cycle phase, guidelines for the development process and its management, and for the products produced and their reviews are presented.

Documentid 19930009672"

Into NASA coding philosophy

Some additional insights on NASA and the highly reliable code that it produces:
https://mystudentvoices.com/a-look-into-nasas-coding-philosophy-b747957c7f8a

Quoting:
"With some years of work there, I wish to provide a first-hand account on the philosophy that’s allowed the space agency to produce some of the world’s most reliable software, and I’ll frame their attitude towards programming with a set of four assumptions I think they make for programmers in the workforce (and which I have experienced directly.)"

SW Construction: Checkstyle in Eclipse

The short story

Checkstyle is a static analysis tool with an Eclipse Plugin (it also has a Maven plugin), that allows you to... check style. An excellent article describing how to install, configure for a project and run for reporting (things about style, duh) can be found here:

• http://www.vogella.com/tutorials/Checkstyle/article.html

The Long Story

... made short by Wikipedia: https://en.wikipedia.org/wiki/Checkstyle

Some modules are readily available, saving you lots of time configuring the tool:

"Checkstyle defines a set of available modules, each of which provides rules checking with a configurable level of strictness (mandatory, optional...). Each rule can raise notifications, warnings, and errors. For example, checkstyle can examine:

1. Javadoc comments for classes, attributes and methods;
2. Naming conventions of attributes and methods;
3. Limit of the number of function parameters, line lengths;
4. Presence of mandatory headers;
5. The use of packets imports, of classes, of scope modifiers and of instructions blocks;
6. The spaces between some characters;
7. The good practices of class construction;
8. Duplicated code sections;
9. Multiple complexity measurements, among which expressions." (Source: Wikipedia)

Similar tools

If you're into .Net, think FxCop: 

https://en.wikipedia.org/wiki/FxCop

SW Construction | SW Testing: best practices

Here are some interesting considerations (do you agree on all of them?) about coding AND testing, with additional links to books and/or articles every good boy (read: every engineer) should read:

https://opensource.com/article/17/5/30-best-practices-software-development-and-testing

BOOK: The Practice of Programming - B. Kernighan | Rob Pike

By no-one else than Mr. Kernighan (from the Kernighan & Ritchie book you might have heard of), "The Practice of Programming" is a 1999 book on best practices while programming and more:

FFR here is the Amazon link with additional information on the book: https://www.amazon.com/Practice-Programming-Addison-Wesley-Professional-Computing/dp/020161586X/ref=sr_1_1?s=books&ie=UTF8&qid=1479759220&sr=1-1&keywords=the+practice+of+programming

Quoting:
"With the same insight and authority that made their book The Unix Programming Environment a classic, Brian Kernighan and Rob Pike have written The Practice of Programming to help make individual programmers more effective and productive.

The practice of programming is more than just writing code. Programmers must also assess tradeoffs, choose among design alternatives, debug and test, improve performance, and maintain software written by themselves and others. At the same time, they must be concerned with issues like compatibility, robustness, and reliability, while meeting specifications.

The Practice of Programming covers all these topics, and more. This book is full of practical advice and real-world examples in C, C++, Java, and a variety of special-purpose languages. It includes chapters on:

• debugging: finding bugs quickly and methodically
• testing: guaranteeing that software works correctly and reliably
• performance: making programs faster and more compact
• portability: ensuring that programs run everywhere without change
• design: balancing goals and constraints to decide which algorithms and data structures are best
• interfaces: using abstraction and information hiding to control the interactions between components
• style: writing code that works well and is a pleasure to read
• notation: choosing languages and tools that let the machine do more of the work

Kernighan and Pike have distilled years of experience writing programs, teaching, and working with other programmers to create this book. Anyone who writes software will profit from the principles and guidance in The Practice of Programming ."

DIGEST: Additional Info on SW Design / Architecture - Further Reading

About SW Design / Architecture (and security as well as performance, quality attributes of architectures):

• The VAP info can be found online here (PDF). 

Security topic and the embedded link to the Check List repository:

1. http://silvaonsoftware.blogspot.pt/2016/05/sw-design-security-as-design-quality.html
2. http://silvaonsoftware.blogspot.pt/2016/07/resource-security-is-process.html
3. http://silvaonsoftware.blogspot.pt/2016/08/security-magic-quadrants-for-mss-remote.html
4. Slightly off-topic but equally interesting: http://silvaonsoftware.blogspot.pt/2016/11/security-industrial-control-systems.html

Additional info on Design Patterns, Code Smells, Refactoring (already shown but repeated here for reinforcement or whatever you would like me to call it): 

1. Design patterns: "The index" in Wikipedia is here. 
2. Several books to read, also called "bibles": The GOF book as well as Code Complete 2. 
3. Another interesting resource is sourcemaking.com (Design Patterns, Anti-Patterns and Refactoring / Code Smells).

Performance (but not only) topic:  

• Performance (and architecture that drives/enables this performance): http://www.javaperformancetuning.com/

DIGEST: Requirements Analysis - Further Reading

Additional info on Requirements Analysis (and SW Requirements):

1. The requirements analysis "film": http://silvaonsoftware.blogspot.pt/2016/05/process-software-requirements-team.html
2. To learn some specifics: See your QMS "requirements standard" (INTERNAL; includes best practices and conventions). 
3. Writing good requirements paper here (PDF)
4. Requirement types: http://silvaonsoftware.blogspot.pt/2016/11/requirements-requirements-types.html
5. For even further info: Read books on the subject and related subjects: Requirements analysis, requirements engineering, business process analysis (a broader topic), writing good requirements. "Google" and/or "Amazon" them. 

(@2016-11-23: Fixed link of Req. Std.; 2017-06-08: fixed link)

Requirements: Requirements Types (Functional, Non-Functional)

Requirement types are a useful categorization for your requirements catalog. There are several classifications and literature about the subject.
The following requirement types were identified according to European Space Agency (ESA) “Guide to the software requirements definition phase”.

FUNCTIONAL REQUIREMENTS

A function is a “defined objective or characteristic action of a system or component” and a functional
requirement “specifies a function that a system or system component must be able to perform”. Typically we will be describing functionality (features) with functional requirements at first. Then comes "the rest": Non-functional requirements.

NON-FUNCTIONAL REQUIREMENTS

• Performance Requirements specify numerical values for measurable variables used to define a function (e.g. rate, frequency, capacity, speed and accuracy). Performance requirements may be included in the quantitative statement of each function, or included as separate requirements.
• Interface Requirements specify hardware, software or database elements that the system, or system component, must interact or communicate with. Interface requirements should also be classified into “internal” and “external” interface requirements, depending upon whether or not the interface coincides with the system boundary.
• Operational Requirements specify how the system will run (i.e. when it is to be operated) and how it will communicate with human operators (e.g. screen and keyboards etc.). Operational requirements may describe physical aspects of the user interface. Descriptions of the dialogue, screen layouts, command language styles are all types of operational requirements.
• Resource Requirements specify the upper limits on physical resources such as processing power, main memory, disk space etc. They may describe any requirements that the development or operational environment place upon the software. A resource requirement should state the facts about the resources, and not constrain how they are deployed.
• Verification Requirements constrain the design of the product. They may do this by requiring features that facilitate verification of system functions or by saying how the product is to be verified.
• Documentation Requirements state project-specific requirements for documentation, in addition to those contained in Software Configuration Management Plan. The format and style of the Interface Control Documents may be described in the documentation requirements, for example. Documentation should be designed for the target readers (i.e. users and maintenance personnel).
• Security Requirements specify the requirements for securing the system against threats to confidentiality, integrity and availability. They should describe the level and frequency of access allowed to authorised users of the software. If prevention against unauthorised use is required, the type of unauthorised user should be described. The level of physical protection of the computer facilities may be stated (e.g. backups are to be kept in a fire-proof safe off-site).
• Portability Requirements specify how easy it should be to move the software from one environment to another. Possible computer and operating systems, other than those of the target system, should be stated.
• Quality Requirements specify the attributes of the software that make it fit for its purpose. The major quality attributes of reliability, maintainability and safety should always be stated separately. Where appropriate, software quality attributes should be specified in measurable terms (i.e. with the use of metrics).
• Reliability Requirements relate to the “the ability of a system or component to perform its required functions under stated conditions for a specified period of time”. The reliability metric, “Mean Time Between Failure” (MTBF), measures reliability according to this definition.
• Maintainability Requirements relate to the “the ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment”. All aspects of maintainability should be covered in the specification of the maintainability requirements, and should be specified, where appropriate, in quantitative terms.

Source: Requirements Standard (INTERNAL) and ESA.

SW Construction: Clean Code vs Dirty Code? Good Code vs. Bad Code?

- Discussing the sex of angels.
Could it be the answer to what the question "What is clean code"? Guess not.

The "Clean Code" book author and SW Engineering guru Robert C. Martin asked some other software well-known and deeply experienced programmers what they thought about it. Who are those people?

- Bjarne Stroustrup: inventor of C++ and author of The C++ Programming Language.
- Grady Booch: author of Object Oriented Analysis and Design with Applications.
- Dave Thomas: founder of OTI, godfather of the Eclipse strategy.
- Mike Feathers: author of Working Effectively with Legacy Code.
- Ron Jeffries: author of Extreme Programming Installed and Extreme Programming in C#.
- Ward Cunningham: inventor of Wiki, Fit, coinventor of  eXtreme Programming, Motive force behind Design Patterns, Smalltalk and OO thought Leader. The godfather of those who care about code.

If you don't know them [and are interested in building better/cleaner code] maybe it's time to start following them and/or reading to whatever books or initiatives they have been involved in (some of those are listed above).

If you want to know their answers and what the Robert C. Martin "school of thought" thinks about it (to the point of writing an entire +400 pg. book on the subject) maybe you should read the book (Amazon link here).

BOOK: Clean Code | Robert C. Martin

So, another good book on how to write good (clean) code to keep in mind is Robert C. Martin's "Clean Code: A Handbook of Agile Software Craftsmanship":

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Quoting:
"Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.

What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.

Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

Readers will come away from this book understanding
How to tell the difference between good and bad code
How to write good code and how to transform bad code into good code
How to create good names, good functions, good objects, and good classes
How to format code for maximum readability
How to implement complete error handling without obscuring code logic
How to unit test and practice test-driven development
This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code."

Table of Contents 

Clean code

Meaningful names

Functions

Comments

Formatting

Objects and data structures

Error handling

Boundaries

Unit tests

Classes

Systems

Emergence

Concurrency

Successive refinement

JUnit internals

Refactoring serialdate

Smells and heuristics

Appendix A: Concurrency II

Appendix B: Org.jfree.date.serialdate

Appendix C: Cross references of heuristics

Epilogue.