Process: SW Construction Process and its main work products

SW Construction Process:

While building your software (aligned with the gathered requirements - SRS - and the software design that your high-level architecture defines - SAS, and eventually the detailed design - DDS) several additional topics are relevant.

For instance:
- Shall the team code against any coding standard (is it a coding standard belonging to the project, to the company or is it external, e.g. imposed by a safety standard or by your contractor)?
- What kind of comments shall the team be producing, and what tags for doc extraction shall the team embed in comments (e.g. Javadoc)?
- Do we have a minimum % of comments to comply with?
- Shall the team also leave traceability hints in the source code (Class - Requirement ID, Class - Component ID, other)?
- What static analysis tool will it be used (and who is responsible to run it and analyze the reports)?
- What other static analysis measures shall the team abide for (cyclomatic complexity < X)?
- What integration tasks shall be configured in the CI server and under what well defined circumstances shall the build fail (e.g. shall it fail if 1 of the 10K unit tests fails or not)?
- What is the coverage goal for Unit Testing (if any - see the unit testing plan)?
- What is the coverage goal for Code Reviews (e.g. only certain well identified critical parts of the code shall be reviewed) and who is doing it? And so on.

While programming:
- Remember to keep on checking that "your code does not smell" and try not to follow the wrong guidelines and/or practices (e.g. "how to write unmaintainable code").
- And if the code "smells" (be it yours or from other programmer) you can always refactor it now or later on, "when the fire stops burning" - just make sure to take note of the need somewhere persistently (tip: "issue tracker").

The main work products and documents resulting after the phase where this process is being more heavily used are:
- The code (that could not be a deliverable - you could be delivering binaries only); includes unit test code;
- Updated end-user documentation: Manuals (administration, installation, user, etc.), online help.

Further Information:

Further information can be found in the following links in the DIGEST (some are INTERNAL):
http://silvaonsoftware.blogspot.com/2016/11/digest-sw-construction-further-reading_49.html

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 ."

BOOK: Forms that Work - Caroline Jarret | Gerry Gaffney

Designing web pages with usability in mind?
The book "Forms that Work - Designing Web Forms for Usability" by Caroline Jarret and Gerry Gaffney might help.

FFR: https://www.amazon.com/Forms-that-Work-Interactive-Technologies/dp/1558607102

Quoting:
"Forms are everywhere on the web – for registration and communicating, for commerce and government. Good forms make for happier customers, better data, and reduced support costs. Bad forms fill your organization’s databases with inaccuracies and duplicates and can cause loss of potential consumers.

Designing good forms is trickier than people think. Jarrett and Gaffney come to the rescue with Designing Forms that Work, clearly explaining exactly how to design great forms for the web. Liberally illustrated with full-color examples, it guides readers on how to define requirements, how to write questions that users will understand and want to answer, and how to deal with instructions, progress indicators and errors.

• Provides proven and practical advice that will help you avoid pitfalls, and produce forms that are aesthetically pleasing, efficient and cost-effective.
• Features invaluable design methods, tips, and tricks to help ensure accurate data and satisfied customers.
• Includes dozens of examples -- from nitty-gritty details (label alignment, mandatory fields) to visual designs (creating good grids, use of color).
• Foreword by Steve Krug, author of the best selling Don't Make Me Think!"

Tools: Code Reviews and Support tools

Why (NOT) Code Reviews? 

