Here's an interesting resource on Agile/Scrum:
Quoting:
"Free Online Scrum Master Training: The fun way to learn about Agile/Scrum, prepare for Scrum Master certification / Agile certification (CSM, CSPO, etc.), and debunk popular misconceptions."
PS. Kudos to Cátia M for sharing this with the rest of us.
quinta-feira, 28 de abril de 2016
TOOL: FreeMind (Diagramming tool, Mind Maps)
Freemind is an open source freeware tool (written in Java) that allows you to do some basic diagrams (as well as mind maps, called in Portuguese as "Mapas Ontológicos").
Diagrams supported include:
- Mind maps,
- Fishbone diagrams (used for causal analysis and brainstorming sessions)
- WBS diagrams, and more.
You can download it here (I use the portable edition, no install required on all machines if shared via a Google Drive or similar cloud storage that automatically propagates to all computers you own):
http://freemind-portable.en.softonic.com/download
PS. You might want to read and know a little bit more about (Tony Buzan's) mind maps here, here and here.
(@2016-06-20: Added the PT translation)
Diagrams supported include:
- Mind maps,
- Fishbone diagrams (used for causal analysis and brainstorming sessions)
- WBS diagrams, and more.
You can download it here (I use the portable edition, no install required on all machines if shared via a Google Drive or similar cloud storage that automatically propagates to all computers you own):
http://freemind-portable.en.softonic.com/download
PS. You might want to read and know a little bit more about (Tony Buzan's) mind maps here, here and here.
(@2016-06-20: Added the PT translation)
Main Work Products for Software Development Projects (Waterfall)
The waterfall phases aim to define:
- What to do? - requirements catalogue (mapping to features; features could map to requested features)
- How to do? - high-level architecture and (if needed) detailed design
- Execute! - produce the code, unit tests and reverse engineer the detailed design (if possible)
- Validate! - validate the system against requirements (are we doing things right?)
- Accept! - prove that the system solves the customer problems (to the customer or a customer representative). Are we doing the right things? Deploy (transfer).
- Maintain! - keep the system up and running (and optionally evolve it - new features, changed features)
The core work products (outputs of applying QMS Engineering processes) are:
- SRS (Requirements Spec)
- SAS (Architecture Spec document - High Level Design; could include sections for ICD, DBS)
- SDD (Detailed design which could include a section for the DBS)
- The Code
- STS (and the STR, i.e. the test report)
- ATS (and the ATR)
In order to execute the project you'll also need plans (management documents, outputs of applying QMS Management or QMS Support processes) as well as present reports:
- PMP (Project Management Plan),
- CMP (Configuration Management Plan);
- CIL (identifies the review strategy for each item - and lists external CIs)
- QAP (Quality Assurance Plan)
- SVP (SVVP, and some similar docs could exist due to regulatory requirements)
- SPAR (SW Product Assurance Report - metrics per milestone)
- Milestone Reports
- Progress Reports (per milestone or per time period - e.g. monthly)
- etc.
PS. Remember that not all these documents need to be deliverables: A Deliverable requires extra peer review and formal customer acceptance (and all this takes you away precious time). Typically the project proposal identifies the minimum set of deliverables.
(@2016-10-13: rephrases, expanded acronyms)
- What to do? - requirements catalogue (mapping to features; features could map to requested features)
- How to do? - high-level architecture and (if needed) detailed design
- Execute! - produce the code, unit tests and reverse engineer the detailed design (if possible)
- Validate! - validate the system against requirements (are we doing things right?)
- Accept! - prove that the system solves the customer problems (to the customer or a customer representative). Are we doing the right things? Deploy (transfer).
- Maintain! - keep the system up and running (and optionally evolve it - new features, changed features)
The core work products (outputs of applying QMS Engineering processes) are:
- SRS (Requirements Spec)
- SAS (Architecture Spec document - High Level Design; could include sections for ICD, DBS)
- SDD (Detailed design which could include a section for the DBS)
- The Code
- STS (and the STR, i.e. the test report)
- ATS (and the ATR)
In order to execute the project you'll also need plans (management documents, outputs of applying QMS Management or QMS Support processes) as well as present reports:
- PMP (Project Management Plan),
- CMP (Configuration Management Plan);
- CIL (identifies the review strategy for each item - and lists external CIs)
- QAP (Quality Assurance Plan)
- SVP (SVVP, and some similar docs could exist due to regulatory requirements)
- SPAR (SW Product Assurance Report - metrics per milestone)
- Milestone Reports
- Progress Reports (per milestone or per time period - e.g. monthly)
- etc.
PS. Remember that not all these documents need to be deliverables: A Deliverable requires extra peer review and formal customer acceptance (and all this takes you away precious time). Typically the project proposal identifies the minimum set of deliverables.
(@2016-10-13: rephrases, expanded acronyms)
quinta-feira, 21 de abril de 2016
Case Study: HUMS Ground Station
An "hypothetical" case study:
The VH-71 was a program for the U.S. presidential helicopter (Marine One).
Imagine that a new generation of Health and Usage Monitoring Systems (HUMS) ground station was to be developed. These HUMS runs on a laptop that stays on ground (thus the name ground station) and after debrief (which is the operation that runs the gathered monitoring systems data - flight data - from the helicopter through a series of algorithms) it will allow for an informed decision (by the maintenance personnel) on whether it is safe to continue to fly it or not for a few more hours.
Would you like to have been part of it? Would you do it using waterfall? What kind of documents would you have included in the technical baseline? Against what standards would it have been built?What level of effort would you have had spent on analysis, implementation, validation and acceptance? What would have been the project duration for it?
About VH-71: It was based on AgustaWestland AW101, formerly EH101 (BTW did you know that the EH101 should have been EHI 01 but a transcription error caught on)?
Links last verified at 2016-04-21.
PS. About the H/C being "like a rock", contrarily to a plane that should... plane (includes a part with the latest Cosmos series presenter, very well known scientist in the US):
https://www.youtube.com/watch?v=BTqu9iMiPIU; and a video with crazy operations and landings being done by H/Cs.
(2016-05-12: Added 2 videos; 2016-05-18: small rephrases; 2017-10-31: added link to HC model)
The VH-71 was a program for the U.S. presidential helicopter (Marine One).
Imagine that a new generation of Health and Usage Monitoring Systems (HUMS) ground station was to be developed. These HUMS runs on a laptop that stays on ground (thus the name ground station) and after debrief (which is the operation that runs the gathered monitoring systems data - flight data - from the helicopter through a series of algorithms) it will allow for an informed decision (by the maintenance personnel) on whether it is safe to continue to fly it or not for a few more hours.
Would you like to have been part of it? Would you do it using waterfall? What kind of documents would you have included in the technical baseline? Against what standards would it have been built?What level of effort would you have had spent on analysis, implementation, validation and acceptance? What would have been the project duration for it?
About VH-71: It was based on AgustaWestland AW101, formerly EH101 (BTW did you know that the EH101 should have been EHI 01 but a transcription error caught on)?
- Some history on VH-71: https://en.wikipedia.org/wiki/Lockheed_Martin_VH-71_Kestrel
- Here's the helicopter database info with info on all vehicles built (some of them are now flying doing S&R in Canada): http://www.helis.com/database/model/275/
- AgustaWestland is a world giant of the helicopter industry, part of an even bigger company (Finmeccanica): https://en.wikipedia.org/wiki/AgustaWestland
- Related models include EH-101 (https://pt.wikipedia.org/wiki/AgustaWestland_EH101) and AW101 (https://en.wikipedia.org/wiki/AgustaWestland_AW101)
- And now, for something completely different: Some google indexed photos: http://www.google.pt/search?q=vh71a+photos&gws_rd=cr&ei=Xxu9VrWIMsyHaI3ao6gB
- And a model to build your own Marine One: https://www.super-hobby.com/products/VH-71-Marine-ONE-EH-101.html
Links last verified at 2016-04-21.
PS. About the H/C being "like a rock", contrarily to a plane that should... plane (includes a part with the latest Cosmos series presenter, very well known scientist in the US):
https://www.youtube.com/watch?v=BTqu9iMiPIU; and a video with crazy operations and landings being done by H/Cs.
(2016-05-12: Added 2 videos; 2016-05-18: small rephrases; 2017-10-31: added link to HC model)
TOOLS: Intermission: Mouse without borders
In this intermission I give you: "Mouse without borders". To be more exact it's Microsoft that gives you the utility for free here:
https://www.microsoft.com/en-us/download/details.aspx?id=35460
Grab it while you can (not that I believe that it will stop being free).
https://www.microsoft.com/en-us/download/details.aspx?id=35460
Grab it while you can (not that I believe that it will stop being free).
To Install and Configure it
You only need to download the utility on 2 computers, run (your favorite AV and then run) the setup; use the host name and software-generated key (that you'll have to write down in the second computer); after that the master computer performs a quick location config (so that "the mouse knows where to go").What's it good for?
This is a productivity tool that allows you sharing a same mouse (and keyboard) in several computers without having to be switching between those hardware devices.
You just need to say where the other computers are (physically, in relation to the "master computer") and the mouse will move there (without borders). The tool will allow you also to copy text (and files!) easily between (up to) 4 computers.
You just need to say where the other computers are (physically, in relation to the "master computer") and the mouse will move there (without borders). The tool will allow you also to copy text (and files!) easily between (up to) 4 computers.
It's useful for some of these scenarios:
- Testing (if you record results on a system and you need to test interactively on another). Grab text from that error on one place and paste it on the place you have the test management tool. Precious time saving.
- Programming: when you need to deploy files on servers or other Windows boxes.
- Whenever you have 2 PCs on your desk and you need to frequently change from one to another.
- (fill in your scenarios here).
AOB
Another tool that works well is Synergy (and this is cross-platform).
(2016-04-21: Rephrases; added cross platform info)
(2016-04-21: Rephrases; added cross platform info)
terça-feira, 19 de abril de 2016
[STANDARD] ISO/IEC 12207 Systems and software engineering -- Software life cycle processes
ISO/IEC 12207 Systems and software engineering -- Software life cycle processes
Quoting:
"ISO/IEC 12207:2008 establishes a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. It contains processes, activities, and tasks that are to be applied during the acquisition of a software product or service and during the supply, development, operation, maintenance and disposal of software products. Software includes the software portion of firmware.
ISO/IEC 12207:2008 applies to the acquisition of systems and software products and services, to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system, whether performed internally or externally to an organization. Those aspects of system definition needed to provide the context for software products and services are included.
ISO/IEC 12207:2008 also provides a process that can be employed for defining, controlling, and improving software life cycle processes.
The processes, activities and tasks of ISO/IEC 12207:2008 - either alone or in conjunction with ISO/IEC 15288 - may also be applied during the acquisition of a system that contains software."
Quoting wikipedia:
"The ISO/IEC 12207 Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.
The ISO/IEC 12207 standard establishes a process of lifecycle for software, including processes and activities applied during the acquisition and configuration of the services of the system. Each Process has a set of outcomes associated with it. There are 23 Processes, 95 Activities, 325 Tasks and 224 Outcomes (the new "ISO/IEC 12207:2008 Systems and software engineering – Software life cycle processes" defines 43 system and software processes).
The standard has the main objective of supplying a common structure so that the buyers, suppliers, developers, maintainers, operators, managers and technicians involved with the software development use a common language. This common language is established in the form of well defined processes. The structure of the standard was intended to be conceived in a flexible, modular way so as to be adaptable to the necessities of whoever uses it. The standard is based on two basic principles: modularity and responsibility. Modularity means processes with minimum coupling and maximum cohesion. Responsibility means to establish a responsibility for each process, facilitating the application of the standard in projects where many people can be legally involved.
The set of processes, activities and tasks can be adapted according to the software project. These processes are classified in three types: basic, for support and organizational. The support and organizational processes must exist independently of the organization and the project being executed. The basic processes are instantiated according to the situation."
quinta-feira, 14 de abril de 2016
BOOK: SWEBOK - Guide to the Software Engineering Body of Knowledge
Yesterday, I've just found "on my back" (literally) an old but still interesting resource every software engineer should read about, printed and signed by a good friend of mine, previously Quality Manager of the company I'm working to and now living at Macau.
I've came across the:
- SWEBOK - Guide to the Software Engineering Body of Knowledge (A project of the IEEE Computer Society Professional Practices Commitee, 2004 [outdated] Version.
"SWEBOK V3.0 is the most recent completely revised and updated version of the internationally respected Guide to the Software Engineering Body of Knowledge. Newly imagined as a living, changing document, and thoroughly rewritten, SWEBOK V3.0 has been developed and created by leading authorities, reviewed by professionals, and made available for public review and comment, continuing its 20-year reputation as the most authoritative, fundamental, and trusted definition of the software engineering profession. SWEBOK V3.0 is comprised of 15 Knowledge Areas, plus a new Appendix on Standards."
I've known for a long time the PMBOK (for Project Managers, a very interesting resource if you're interested on that part of software construction and the basis for certification) but this resource is a lot less talked about.
Give it a look.
Quality Attributes: INVEST on Proper User Stories
User Stories (US) are important Product Backlog Items (PBI) on Scrum.
When they are deemed "Ready" this means that they are ready to be inserted in the scope of a Sprint. When they are not ready, this means that the appropriate level of detail (and peer review) was not yet achieved. They were not yet subject to "refinement" (previous terminology included the term "Product Backlog Grooming"). As a developer don't touch them.
When they are "Done" this means they are ready for the PO approval.
The definition of "Done" is an important part of Scrum (relates to transparency) and deserves a full section on the Scrum Official Guide. There could also be a Definition of Ready (but this is optional).
PS. The latter link has a variant definition for the SMART Acronym for requirements: SMART tasks.
When they are deemed "Ready" this means that they are ready to be inserted in the scope of a Sprint. When they are not ready, this means that the appropriate level of detail (and peer review) was not yet achieved. They were not yet subject to "refinement" (previous terminology included the term "Product Backlog Grooming"). As a developer don't touch them.
When they are "Done" this means they are ready for the PO approval.
The definition of "Done" is an important part of Scrum (relates to transparency) and deserves a full section on the Scrum Official Guide. There could also be a Definition of Ready (but this is optional).
The INVEST model
Each and every user story shall possess the INVEST quality attributes. Refine an Epic into User Stories and before considering them "Ready" make sure that the INVEST model is applicable to each one of the user stories you are working on:- The INVEST acronym (for Scrum US): https://en.wikipedia.org/wiki/INVEST_(mnemonic)
- The original article from Bill Wake (author of the "Exploring Extreme Programming" XP123 blog) can be found here: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
PS. The latter link has a variant definition for the SMART Acronym for requirements: SMART tasks.
sexta-feira, 8 de abril de 2016
BOOK: Xamarin (Charles Petzold) | Free
https://blogs.msdn.microsoft.com/microsoft_press/2016/03/31/free-ebook-creating-mobile-apps-with-xamarin-forms/
Quoting:
"Microsoft Press, in cooperation with Xamarin, is pleased to publish a new ebook by legendary author Charles Petzold: Creating Mobile Apps with Xamarin.Forms: Cross-platform C# programming for iOS, Android, and Windows."
Free PDF here: http://aka.ms/xamebook
Quoting:
"Microsoft Press, in cooperation with Xamarin, is pleased to publish a new ebook by legendary author Charles Petzold: Creating Mobile Apps with Xamarin.Forms: Cross-platform C# programming for iOS, Android, and Windows."
Free PDF here: http://aka.ms/xamebook
quinta-feira, 7 de abril de 2016
BOOK: Xamarin Free Ebook from Charles Petzold and MS
https://blogs.msdn.microsoft.com/microsoft_press/2016/03/31/free-ebook-creating-mobile-apps-with-xamarin-forms/
Quoting:
"Microsoft Press, in cooperation with Xamarin, is pleased to publish a new ebook by legendary author Charles Petzold: Creating Mobile Apps with Xamarin.Forms: Cross-platform C# programming for iOS, Android, and Windows."
Free PDF here: http://aka.ms/xamebook
About Xamarin: https://www.xamarin.com/
Quoting:
"Microsoft Press, in cooperation with Xamarin, is pleased to publish a new ebook by legendary author Charles Petzold: Creating Mobile Apps with Xamarin.Forms: Cross-platform C# programming for iOS, Android, and Windows."
Free PDF here: http://aka.ms/xamebook
About Xamarin: https://www.xamarin.com/
terça-feira, 5 de abril de 2016
Agile/Scrum software development
Agile / Scrum is being more and more widely used as a methodology for developing software.
There are lots of resources on agile/scrum. I will simply list some of the main resources for future reference:
There are lots of resources on agile/scrum. I will simply list some of the main resources for future reference:
- The agile manifesto: http://agilemanifesto.org/
- The main principles: http://agilemanifesto.org/principles.html
- Some "history" can be found here: https://en.wikipedia.org/wiki/Agile_software_development
- The scrum guide (official) can be found here: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
Personally, I like the simplicity of the thing (but please bear in mind that agile is not suitable for all development - more on that at the end of this topic). Sometimes the world is changed by people "thinking out of the box". These people (listed here) started in the nineties thinking on alternatives to Waterfall methodologies. Waterfall and other more classic methodologies fit well into mature markets (aerospace, railway and transportation, amongst other), but are not so suited for low level maturity clients, customers that don't know very well what they want (but do not mind paying for the changes they request), product development, research and development as well as other "fast changing" projects.
And as we know that "change is part of life", why not having a way of dealing with it elegantly, or at least with a little "less drama" (scope negotiations, contract negotiations that may do more harm than good to your relationship with the customer)?
Subscrever:
Mensagens (Atom)