Agile Alliance, with some insights for distributed agile teams (at 2012!):
sexta-feira, 29 de julho de 2016
Sococo - Tool for agile distributed teams
You don't need any special tools for supporting Agile/Scrum. A box with PBIs written on paper cards and a task board representing the sprint backlog items (with magnetic cards and/or post its, showing the PBIs the Todo, In Progress, Done and Closed statuses) might do the trick. But for sure that productivity (and auditability, collection of metrics, etc) will be empowered by supporting tools like JIRA or other. The market is moving around this opportunity and so new things appear everyday.
For instance / for future reference:
"SOCOCO is THE online place where Agile teams get work done. Distributed Agile teams go to work in Sococo. It recreates the personal proximity and functionality of a physical office in an online experience. "
So they say here in the Web site where a free online space can be created. For details:
https://www.sococo.com/
For instance / for future reference:
"SOCOCO is THE online place where Agile teams get work done. Distributed Agile teams go to work in Sococo. It recreates the personal proximity and functionality of a physical office in an online experience. "
So they say here in the Web site where a free online space can be created. For details:
https://www.sococo.com/
quinta-feira, 28 de julho de 2016
Estimation Process and related artifacts
Your QMS could include a process on estimation (that presents the estimation techniques and the associated activities to be executed in order to produce the final estimation sheets that are input for ROMs, Proposals, Change Requests, ...).
One example (INTERNAL):
Some common artifacts include templates and models to help you estimating (INTERNAL, use the QMS Portal with the doc id enclosed in double quotes):
One example (INTERNAL):
Some common artifacts include templates and models to help you estimating (INTERNAL, use the QMS Portal with the doc id enclosed in double quotes):
- Estimation form (template): CSW-QMS-2011-TPL-02102-estimation-sum-up.xls (now a xltx)
- Planning Poker form (template): CSW-QMS-2015-TPL-02398-planning-poker-estimation.xltx
- Effort Per Phase Model: CSW-QMS-2009-DOC-04974-effort-model-2014-baseline-data4all.xlsx
- Safety Critical Estimation Model: CSW-QMS-2014-DOC-01296-asd-estimation-model.xlsx
- Estimation @ CRITICAL Software - Study on the Estimation Process for CRITICAL Software Projects: CSW-ESTIMATE-2009-PCS-00707-estimation-process.doc
PS. If you're interested in estimation models, google for them. They are very dependent on the business you're working on although there are some attempts to generalize them.
Example: COCOMO Estimation Model.
Paper: Writing good requirements
There are full courses, papers and entire books on the subject.
It is indeed important to get requirements right (either from the customer or to be able to gather them properly from the customer).
Here's an interesting (old) paper on the subject:
http://homepages.laas.fr/kader/Hooks.pdf
Quoting:
"Abstract. The primary reason that people write poor requirements is that they have had
no training or experience in writing good requirements. This paper will address what
makes a good requirement. It will cover some of the most common problems that are
encountered in writing requirements and then describe how to avoid them. It also
includes examples of problem requirements and how to correct them.
(...)
Published in the Proceedings of the Third International Symposium of the NCOSE - Volume 2, 1993. Prepared by the Requirements Working Group of the International Council on Systems Engineering, for information purposes only. Not an official position of INCOSE."
It is indeed important to get requirements right (either from the customer or to be able to gather them properly from the customer).
Here's an interesting (old) paper on the subject:
http://homepages.laas.fr/kader/Hooks.pdf
Quoting:
"Abstract. The primary reason that people write poor requirements is that they have had
no training or experience in writing good requirements. This paper will address what
makes a good requirement. It will cover some of the most common problems that are
encountered in writing requirements and then describe how to avoid them. It also
includes examples of problem requirements and how to correct them.
(...)
Published in the Proceedings of the Third International Symposium of the NCOSE - Volume 2, 1993. Prepared by the Requirements Working Group of the International Council on Systems Engineering, for information purposes only. Not an official position of INCOSE."
FUN Dept.: SQL Databases?
When the leading edge technology required us to have a SQL DB on our systems, this happened frequently:
(Dilbert's Friday November 17, 1995 comic strip)
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:
Data Modelling:
Reference Booklets (PDF List):
Getting Started:
- http://www.sparxsystems.com.au/downloads/resources/booklets/getting_started_with_enterprise_architect.pdf (Getting Started)
- http://www.sparxsystems.com.au/downloads/resources/booklets/using_enterprise_architect.pdf (Using EA)
- http://www.sparxsystems.com.au/bin/EAUserGuide.pdf (User Guide)
- https://www.sparxsystems.com.au/resources/user-guides/basics/tutorial.pdf (Tutorial)
Requirements management with EA:
Data Modelling:
- http://www.sparxsystems.com.au/resources/uml_datamodel.html
- http://www.sparxsystems.com.au/downloads/whitepapers/Database_Modeling_In_UML.pdf
- https://community.sparxsystems.com/white-papers/669-data-modeling-from-conceptual-model-to-dbms (from Conceptual to Physical)
When and how to use Version Control with EA:
UML additional resources:
(Updated: @2016-10-10: Added version control PDF; 2018-03: updated broken links)
quarta-feira, 20 de julho de 2016
Operations and Maintenance Phase (and the Maintenance Process)
The operations and maintenance phase starts after completion of the acceptance review (AR) of the software. This phase is very important since the success of most software products is highly dependent from the level of operations that it can provide to the customer organisation.
The maintenance process is activated when the software product undergoes any modification to code or associated documentation as a result of correcting an error, a problem or implementing an improvement or adaptation.
The operations and maintenance may be invoked within warranty period or by a maintenance contract and ends with the retirement of the software product (end of life or EOL), with the end of maintenance contract or with the end of the warranty period.
For more details and a link to the maintenance process (internal) look here: http://silvaonsoftware.blogspot.com/2016/05/internal-resource-5-qms-engineering.html
Source: QMS / ITG Materials
The maintenance process is activated when the software product undergoes any modification to code or associated documentation as a result of correcting an error, a problem or implementing an improvement or adaptation.
The operations and maintenance may be invoked within warranty period or by a maintenance contract and ends with the retirement of the software product (end of life or EOL), with the end of maintenance contract or with the end of the warranty period.
For more details and a link to the maintenance process (internal) look here: http://silvaonsoftware.blogspot.com/2016/05/internal-resource-5-qms-engineering.html
Source: QMS / ITG Materials
Code Reviews and the "If it ain't broke, don't fix it" principle
"If it ain't broke, don't fix it." is credited to Bert Lance as the person who popularized it, when he was quoted saying it in the May 1977 issue of the magazine Nation's Business.The expression became widespread, and William Safire wrote that it "has become a source of inspiration to anti-activists." - Wikipedia
Sometimes this principle will be put in place while performing Code Reviews (CR is a verification measure that intends to spot software defects by reading the software source code, as early as possible in the software life cycle). This only means that the main reason you are reviewing the code is to spot defects, so optimizations, formatting issues are out of scope (even if they bother you, don't engage into unnecessary discussions with the author).
Unless, of course, they are part of the written coding conventions for the project (some projects will inherit whatever the company or the customer have). This means that indenting code at 2 spaces instead of 4 could be a defect if there is a coding convention for this team that requires this specific indentation.
Also sometimes, as input to a code review a check list (of different sizes ;) could be handed to you. And those check lists could cover more that spotting defects.
So this principle applies in principle for code reviews unless there is a good reason to break it (Software coding conventions, check lists that are input to each code review).
Got it?
Sometimes this principle will be put in place while performing Code Reviews (CR is a verification measure that intends to spot software defects by reading the software source code, as early as possible in the software life cycle). This only means that the main reason you are reviewing the code is to spot defects, so optimizations, formatting issues are out of scope (even if they bother you, don't engage into unnecessary discussions with the author).
Unless, of course, they are part of the written coding conventions for the project (some projects will inherit whatever the company or the customer have). This means that indenting code at 2 spaces instead of 4 could be a defect if there is a coding convention for this team that requires this specific indentation.
Also sometimes, as input to a code review a check list (of different sizes ;) could be handed to you. And those check lists could cover more that spotting defects.
So this principle applies in principle for code reviews unless there is a good reason to break it (Software coding conventions, check lists that are input to each code review).
Got it?
TOOLS: Modelling Tools Hot Topics
The main (hot) topics for any modelling tool include:
- How to organize hierarchically information (eventually, segregate model info by SW life cycle phase plus, RFP, Proposal packages)
- UML Support: New packages, new subpackages; new [UML] diagrams; new [UML] elements; establish relationships between them (UML relationships, several types: agreggation, composition, generalization, simple trace, ...);
- How to store requirements information: features (requested, proposed), requirements (several types); features and requirements are not part of the initial UML spec so the tools will support them differently (with some kind of stereotyped UML element most probably); if applicable: How to store testing information (the spec as well as test results including evidences and created issues) - typically for this, test management tools will be used.
- How to draw basic UML diagrams: Some are simpler than other: class, sequence, object, package, deployment, use case, state machine, activity, communication, composite structure, component, interaction overview, and timing diagrams (Tip: See "UML Distilled")
- How to capture sequence diagrams from executable code
- Team conventions for the model: package names, UML Element identifiers (requirements, UML components), ...
If you know how to do this in your UML Modelling tool then you're ready to start modelling.
Advanced tasks for team leaders might also include:
- How to generate documentation from the model (HTML, doc, xls, PDF, more)
- How to reverse engineer: Code, physical database models, Web Services, XML...
- How to forward engineer (classes to code skeletons; tables to DDL SQL, ...)
Additional tasks to be performed:
- How to create a collaborative (centralized) model from scratch
- How to baseline the model (per milestone) and perform backups
- How to activate and configure security (roles, users, authorization)
- How to activate and read audit logs (activity logs, per user)
- How to import and export from the model to other UML tools (XMI support) - either the full model or parts of it
- How to organize hierarchically information (eventually, segregate model info by SW life cycle phase plus, RFP, Proposal packages)
- UML Support: New packages, new subpackages; new [UML] diagrams; new [UML] elements; establish relationships between them (UML relationships, several types: agreggation, composition, generalization, simple trace, ...);
- How to store requirements information: features (requested, proposed), requirements (several types); features and requirements are not part of the initial UML spec so the tools will support them differently (with some kind of stereotyped UML element most probably); if applicable: How to store testing information (the spec as well as test results including evidences and created issues) - typically for this, test management tools will be used.
- How to create traceability matrices. How to export them (to Word, CSV / Excel, ...)
- How to perform traceability analysis (what relates to what; where is it stored in the model, ...), including gap analysis- How to draw basic UML diagrams: Some are simpler than other: class, sequence, object, package, deployment, use case, state machine, activity, communication, composite structure, component, interaction overview, and timing diagrams (Tip: See "UML Distilled")
- How to capture sequence diagrams from executable code
- Team conventions for the model: package names, UML Element identifiers (requirements, UML components), ...
Advanced tasks for team leaders might also include:
- How to generate documentation from the model (HTML, doc, xls, PDF, more)
- How to reverse engineer: Code, physical database models, Web Services, XML...
- How to forward engineer (classes to code skeletons; tables to DDL SQL, ...)
- How to create a collaborative (centralized) model from scratch
- How to baseline the model (per milestone) and perform backups
- How to activate and configure security (roles, users, authorization)
- How to activate and read audit logs (activity logs, per user)
- How to import and export from the model to other UML tools (XMI support) - either the full model or parts of it
If you know how to do these latter tasks, you're ready to help / manage teams doing modelling.
Modelling tools include Sparx Systems Enterprise Architect (EA), MagicDraw, ...
(Click here for EA additional documentation).
(@2016-07-26: Updated task grouping; minor rephrases/typos; 2016-11-17: EA add. doc. link)
(Click here for EA additional documentation).
(@2016-07-26: Updated task grouping; minor rephrases/typos; 2016-11-17: EA add. doc. link)
RESOURCE: Code Smells and more (Design Patterns, Anti-Patterns and Refactoring Tips)
One interesting reference guide to design patterns (and anti-patterns) as well as "code smells" (who happen when the code you're touching smells like a rotten bird in your garden) is:
- https://sourcemaking.com/design_patterns (Design Patterns: structural and more; also remember to avoid anti-patterns)
- https://sourcemaking.com/refactoring (code smells: what to do to improve this "code smell"?)
Nice readings.
INDEX: The Agile/Scrum index of useful links
To gather some resources and information presented on this site (and mostly available in the internet) here it goes, the Agile/Scrum index of useful links (not exhaustive):
- http://silvaonsoftware.blogspot.pt/2016/05/scrum-agile-main-documents-and-5-line.html (Resumo do SCRUM Official Guide: 16p. em 5 linhas ;)
- http://silvaonsoftware.blogspot.pt/2016/07/book-sbok-guide-guide-to-scrum-body (Scrum Body of Knowledge)
- http://silvaonsoftware.blogspot.pt/2016/04/resource-agile-videos.html (learning through videos)
- http://silvaonsoftware.blogspot.pt/2016/06/book-actionable-agile-tools-jeff.html (BOOK with additional tools to use with Scrum, e.g. during some Scrum events)
- http://silvaonsoftware.blogspot.pt/2016/04/quality-attributes-invest-on-proper.html (about the INVEST Model that each US shall respect)
- http://silvaonsoftware.blogspot.com/2016/06/the-state-of-scrum-2015-report.html (The State of Scrum Report)
RESOURCE: Security is a Process
Security is a process: It is not just a tool to produce you reports on potential holes (when probably you don't have the time or the skilled persons to browse through the detailed report it generates).
And this is what happens when you don't have the process in place. You will get to the cover page in the news (for the bad reasons):
https://www.publico.pt/portugal/jornal/auditoria-detectou-21-falhas-de-seguranca-no-sistema-informatico-dos-tribunais-21474798
Excellent initiatives at this level (security) are government initiatives like these ones:
And this is what happens when you don't have the process in place. You will get to the cover page in the news (for the bad reasons):
https://www.publico.pt/portugal/jornal/auditoria-detectou-21-falhas-de-seguranca-no-sistema-informatico-dos-tribunais-21474798
Excellent initiatives at this level (security) are government initiatives like these ones:
- https://en.wikipedia.org/wiki/Cyber_Essentials (UK)
- https://web.nvd.nist.gov/view/ncp/repository (US, from the NIST)
- https://nvd.nist.gov/ncp/repository (the checklists)
- http://www.usccu.us/documents/US-CCU%20Cyber-Security%20Check%20List%202007.pdf (2007, US)
- At the "SW and Security Product Assurance technical area" a list of recommended tools can be found and some are security-related: https://delivery.critical.pt/TechAreas/sspa/SitePages/Web%20Application%20Security%20Testing.aspx (accessible from https://delivery.critical.pt/TechAreas/sspa/SitePages/Tools.aspx)
- Security Testing Tool Example: IBM AppScan: Used to perform automated web application security tests (dynamic). IBM Security AppScan Standard helps decrease the likelihood of web application attacks and costly data breaches by automating application security vulnerability testing. IBM Security AppScan Standard can be used to reduce risk by permitting you to test applications prior to deployment and for ongoing risk assessment in production environments.
Remember: Your information system is as strong as its weakest link. For instance: If you don't patch your system components that you rely upon (e.g. your RDBMS, Application Servers, File Servers, Web Servers, target Operating Systems) who do you think your customer will turn to when a security flaw turns up?
History: 2017-11-30, updated with SSPA internal resources (and IBM Appscan tool).
History: 2017-11-30, updated with SSPA internal resources (and IBM Appscan tool).
segunda-feira, 18 de julho de 2016
Project Management: PMBOK
The PMBOK is an indispensable reference for Project Managers (the basis for certification of Project Managers at the Project Management Institute - PMI):
Citando:
The PMBOK as described in the Guide is intended to be "subset of the project management body of knowledge that is generally recognized as a good practice. 'Generally recognized' means the knowledge and practices described are applicable to most projects most of the time and there is a consensus about their value and usefulness. 'Good practice' means there is a general agreement that the application of the knowledge, skills, tools, and techniques can enhance the chance of success over many projects."
Citando:
The PMBOK as described in the Guide is intended to be "subset of the project management body of knowledge that is generally recognized as a good practice. 'Generally recognized' means the knowledge and practices described are applicable to most projects most of the time and there is a consensus about their value and usefulness. 'Good practice' means there is a general agreement that the application of the knowledge, skills, tools, and techniques can enhance the chance of success over many projects."
quinta-feira, 14 de julho de 2016
Agile: Kan Ban (Getting Started)
Kan Ban is one of the Agile Methodologies, intimately related with the Toyota Production System (TPS), Lean Manufacturing and Just in Time (JIT) production concepts (started in the manufacturing industry):
Some interesting starting points include:
Some interesting starting points include:
- Getting started: https://kanbanery.com/ebook/GettingStartedWithKanban.pdf
- Kan Ban vs. Scrum: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
- http://www.kuehne.com.br/Kanban.pdf (PT BR)
BOOK: SBOK Guide - A Guide to the SCRUM BODY OF KNOWLEDGE
One interesting thorough book on Scrum, talking of Scrum of Scrums and many other interesting topics is the SBOK™ Guide (A Guide to the SCRUM BODY OF KNOWLEDGE).
The PDF links are:
The PDF links are:
- www.scrumstudy.com/download-free-SBOK.asp (English version)
- www.scrumstudy.com/download-free-SBOK.asp?lan=pt ("Portuguese" version)
TOOLS: Rapid prototyping tools (for mockups creation as well as live feature navigation)
The basic tool for rapid prototyping is, as you might know, a white board and good User eXperience Design (UXD) principles (in your head).
Your favorite IDE could serve the purpose (you already know how to implement Grahical User Interfaces there, so there's no ramp up). Sparx Systems' Enterprise Architect also allows you some basic prototyping (and navigation) with the advantage of traceability of UI elements to other elements of the model (such as requirements and tests).
Any image editor also could do (as well as some sheets of hand-drawn papers that after peer review could be quickly scanned and added to the Version Control System or to meeting minutes). The only problem with these latter tools is the need of navigation (between windows, pages) so that the visualization of the final system behavior is easier.
There are however specialized tools for rapid prototyping like Balsamiq. Some are free, some other are not. Some are specialized for Web applications, some for mobile apps, some for client apps.
A good review of some of these tools can be found here:
Your favorite IDE could serve the purpose (you already know how to implement Grahical User Interfaces there, so there's no ramp up). Sparx Systems' Enterprise Architect also allows you some basic prototyping (and navigation) with the advantage of traceability of UI elements to other elements of the model (such as requirements and tests).
Any image editor also could do (as well as some sheets of hand-drawn papers that after peer review could be quickly scanned and added to the Version Control System or to meeting minutes). The only problem with these latter tools is the need of navigation (between windows, pages) so that the visualization of the final system behavior is easier.
There are however specialized tools for rapid prototyping like Balsamiq. Some are free, some other are not. Some are specialized for Web applications, some for mobile apps, some for client apps.
A good review of some of these tools can be found here:
Subscrever:
Mensagens (Atom)