Mostrar mensagens com a etiqueta HOW-TO. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta HOW-TO. Mostrar todas as mensagens

domingo, 31 de dezembro de 2017

segunda-feira, 6 de novembro de 2017

Open Source: What kind of license to choose?

Interesting article on what kind of open source license to choose if you are to be the project maintainer:
https://01.org/blogs/jc415/2017/open-source-hacks-one-question-interviews-open-source-experts-licenses?sf148133548=1

Quoting:
“Which open source software license should I use for my project?”

I get asked that a lot. Or this variation, “What are your preferred open source licenses?” My answer: It depends.

I’m not trying to be flip; really, IT DEPENDS! No single open source license is appropriate for every use case or objective. And I have no “preferred” open source licenses—sure, there are some I find myself using or recommending more frequently, but as long as it has been approved as an open source license by the Open Source Initiative (OSI) or a free license by the Free Software Foundation (FSF), there is no license that I *wouldn’t* use, given the right scenario.

The choice comes down to what is most appropriate for a particular situation. How do you determine which license(s) might be appropriate for a given project? There are multiple factors to weigh.

If you are contributing to an existing project, the community expects you will make contributions under the existing project license, or a compatible license—the important thing is to understand and follow that community’s norms.

A project maintainer might reject contributions made under any license other than the one they’ve specified, even if from a legal and practical perspective the licenses have no incompatibilities. “Know your audience” and “go with the flow” are two maxims to keep in mind when you’re making upstream contributions.

What license to choose becomes more interesting when the project is your own. Assuming you have a choice (you haven’t used or incorporated any code licensed under terms that require the same license for derivative work), think about what you want recipients to be able to do (or not do) with your code.
(...)
The “right” open source license for your project will be the one that has terms that support your objectives, is compatible with other licenses in the relevant ecosystem, and is acceptable to your users.

Getting that equation right doesn’t guarantee your project success, of course, but getting it wrong is almost certain to ensure failure. 

One of the best ways to learn about open source licensing is to keep up to date with discussions in the open source legal and licensing community, either by joining a mailing list or browsing a mailing list’s archives (...)"

Examples of those discussion lists are in the article.

sexta-feira, 23 de junho de 2017

DIGEST: Modelling Tools tasks and Sparx Systems EA Documentation (UML Modelling Tool)

And the proper freshly linked links are indeed these ones:

  • Modelling tasks (what do I need to be able to do to be a modeller?): http://silvaonsoftware.blogspot.pt/2016/07/tools-modelling-tools-hot-topics.html
Is this enough?

segunda-feira, 24 de abril de 2017

Review Procedure: Document reviews for dummies?

You do review documents before delivering/publishing do you?
How do you review documents (hands-on)?
And what do you do when the documents you receive are not in the more commonly editable formats? Or when you do not have a license of Microsoft Office / Microsoft Office 365?
So many questions, so many answers...

Note: Some of the considerations below assume you are using an Office Suite (that supports tracked changes and peer review comments).

Review roles

There should be a moderator for the review (the person that should make sure everyone reviews things in time and that makes sure a reviewed artifact comes out of the peer review activity). This could be the author, or not. All other involved are peer reviewers.

Note: Some process definitions can differentiate the moderator from the author roles. For larger teams, it could make sense. For smaller teams and / or more informal organizations, the author could work as moderator.

Review Types

There are several types of (document peer) reviews. Think: Commentary, Walk-through, Full-reading (run from those ones!). We are talking mainly of the Commentary ones here.

How do you peer review (The Process)? 

Ideally you (as a moderator for the review) should ask for peer reviewers to edit inline trivial errors (such as typos); and comment the document with whatever needs commenting (a comment is a sentence regarding the selected text the comment is about). Comments should be done "near" the paragraph / section they are related to.
The document could be reviewed simultaneously but it will be better (e.g. avoiding duplicated comments) to be circulated between all review members.
Circulation could be made by e-mail, or using the DMS and / or VCS: I will make my review and I will commit the version with my comments to the VCS (while warning the next person - or the whole review team - that the comment is free for the next reviewer).