Code reviews is not the most beloved verification method for a developer (in the end of the day it makes you proof-read others code, and everyone knows that all code other than yours is not good enough - #irony). But remember that Code Reviews are one of the most cost-effective verification methods available: Fixing a bug in software while developing it is way much cheaper than fixing it after the formal testing phases begin (several studies on the subject can be found - just "google" for it).

Also, things that we should bear in mind before we start complaining about having to do code reviews are:

• There are things that are much easier to verify looking at the code directly (e.g. correct use of RDBMS transactions) than by integration / system testing.  "White box" rules here and saves us hours (as a team - because on some cases we are saving testers' time).
• For some critical parts of your code it might be a good idea to have them being checked (read: code reviewed) prior to any deployment to production, e.g., code involved in authentication, authorization, money transfers, etc..  

Code Reviews in your QMS/SDP

Your QMS/SDP might have a Verification Process defining a code review procedure on how to conduct code reviews (see "Further Reading"). And how metrics related to code reviews are to be collected (and when, and by whom). Examples are: code review speed, preferably per technology; number of defects detected, number of defects fixed, defect fix cost - e.g. in minutes, etc.

And What About Supporting Tools?

So in order to "reap the benefits" (read: improve SW Quality and save money), give the developer teams a help by supporting the procedure with tools. For instance: Crucible (a plugin to Atlassian JIRA). Or any other. Anything other than making people use printed code and / or word processor annotated documents.

Further Reading

Examples (permissions could apply; INTERNAL):

• Example of a QMS Verification Process (Supporting Processes): https://quality.critical.pt/QMS%20PT/SUP-support/SUP-03-verification/CSW-QMS-2002-PCS-0354-verification.pdf#search=crucible%20guidebook
• Example of Code Review Support Tool Guidebook: https://quality.critical.pt/QMS%20PT/SUP-support/SUP-03-verification/CSW-QMS-2002-PCS-0354-verification.pdf#search=crucible%20guidebook
• Example of a code review under Crucible: https://crucible.critical.pt/cru/ATG-5#CFR-11408

DIGEST: SW Construction - Further Reading

Additional Resources for SW Construction:

While building your software (aligned with the gathered requirements - SRS - and the software design that your high-level architecture defines - SAS) several additional topics are relevant. For instance: Coding standards to comply with (if any); comments to create and % of comments and eventual traceability to requirements IDs / component ID there left; static analysis to perform (and extracted KPIs to comply with - if any); continuous integration server and tasks to use; verification measures such as unit tests, code reviews. For more generic information on these topics see here.
   
For further detailed information please see the following links (some are INTERNAL).

Static Analysis: 

1. http://silvaonsoftware.blogspot.pt/2016/05/tools-source-monitor-static-analysis.html
2. http://silvaonsoftware.blogspot.pt/2016/05/tools-static-analysis-tools-listing.html
3. http://silvaonsoftware.blogspot.pt/2016/10/sw-construction-static-analysis-tools.html

Code Reviews: 

1. The QMS context (INTERNAL): Review Procedure here; Crucible Tool GBK here; CheckStyle (Java) tool GBK here.
2. Code Reviews example - Crucible (Plugin to JIRA; INTERNAL): https://crucible.critical.pt/cru/ATG-5#CFR-11408

Continuous Integration (CI):

1. About CI, a list of several servers available can be seen here: https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
2. Example - Jenkins (INTERNAL): http://jenkins.critical.pt/computer/(master)/ (INTERNAL; Teamcity could also be in use for some projects).

Unit Testing: 

1. Think "developer tests" (and see Module 9 for now; again, INTERNAL)

Further reading - Coding Standards: 

Each company might have internally defined coding standards. Or it could be using external standards (e.g. HP, NASA, ESA, etc.). Google for "C Coding Standard" and see what it is meant by coding standards here: For instance this is 1994 NASA-SEL's style guide for C (PDF).

Further reading - BOOKS: 

There are lots of books on SW Engineering that focus on best practices for coding activities, with the objective of writing clearer code, easier to understand and maintain, easier to reuse, etc. 

Two must read examples might include: 

• Clean Code - Robert C. Martin, 
• Code Complete 2 - Steve McConnell

Many more books have full chapters on writing "good" code. 

Again, "Google" and/or "Amazon" for it.

Happy readings!

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)

TOOLS. Ditto clipboard manager (productivity tools; multi-PC)

Yest another free clipboard manager (see the ARS Clip link here)?
http://ditto-cp.sourceforge.net/

Quoting:

Ditto is an extension to the standard windows clipboard. It saves each item placed on the clipboard allowing you access to any of those items at a later time. Ditto allows you to save any type of information that can be put on the clipboard, text, images, html, custom formats, ...

Interesting features:

• Keep multiple computer's clipboards in sync (encrypted)
• It has a portable installer.

TBC: how does it stack against ARS Clip?

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.

DIGEST: And the fresh LAST links are...

And the last fresh links are indeed these ones:

The productivity Dept. (send me your suggestions, please): 

• http://silvaonsoftware.blogspot.pt/2016/11/tools-newfilego-productivity-tools-file.html
• Search for TOOLS, Productivity here around. And remember to send me info on your suggestions. 

Additional info on SW Requirements / Requirements Analysis:

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

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, 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/

Additional resources for SW construction:

1. Static Analysis: 
2. http://silvaonsoftware.blogspot.pt/2016/05/tools-source-monitor-static-analysis.html
3. http://silvaonsoftware.blogspot.pt/2016/05/tools-static-analysis-tools-listing.html
4. http://silvaonsoftware.blogspot.pt/2016/10/sw-construction-static-analysis-tools.html

Additional resources for SW Testing:

• http://silvaonsoftware.blogspot.pt/2016/11/sw-testing-list-of-105-software-testing.html

The Agile Dept.: 
Agile additional info including the Agile state of scrum report, info on Product vision statements rationale and examples, and additional tools as well as books. You will not die without a pile of stuff to read if you follow these final links:

1. Digest 1: http://silvaonsoftware.blogspot.pt/2016/09/starting-learning-agile.html
2. Digest 2: http://silvaonsoftware.blogspot.pt/2016/07/index-agilescrum-index-of-useful-links.html
3. Digest 3 (ufff): http://silvaonsoftware.blogspot.pt/2016/10/digest-agilescrum-links.html
4. BOOK http://silvaonsoftware.blogspot.pt/2016/08/mr-scrum-wrote-yet-another-book-scrum.html
5. The Product Vision "art": http://silvaonsoftware.blogspot.pt/2016/06/about-product-vision.html

And so on. So they say. Happy reading!

(@2017-06-06: fixed req.std.url)

SW Testing: List of 105 Software Testing Tools to Meet Your Testing Objectives - DZone Web Dev

One huge list of software testing (but not only) related tools, FFR:

List of 105 Software Testing Tools to Meet Your Testing Objectives - DZone Web Dev

Security: Industrial Control Systems (2016, PDF, Report)

Interesting report on the security of Industrial Control Systems (ICS), FFR:

Overload: Critical Lessons from 15 Years of ICS Vulnerabilities

2016 Industrial Control Systems (ICS) Vulnerability Trend Report

ics-vulnerability-trend-report-final.pdf

TOOLS: NewFileGo (productivity tools - File watcher task runner)

From the same supplier of ARS Clip (Clipboard Manager), the NewFileGo is another important productivity enhancer, allowing you to perform a task every time a file appears on a certain location.
For repetitive tasks it's the dream of everyone.

NewFileGo can be downloaded here:
http://www.joejoesoft.com/vcms/170/

FFR

TOOLS: ARS Clip cliboard manager (productivity tools)

ARS clip is THE free, open source (mainly windows-based) clipboard manager: http://www.joejoesoft.com/vcms/97/

Quoting:

ArsClip is a freeware "clipboard manager" utility. ArsClip monitors the clipboard and keeps track of the entries. Pasting is done by using a triggered popup window. This window can be triggered by a hotkey, holding right-click, a special trigger window, and other methods.

ArsClip used to be barebones, but I think I can safely say that it has become a nicely featured and highly configurable program, due to user feedback. The program now specializes in copy-and-paste automation tasks.

Delphi XE2 source code included

Features

- Permanent Clips/Macros for copying and pasting automation 

- Picture, RichText, File Copy, Unicode, HTML support

- Highly configurable

- Win7 Jumplist support

- Optional Clipboard Bar -- clipboard viewer

- Optional Global Clipboard to shares clips with other Windows and Android devices 

Requirements

This program requires no installation, but an optional setup program is included. Supported on Windows XP through Windows 10.

Interesting features include:
- Shortcut to recent items as a context menu (Ctrl+Shift+Z)
- Permanent items
- Persistence between restarts
- Stripped down format paste (Ctrl+Shift+V)
- The global shared clipboard (not yet tested by me)

Cons:
- Some minor issues: Slight instability (Windows 8), initial error setting global keyboard hook and some minor problems with OneNote (copied values are always pasted as image in certain apps).

PS. Also from the same supplier, make sure to check a very interesting tool for automating file-based tasks. If you like it, think about making a donation.

TBC: How does is stack against Ditto?

About long position / titles: Monty Python - Cosmetic Surgery sketch

Everytime I see a long job description like "Senior Security and Software Product Assurance Engineer", I reckon the Monty Python: Cosmetic Surgery sketch:

Quoting:
"(A man sitting behind a desk in a Harley Street consulting room. Close-up of the name plate on desk in front of him. Although the camera does not reveal this for a moment, this name plate, about two inches high, continues all along the desk, off the side of it at the same height and halfway round the room. We start to track along this name plate on which is written:

'Professor Sir Adrian Furrows F.R.S. F.R.C.S. F.R.C.P. M.D.M.S. (Oxon), Mall Ph.D., M. Se. (Cantab), Ph.D. (Syd), ER.G.S., F.R.C.O.G., F. FM.R.C.S., M.S. (Birm), M.S. (Liv), M.S. (Guadalahara), M.S. (Karach), M.S. (Edin), B.A. (Chic), B. Litt. (Phil), D. Litt (Phil), D. Litt (Arthur and Lucy), D. Litt (Ottawa), D. Litt (All other places in Canada except Medicine Hat, B. Sc. 9 Brussels, Liege, Antwerp, Asse, (and Cromer) '.

There is a knock on the door.)"

