SECURITY: The visible face of your projects could be the wrong one

Customer are always important but some customers and its projects will need additional care. Sometimes the visible face of your work gets into the news and this is good. Unless the news are bad, or even worse, are incorrect.

Only then you'll probably be aware that sometimes it is just not a matter of being the best in business and let your technical (and management) competency excel.
It's a matter of surviving what it is being said about your work, the way you got your contract, the way you delivered your work, the way you could get the blame for issues that are not part of the scope of your work and so on. It's then that you'll have to have your executive management support (to shield you from the outer world interferences and to manage communication with that outer world).

The oddest experience I've ever had was having to work with a point of contact that was to help us execute a specific project and from minute one his intentions were to undermine the project's success. I had 20+ years of experience in the software industry, and in my innocence, I was thinking I had nothing more to learn. I was so wrong,

What if the visible face of your project start to be in the news? The news could be correct and/or incorrect; presenting sensitive data and/or confidential data (that no one knows who's disclosing). Your competition could be interested in it. Internal stakeholders could be interested in it (feeling "invaded"). Reporters could be getting it all wrong. It can get messy...

Some examples (in PT, sorry guys):

• http://www.publico.pt/sociedade/noticia/citius-tem-um-mes-para-ficar-bom-colapso-era-afinal-previsivel-1670159
• http://www.computerworld.com.pt/2013/05/27/critical-reage-a-noticias-sobre-citius/
• http://www.publico.pt/sociedade/noticia/auditoria-ja-tinha-alertado-para-problemas-na-rede-informatica-dos-tribunais-1669185
• http://observador.pt/especiais/como-a-rede-de-toupeiras-do-benfica-foi-descoberta-pela-policia-judiciaria/ (2018-03: you could be wondering what BENFICA has to do with the rest of this article, but it does).
• http://silvaonsoftware.blogspot.pt/2016/07/resource-security-is-process.html

Maybe some more can be told on this topics later on. Lessons learned are for sure more useful if properly shared. And you bet that we've managed to deliver successfully that particular [migration] project.

Revisions: 2018-03 - updated links. 2018-04 - added the "drop money out of the window" link.
PS: Additional info or how to not execute a "data migration" project:

• https://www.publico.pt/2014/09/01/sociedade/noticia/site-citius-continua-indisponivel-no-arranque-do-mapa-judiciario-1668298#/0
• https://www.publico.pt/2014/09/01/sociedade/noticia/sistema-informatico-dos-tribunais-esta-a-voltar-a-normalidade-assegura-ministerio-da-justica-1668350
• https://tek.sapo.pt/noticias/computadores/artigos/citius-investimento-de-26-milhoes-de-euros-na-plataforma-tera-sido-desperdicado (or, how to drop out of the window ~2.5 M EUR) 

TOOLS: Source Monitor (Static Analysis - Multi-language)

Static analysis refers to analysis of the code statically (without running it).
There are several tools embedded in modern IDEs (as plugins or even natively).
There are also some standalone multi-language tools.
A simple (and free) example of a tool like this is the multi-language tool named Source Monitor:

• http://www.campwoodsw.com/sourcemonitor.html

Quoting:
"The freeware program SourceMonitor lets you see inside your software source code to find out how much code you have and to identify the relative complexity of your modules. For example, you can use SourceMonitor to identify the code that is most likely to contain defects and thus warrants formal review. SourceMonitor, written in C++, runs through your code at high speed, typically at least 10,000 lines of code per second. SourceMonitor provides the following:

• Collects metrics in a fast, single pass through source files.
• Measures metrics for source code written in C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML.
• Includes method and function level metrics for C++, C, C#, VB.NET, Java, and Delphi.
• Offers Modified Complexity metric option.
• Saves metrics in checkpoints for comparison during software development projects.
• Displays and prints metrics in tables and charts, including Kiviat diagrams.
• Operates within a standard Windows GUI or inside your scripts using XML command files.
• Exports metrics to XML or CSV (comma-separated-value) files for further processing with other tools."

What do you do static analysis for? 
Some reasons include:
- For quickly gaining insight on some new code (to you) when entering a project
- For spotting difficult parts of the code (in terms of complexity for example), spotting refactoring candidates
- For quickly analysing some quality attributes of the code being produced by the team (as a Technical Manager or mini-team leader, for instance % of comments when compared to LOC)
- For presenting reports to the customer on specific quality attributes of the code (Kiviat Charts with KPIs and an optimal region where we would like or are obliged to have the code).

History: Added details, quote 2017-11; 2017-12-04: Minor rephrases;

CMMI Staged Representation (Maturity Levels)

The staged representation for CMMI-DEV introduces maturity levels (1-5):

Maturity Level 2 (ML2)

Requirements Management (RM)
Project Planning (PP)
Project Monitoring and Control (PMC)
Supplier Agreement Management (SAM)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA)
Configuration Management (CM)