This really depends on what your review process / procedure states in your QMS.

If the review team is not fully inside the subject of the the document, and/or the objective of the peer review, it might be a good idea for you to do a presentation of the document being reviewed (a meeting where the document and the objectives is presented; eventually the check-lists to use as input for the review could also be presented; and the schedules for the review are emphasized: "Do this for tomorrow, or else..."). In this meeting you could also explain how the review will be done (in sequence, all at the same time, using what tools for commenting, ...).

In the end of the rework (rework is made based on the peer review comments that are approved for implementation) the moderator could have the power to ask for a re-review. Mainly it will be a good idea if the rework that has been done was profound and if you feel that a new review (delta, or full) is needed to ensure the final document quality. Look at the review process / procedure in your company for rules on re-reviews.

Sometimes it will be mandatory for the review organizer to extract (or make a tool extract) the review metrics. That could include, #of comments, how many of them were acknowledged (and implemented), how many were dismissed, etc. A metrics repository could be fed with this (important performance) information. Ask about that part also (company dependent).

With what tools (The Supporting Tools)? 

- If you are producing the document internally, deliver it internally for peer review in an editable format. If everyone has the app to edit it (and that app supports comments).
- If someone does not have a license of Microsoft Office, try to see if free Office Suites are suitable for your document (some Office Suites will "damage" more complex documents; think: Open Office, Libre Office, ...). If so, recommend installation of those.
- "Google docs" allows you opening and commenting (MS Office) documents. So it could be an option. Just test it with the concrete document you need to review.

If you only have a PDF and you want to peer review it you could:
- Try to create an editable document from the PDF (several utilities can be found - google is your friend, but do test the conversion since more complex docs could not be well extracted/converted).
- Try to comment right away the PDF: https://www.adobe.com/content/dam/Adobe/en/feature-details/acrobatpro/pdfs/adding-comments-to-a-pdf-document.pdf

Merging Comments (If possible, No)? 

In the end, if you do a sequential comment workflow (which is recommended and will dispense you from having to merge all peer reviewers comments into a single document) the document owner (the one responsible to process and close all comments provided) will receive a single file, that went through all peer reviewers to process.

If you have several documents with comments from several reviewers, do not dispair. Remember that MS Word has that wonderful feature to merge 2 versions of the same document (try to save one above the other and MS Word will offer to Merge contents). A tracked changed version (with all comments merged also) can be produced in this way.

Easy ain't it? :)

Note: If you opt to use an Office Suite like google docs (of Office365) that allow concurrent edits by several users at the same time (without frequent unsolvable merge conflicts that tear your hair apart), the merge part is not needed, of course.

Recap 

Read the guidelines to peer review artifacts in your QMS. Know if there are check lists associated to check against, during the review. Know how to edit inline and comment a paragraph, Know how to circulate the document between the team. And be a good boy: do review technically and formally the stuff. Do not just point formatting and English issues (but do report those also).

Further Reading (The Process stuff): For further info, look for your company's SUP03 - Verification Process and the Review Procedure documents (or equivalent), that shall detail the above considerations. Mine's are here: https://goo.gl/4EKKec (INTERNAL resource).


History:
@2017-04-26: Added INTERNAL QMS links; added Google Docs note; updated tags.



sexta-feira, 4 de novembro de 2016

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)

quinta-feira, 13 de outubro de 2016

INDEX: About Project Plans - The Hitchhiker's Guide to the Galaxy (of QMS / SDP Project Plans)

The Short Story


Plans, plans, plans… 

Q: What kind of initial QMS / SDP-related documentation should it be created at project start (also called Kick-off)?
A: "Some" plans. 

Plans, allow us to plan (which by the way everyone should do) and after approval, allow us to monitor and control the project execution against those same plans. PMs are responsible to approve them even though sometimes they will delegate their creation and maintenance to the TM and/or the most experienced SPAE (Software Product Assurance Engineer) in the team.