And this is the video (worthwhile seeing because the title won't fit in the room, so it "curves"):




Do you see what I mean?

TOOLS: The #StartupStack

Interesting trend and article on the startup stack [software-related tools], i.e. the number of common tools that modern startups use to support them on the most common tasks (like: billing, electronic payments, managing technical work, hiring, etc.).
Modern startups now have these tools for a fraction of the cost it used to cost some years ago...

Details on the Startup Stack:

• The #StartupStack (You'll need an account on SlideShare);
• And a related article: https://www.techgig.com/tech-news/editors-pick/tools-that-help-startups-scale-effectively-74706.

Happy readings! 

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).

TOOLS: SQL Clients AKA DB Tools

A SQL client is, as the name indicates, a client for a SQL Relational Database Management System (RDBMS). It can help you manage (create, read, modify/update, delete) DBs.
Some kind of administration tool is available with each RDBMS (you could have it installed on your computer or only on the server). But sometimes you'll have productivity gains if you use a multi-DB client because using the same SW user interface you will be managing several different DB engines / instances.

Examples of DB Tools include: Aqua Data Studio (Windows, proprietary - this one scripts data into DML SQL statements), Squirrel SQL Client (open source, java-based).

A comparison of DB tools can be found - where else? - in Wikipedia so choose one according to your requirements (and that might be shaped by your budget): 
https://en.wikipedia.org/wiki/Comparison_of_database_tools