Maturity Level 3 (ML3)

Organizational Process Focus (OPF)
Organizational Process Definition (OPD)
Organizational Training (OT)
Integrated Project Management (IPM)
Risk Management (RSKM)
Decision Analysis and Resolution (DAR)
Requirements Development (RD)
Technical Solution (TS)
Product Integration (PI) - how to integrate the system (and dependencies)
Verification (VER) - selected WP meet their specified requirements; build the SW right
Validation (VAL) - build the software right; in the right environment; criteria for validation

Maturity Level 4 (ML4)

Organizational Process Performance (OPP) - establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects
Quantitative Project Management (QPM) - quantitatively manage the project to achieve quality and process performance objectives; metrics infrastructures

Maturity Level 5 (ML5)

Organizational Performance Management (OPM) - manage the org. performance to meet its business obj.

Causal Analysis and Resolution (CAR) - identify causes of problems (more broadly: selected outcomes) and take action to improve performance

About CMMI-DEV (Concepts)

CMMI-DEV is divided into process areas (definitions below).

First things first:

• CMMI-DEV, V1.3 =  "CMMI® for Development, Version 1.3" = Improving processes for developing better products and services

Main concepts:

• Process Areas (PA): A cluster of related practices in an area that, when implemented collectively, satitsfies a set of goals considered important for making improvements in that area.
• PA Groups: Support, Project Management, Process Management, Engineering
• Specific Goals (SG): A required model component that describes the unique characteristics that must be present to satisfy a process area. 
• Capability Level: Achievement of process improvement within an individual process area; defined by appropriate SG and GG for a PA.
• Specific Practice (SP): An expected model component that is considered important in achieving a specific goal (SG); the specific practices (SPs) describe the activities expected to result in achievement of the SG of that area.
• Generic Goals (GG): A required model component that describes characteristics that must be present to institutionalize processes that implement a process area.
• Institutionalization: The ingrained way of doing business that an organization follows routinely as part of its corporate culture.
• Stakeholder: A group or individual that is affected by or is in some way accountable for the outcome of an undertaking; may include project or work group members, suppliers, customers, end users, and others.
• Relevant Stakeholder: A stakeholder that is identified for involvement in specific activities and is included in a plan.
• Maturity Level (ML): Degree of process improvement across a predefined set of process areas in which goals in the set are attained.
• Process Performance: A measure of results achieved by following a process.
• For a full glossary of terms see [1, 3].

There are 22 Process Areas for CMMI-DEV and you can find the full list or process areas here.

Sources:

•  [1] "CMMI-DEV 1.3 - Technical Report", SEI, CMU/SEI-2010-TR-033 / ESC-TR-2010-033, Nov. 2010 (available at http://www.sei.cmu.edu; this is "the bible")
• [2] "CMMI for Development - Guidelines for Process Integration and Product Improvement", 3rd. Ed.; Mary Beth Chrissis, Mike Conrad, Sandy Shrum; Addison-Wesley 
• [3] "CMMI for Development Quick Reference" (available from http://www.sei.cmu.edu)

CMMI-DEV Process Areas

CMMI-DEV V1.3 is divided into Process Areas (definitions here).

These are the 22 process areas for CMMI-DEV (in alphabetical order):

Process Area (Group, ML)	Group (ML)	Description
CAR	SUPPORT (ML5)	CAUSAL ANALYSIS AND RESOLUTION
CM	SUPPORT (ML2)	CONFIGURATION MANAGEMENT
DAR	SUPPORT (ML3)	DECISION ANALYSIS AND RESOLUTION
IPM	PROJECT MANAGEMENT (ML3)	INTEGRATED PROJECT MANAGEMENT
MA	SUPPORT (ML2)	MEASUREMENT AND ANALYSIS
OPD	PROCESS MANAGEMENT (ML3)	ORGANIZATIONAL PROCESS DEFINITION
OPF	PROCESS MANAGEMENT (ML3)	ORGANIZATIONAL PROCESS FOCUS
OPM	PROCESS MANAGEMENT (ML5)	ORGANIZATIONAL PERFORMANCE MANAGEMENT
OPP	PROCESS MANAGEMENT (ML4)	ORGANIZATIONAL PROCESS PERFORMANCE
OT	PROCESS MANAGEMENT (ML3)	ORGANIZATIONAL TRAINING
PI	ENGINEERING (ML3)	PRODUCT INTEGRATION
PMC	PROJECT MANAGEMENT (ML2)	PROJECT MONITORING AND CONTROL
PP	PROJECT MANAGEMENT (ML2)	PROJECT PLANNING
PPQA	SUPPORT (ML2)	PROCESS AND PRODUCT QUALITY ASSURANCE
QPM	PROJECT MANAGEMENT (ML4)	QUANTITATIVE PROJECT MANAGEMENT
RD	ENGINEERING (ML3)	REQUIREMENTS DEVELOPMENT
REQM	PROJECT MANAGEMENT (ML2)	REQUIREMENTS MANAGEMENT
RSKM	PROJECT MANAGEMENT (ML3)	RISK MANAGEMENT
SAM	PROJECT MANAGEMENT (ML2)	SUPPLIER AGREEMENT MANAGEMENT
TS	ENGINEERING (ML3)	TECHNICAL SOLUTION
VAL	ENGINEERING (ML3)	VALIDATION
VER	ENGINEERING (ML3)	VERIFICATION
GG	-	(GENERIC GOALS) Applicable to all PAs

Sources:

• [1] "CMMI-DEV 1.3 - Technical Report", SEI, CMU/SEI-2010-TR-033 / ESC-TR-2010-033, Nov. 2010 (available at http://www.sei.cmu.edu; this is "the bible")
• [2] "CMMI for Development - Guidelines for Process Integration and Product Improvement", 3rd. Ed.; Mary Beth Chrissis, Mike Conrad, Sandy Shrum; Addison-Wesley 
• [3] "CMMI for Development Quick Reference" (available from http://www.sei.cmu.edu)

Updated: 
2016-03-16, initial version

Case Study: EXOMARS TGO

What if you were to work for a mission that aims to find life on another planet?
Could you do it from Portugal?
Could you do it using agile methodologies for ESA?
What deliverables were you to deliver to your contractor?
On what language would you have to work on? And on what programming language?
How many time would it take per sattelite module and what statistics would it involve (#reqs to implement, #LOC, etc.)?

Tomorrow (2016-03-14) it's the launch of the first phase of the work of years here at Critical Software. At 9:31 from Casakhistan.

• https://www.theguardian.com/science/2016/mar/13/exomars-giant-nose-life-on-mars-prepares-launch
• https://www.theguardian.com/science/across-the-universe/2016/mar/11/is-there-life-on-mars-exomars-trace-gas-orbiter-takes-up-the-search

Answers on a follow up. One of these days. 

About Earned-Value Management (EVM)

The topic here is Software Development, but with time you'll learn that a team without management will under-perform (and this is more true for large teams).

Sometimes, if you're a software engineer (or product assurance engineer) you'll be on progress meetings where the project performance is being reviewed and some strange acronyms will start being referred (CPI, SPI, etc.).
Some of these are Earned-Value Management Indicators (EVM Indicators). What are these? Google will tell you. For now I'll just share with you these neat cheat sheets and/or summaries:

• http://www.velopi.com/images/Velopi%20PMP%20Cheat%20Sheet.pdf
• http://www.starpmo.com/downloads/00_PMP_Formulae_CheatSheet_Anil_Tanguturi.pdf
• http://leadinganswers.typepad.com/files/earned-value---one-page-summary-1.pdf
• http://www.cheatography.com/mrsb/cheat-sheets/project-cost-management/

There are also good books for a jump start on these topics:

• Project Management for Dummies (Stanley / Portny): Amazon.

PS. For a description of WISE EVM indicators please read the WISE Project Module Guidebook (INTERNAL). Examples of how they are shown internally to PMs can be seen here (INTERNAL).

PS. EVM is NOT enough for Project Monitoring and Control for certain levels of maturity as required by the Capability Maturity Model (CMMI). We'll need more on our QMS. More on this later on. One of these days.

(2016-05-12: Added book, WISE GBK, screenshot; 2017-05-02: shortened URL, minor rephrases)

Milestone meetings and Milestone Reports (Waterfall)

Waterfall uses milestones at the end of phases as a formal moment to mark the closure that phase.

Milestone Meetings

Every milestone must have milestone meetings. Some milestones have internal meetings as well as the external (i.e. with the customer) meetings. External milestone meetings typically involve several customer stakeholders for a large period of time (half a day, a full day or even more, depending on the agenda and on the complexity of the project). External meetings can involve travel to the customer premises (to Cannes or wherever the customer is located, which could be "nice").

Each milestone meeting has a specific agenda, but typically will involve overviewing the work performed in the current phase, performing a walk-through of some deliverable documents, presenting some statistics on the work thas has been performed, making clear whatever open issues that were still left unclosed and a final special moment where the customer confirms that it's ok to move to the next phase (that statement should be present in the meeting minutes, by the way).

Typically it is a good idea that the QMS has some kind of guide to help the (project) management team as well as the rest of the team preparing the milestone meeting. Here's an example in the format of a "Project Life Cycle Milestone Meetings Guidebook" (internal) :

• https://quality.critical.pt/QMS%20PT/MAN-management/MAN-01-project-management/CSW-QMS-2009-GBK-03894-project-milestones-meetings.pdf#search=milestone%20meeting%20gbk
• Details on a possible TOC can be found here. 

Milestone Reports

As a result of a successful milestone being achieved, a milestone meeting report is produced (and this is typically the exit criteria of the phases - the existence of an approved milestone review report by the customer).

This NASA document has example TOCs for those reports (and much more):

• https://quality.critical.pt/orgstandards/nasa/nasa-sel/software-management-handbook.pdf

Example of those deliverables are: 

• PDR Report (Preliminary Design Review Report)
• CDR Report (Critical Design Review Report)
• QR Report (Qualification Review Report)
• AR Report (Acceptance Review Report)

(2016-05-05: added URL for MM GBK possible TOC)

RESOURCE: On Software Development Methodologies

The non-exaustive-use-with-care list of resources on software development methodologies includes some additional information on the waterfall - agile/scrum "recipes" - some of which include variants and/or predecessors of it:

• https://en.wikipedia.org/wiki/Software_development_process - several methodologies listed including FDD, TDD, etc.
• https://en.wikipedia.org/wiki/Software_development_process#Spiral_development - focus on iterative deliveries and risk management as well as planning as explicit parts of the methodology
• https://en.wikipedia.org/wiki/Extreme_programming - unit testing, pair programming, involve the end-customer, stand-up meetings
• https://en.wikipedia.org/wiki/Software_development_process#Agile_development
• https://en.wikipedia.org/wiki/Scrum_(software_development)