What plans are we talking about? The project Plan (and the related detailed plan), the QAP, the CMP, …
You'll hear of even more plans (depending on the standards we are being compliant with). Mainly it has to do with the fact that for some standards we have to plan even further (and deliver those plans so that the contractor knows how we plan - and later on, double check the execution of tasks in the plan, through the inspection of produced evidences). Examples of such standards are the ESA standards (ECSS, for space development), DO-178 (for airborne systems), CENELEC 50126 (for railway applications), and so on. 
Examples of those include:
  • Software Verification Plan (SVP)
  • Software Validation Plan or (the mix of both):
  • Software Verification and Validation Plan (SVVP)
Another PA-related artifact is the PA Log book (sometimes called SPAE Logbook). 
And Agile/Scrum projects use yet another log book: The sprint retro logbook.

What is the purpose of those main SDP plans? 
What are their goals , when are they created, when should they be updated?

Before starting, one important thing to remember is the fact that there should be a public list of QMS Process Owners (PO) and some backups for that role (called Process Representatives - PRs).

The (Very) Long Story


In order to know more about each artifact, the following "sequence of steps" is recommended:
  • Read one entry in the final table below; from there you get to know the QMS process to where it belongs;
  • Open the QMS Process and browse (at least) the main activities there described (typically there is only a single table/slide per process activity).
  • The plan/artifact in question should be an artifact of this process you've just opened and if not, it is because it probably is just updated by this process. It could be an AD of the process or not - you can check it at the end of the process document.
  • Open the template for the artifact (or the provided samples - if any), and scan read its contents. If some concrete examples are available also scan them. Google can also find them.
  • Read the associated guidebooks (or the instruction sheets in the spreadsheet files).
  • During this process, remember to list your questions / open issues so that in the end you can always go to the PO (or as a last resource the QD) and solve them.
  • The one million dollar final questions to answer are:
    • Am I able to create these documents from scratch?
    • Am I able to understand them and extract the needed information for the activities/tasks I will be performing for the project?
    • Do I know who to talk to in case of doubt (who is the doc owner? Who are the PO/PRs)?

INDEX: Plan / Artifact
Templates / Examples / Additional Relevant Docs
Templates
(Docs from MT)
<<master template -- Quality Assurance Plan.docx>>
<<master template -- Product Assurance Report.docx>>
<<master template -- Int. Configuration Management Plan.docx>>
<<master template -- Configuration Management Plan.docx>>

Templates
(Spreadsheets)
<<internal QAP pre-tailored -- CSW-QMS-2013-TPL-00997-rd-pre-tailored-qap.xltx>>
<<internal QAP -- PA Process -- CSW-QMS-2009-TPL-04681-quantitative-qap.xltx>>
<<CSW-QMS-2014-TPL-01088-sprint-retrospective-workbook.xltm>>
<<CSW-QMS-2007-TPL-0112-configuration-items-list.xltm>>
<<CSW-QMS-2006-TPL-1126-spae-log-book.xltm>>

GBKs
<<CSW-QMS-2014-GBK-01269-agile-guidebook.pdf>>
<<CSW-QMS-2012-GBK-04055-crucible-guidebook.pdf>>
<<CSW-QMS-2012-GBK-02170-research-development-projects-tailoring.pdf>>
<<CSW-QMS-2010-GBK-04838-review-report-macro.pdf>>
<<CSW-QMS-2009-GBK-04120-wise-project-module-guidebook.pdf>>
<<CSW-QMS-2009-GBK-03894-project-milestones-meetings.pdf>>
<<CSW-QMS-2009-GBK-03591-qap-how-to.pdf>>

Relevant Trainings
<<project-management-practices-at-csw-internal-training.pptx>>
<<CSW-QMS-2016-PRS-00605-QMSVerificationProcess2016DocumentandCodeR.pptx>>
<<CSW-2015-PRS-00614-managing-baselines-and-change-control-tracking.pptx>>
<<CSW-QMS-2015-TPL-00368-excel-project-tips-tricks.pdf>>