For SQL Server, as per 2016-11: 
SQL Server Management Studio (SSMS)
https://msdn.microsoft.com/en-us/library/mt238290.aspx 
SQL Server Management Studio Express

https://technet.microsoft.com/en-us/library/ms365247(v=sql.105).aspx
And a related download - SQL Server 2016 Express (the free DB engine):
https://www.microsoft.com/en-us/download/details.aspx?id=52679


(Updates: @2016-11-08: MS SQL Server example links)

Modelling: EA initial management tasks

Some common management tasks for EA (to be performed by the EA UML repository manager, which could be the Technical Manager of your project) include:

Activate Security - Turn on the option that allows you to define who alters what part of the model and who does not (lock, unlock):
http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/projects_and_teams/usersecurity.html

Managing Users - Create profiles, users belonging to profiles and defining permissions for those:
http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/projects_and_teams/managingusers.html

Import Users from Active Directory - Integrating existing (e.g. domain) users into EA 
http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/projects_and_teams/import_user_ids_from_active_di.html

Initial EA Scripts - The DB schema that has to be loaded into the SQL DB initially: 
http://silvaonsoftware.blogspot.pt/2016/10/ea-initial-scripts.html


(@2017-06-23: Minor rephrases)

RESOURCE: "How To Write Unmaintainable Code" (PDF)

Do you like learning while laughing? If so you'll like to read "How To Write Unmaintainable Code". Remember that this is irony and that you'll earn enemies for life if you follow this through.

• PDF: https://www.se.rit.edu/~tabeec/RIT_441/Resources_files/How%20To%20Write%20Unmaintainable%20Code.pdf

• https://github.com/Droogans/unmaintainable-code

Stop and smell the... Code

Code Smells? Sometimes the code smells. So should we stop and smell the roses, or shall it be the code?

Quoting Martin Fowler:
"One of the nice things about smells is that it's easy for inexperienced people to spot them, even if they don't know enough to evaluate if there's a real problem or to correct them. I've heard of lead developers who will pick a "smell of the week" and ask people to look for the smell and bring it up with the senior members of the team. Doing it one smell at a time is a good way of gradually teaching people on the team to be better programmers." (Source: http://martinfowler.com/bliki/CodeSmell.html)

More info:
- https://en.wikipedia.org/wiki/Code_smell
- http://mikamantyla.eu/BadCodeSmellsTaxonomy.html
- https://blog.codinghorror.com/code-smells/

A good reference resource (and a company providing consulting services) here: https://sourcemaking.com/refactoring/smells