Artifact / Work Product (Plan)
Who is mostly involved
QMS Process / Doc. Level
Main Purpose
Artifact Doc Format / Tool
Generated by MT?
Example Doc. / Link
Associated Template and/or GBK / HOW-TO
More info (when to create, update and AOB)
AOB
Master Project Plan
PM
PM Process (MAN.1)
High-level plan (Gantt chart with the main WBS of the project (similar to the one produced for the estimation sum-up sheet if created during proposal elaboration);

Relevant topics and uses for this artifact include: high level view of ptoject activities (overall view); end project date determination;  resource balancing; critical path analysis; effort and cost estimation (use of PERT estimation techniques  -Best Case Scenario, Expected Case Sc., Worst Case Sc.)…
MS Project (.mpp, etc.)



For each project, the WISE export can be opened in MS Project: https://wise.critical.pt/wiseweb/projects/ExportProjectFile.action?id=7439
For MS Project planning tool info, tips and tricks, see training: https://my.critical.pt/humanresources/Documents/CSW-QMS-2015-TPL-00368-excel-project-tips-tricks.pdf
Should be always kept up to date (acc. To CRs/CCNs, approved changes to schedule, …); uploaded to "WISE Projects"; V1 ready at KOM (based on info from PRL, if existent)
Previously: There were ECS and ASD master plan templates as QMS artifacts.

A guide for the "WISE Project Module" (covering EVM indicators, managing baselines and more) can be found here:
Detailed Project Plan
Typically: PM/TM
PM Process (MAN.1)
Used for detailed planning (day to day tasks, concrete resource allocations, % progress…)
MS Project (.mpp)

Optional: Created if a finer planning and control is needed (by the TM): details the Master Plan (and could be used to report %s progress for each task and calculate overal % progress, etc.)
N/A
Updated weekly (with progress)

External QAP
SPAE (PM typically delegates)
Software Product Assurance Process (MAN.8)
A written statement on how we intend to perform QA activities (i.e. how will the QMS apply to the project). 
For instance: Describes the QA aspects of verification including
  • Review activities to be performed
  • Transition criteria for review activities

The external QAP is a doc; The internal QAP is a XLS (see entry in this table).
MS Word (Master template, template ID = TBD - empty at MT at the moment, reported PROCIMP-819);
Yes
See template TOC.
See template and "fill in the blanks";

Optional: If DL, it is created at KO; tailored with the QD (in case of doubt)
Note: This document could not be requested by the customer as deliverable (DL).
Internal QAP
SPAE
Software Product Assurance Process (MAN.8)
XLS that includes all process tailorings: e.g. Verification Process tailoring

Includes a record of all tailoring decisions e.g. How will verification be performed (e.g. will the project do code reviews?)? Validation? Reqs, Design and SW Construction?
Spreadsheet (see template ids at right)
No
See spreadhseet contents.
See XLS template:


Also see the QAP GBK (link above)
Same as Ext. QAP
Old Ids:
CSW-QMS-2003-TPL-2570 (EN),
CSW-QMS-2004-TPL-2755 (PT)
CMP (External Config. Mg. Plan)
Typically: CM (Project Role; PM assigns this role to a team member)
CM Process (SUP.2)
A written statement on how we intend to do  Config. Management (activities).
This document is optional but if done typically is to be delivered to the customer; this doc  consolidates info in a single document some information already stated in other internal docs such as the ICMP, QAP, CIL, …

MS Word (Master template, template ID = CSW-QMS-2004-TPL-0234)
Yes
See template contents; check list contents
See template(s) and "fill in the blanks";



Optional: If DL, it is created at KO and kept up-to-date during the project (CRs/CCNs could impact this DL);
Note: This document could not be requested by the customer as deliverable (DL).

Template Variants: External and Internal; pre-tailored for certain life cycles: See doc list.

EN
[CSW-QMS-2004-TPL-0234]
{CMP}
Configuration Management Plan (CMP)
EN
[CSW-QMS-2006-TPL-3196]
{CMP}
Internal CM Plan (ICMP)
EN
[CSW-QMS-2013-TPL-01989]
{CMP}
Internal Maintenance Pre-Tailored CM Plan (ICMP)
EN
[CSW-QMS-2013-TPL-00995]
{CMP}
Internal R&D Pre-Tailored CM Plan (ICMP)

Internal CMP (ICMP)
CM (project role)
CM Process
The ICMP is a simpler document (when compared to the CMP) that includes the CM process tailoring decisions (what activities in the CM process are to be performed and what are not and with what formality and frequence) and the CM strategies (such as check-up strategy, build, baseline, tagging and branching strategies); it specifies the conventioned text for the TAGs to be applied at certain moments to the Version Control System (VCS).
MS Word (Master template, template ID = CSW-QMS-2006-TPL-3196; pre-tailored templates: CSW-QMS-2013-TPL-01989 (Maintenance); CSW-QMS-2013-TPL-00995 (R&D)
)

Yes
See template TOC and pre-tailored templates.
See above

As seen above, there are 3 ICMP templates being generated by the MT.
CIL
Typically: CM (PM approves)
Verification Process
Contains the review strategy (usually internal). It list internal and external configuration items under configuration (built from the proposal and including CFIs received from the customer - be it software or hardware, external input docs, etc.) and for the internal, how we plan to do the reviews.
Excel Template: CSW-QMS-2007-TPL-0112
No
See spreadsheet contents; see CM check list contents;


At KO; aligned with the DLs (and outputs) indicated in the PRL;

Typically the CM check list shall be ran before the end of each phase.
Sometimes the CIL info is included in the SVP (Software Verification Plan):
The SVP might be provided by the customer or be required by regulatory standards such as ECSS with the detailed review plan (i.e. while te CIL is typically internal, we could have one additional deliverable, the SVP)
More Project Documents









SPAE Log Book
Most experienced SPAE
SPA Process (MAN.8)
A guide for the performance of Product Assurance activities, including verification check lists before milestones
Excel macro-enabled template:  CSW-QMS-2006-TPL-1226
No

See Milestone meeting prep. GBK:
Created at KO, updated during phases and at least once per milestone

PAR - External Product Assurance Report
SPAE (PM Approves)
SPA Process (MAN.8)
A report with several metrics collected regarding the project execution. Could be requested by the customer as a deliverable.

In case of milestone meetings, the detailed quality verification is performed and the software product assurance report (PAR) is produced, reporting a sum-up of the results. Actions must be created whenever problems are identified and/or when a potential problem is identified. The PAR shall be released for all interested parties (PM and project team, and other departments such as the QD).
 MS Word (Master Template, template ID = CSW-QMS-2003-TPL-1860)
No
See template TOC
See template and "fill in the blanks"
If required: Create one new PAR document per milestone (except KOM).

A guide for milestone meetings (where the PAR contents could be presented) can be found here:

Sprint Retro Log book
Scrum Master / SPAE
Agile Guidebook (to be split in Scrum/Agile Development SDP)
A book to support sprint retrospectives (which is one of the last events to take place in a Scrum/Agile sprint), with some macro integrations to speed up the collection and display of agile metrics, as well as sheets to collect lessons learned and perform action management from them...
Excel template: CSW-QMS-2014-TPL-01088
No
See spreadsheet contents
See template, namely the instructions sheet:


quarta-feira, 27 de julho de 2016

RESOURCE: EA additional documentation

Sparx's Enterprise Architect (EA) UML Modelling Tool has loads of documentation in the WWW (aside from the local online help documentation that typically is very self-contained and informative). Several task-oriented docs exist and are made available via the WWW web site. Some interesting examples are presented here (direct links for download):

Reference Booklets (PDF List):
Getting Started:
Requirements management with EA:


Data Modelling:
UML additional resources: 

(Updated: @2016-10-10: Added version control PDF; 2018-03: updated broken links)

quarta-feira, 25 de maio de 2016

INSTALL: Sparx EA

To install and configure EA to use the floating license, starting from https://delivery.critical.pt/TechAreas/net/SitePages/ToolsPage.aspx select Enterprise Architect (https://delivery.critical.pt/TechAreas/net/SitePages/ToolEnterpriseArchitect.aspx). Look at the PDF with the installation instructions (INTERNAL).

You can also download a free trial from the Sparx Systems WWW site.