terça-feira, 31 de outubro de 2017

Standards: Safety Critical what?

About safety critical and the most common standards to comply with:
"The Safety Critical technical area addresses the analysis, development, verification and validation of software and systems that are classified as either safety- or mission-critical.

Systems classified as safety-critical are those where failure may lead to personal injuries, fatalities or harmful effects to the environment. Airborne systems in aircraft and signalling systems in railway are traditionally the best-known cases of safety-critical systems. Systems controlling industrial processes in chemical, petrochemical and nuclear plants are also in this category.
Mission-critical systems are those where failure may lead to either loss or major degradation of the mission performance. Traditionally the best known cases of mission-critical systems are unmanned space missions such as telecommunications and scientific satellites, and the energy production and distribution infrastructure.
Enterprise systems in banking, retail and other industries may also be considered mission-critical though we prefer to designate them ‘business-critical’.

The services delivered by the Safety Critical technical area aggregate a set of disciplines and technology that is closely related to international safety standards. These standards are a daily reference in the work performed by the Safety Critical technical area. The most common standards used are for aerospace: ARP-4754, ARP-4761, DO-178B and DO-178C, and DO-254; for railway: EN-501216, EN-50128 and EN-50129; for space ECSS-E-ST-40C and ECSS-Q-ST-80C; for automotive the ISO 26262 and for industrial systems in general IEC 61508.

The work performed by the Safety Critical technical area is characterised by the rigour of the engineering processes. The main challenge faced is to comply with that rigour in the most economically efficient way. The projects and activities developed by the Safety Critical technical area fall into the following categories:

  1. • Development of real-time embedded software in either full life-cycle, from requirements to final acceptance, or in partial life-cycle. Often the development entails close co-operation with the customer and in some cases members of the project team may work at the customer’s premises while interacting with the project team at home. The SW will typically be developed in either C or Ada and requires knowledge of real-time operating systems, microprocessor architectures and low-level communication protocols. 
  2. • Verification and validation of real-time embedded software, from requirements and code reviews, to unit tests, integration and system tests. A full life-cycle embedded software development also includes V&V but this type of service is often delivered as specific projects, where we verify and validate software developed by the customer or a third party. The V&V services include not only testing software but also testing with hardware-in-the-loop. Typical tools used include VectorCAST, LDRA and bespoke validation facilities. 
  3. • Development of integrated electronic systems comprising the software and the hardware that supports it. This requires competencies in both software and electronics, including the ability to procure and integrate COTS components. Typical systems developed include validation facilities with HW-in-the-loop and solutions for military C&C systems. 
  4. • Functional safety assessment and reliability prediction (known as RAMS). This entails analysing the failure modes of systems using techniques such as Fault Tree Analysis (FTA) and Failure Mode Effects Analysis (FMEA). This analysis may contribute to both allocate criticalities to components and to reformulate the system design to minimise the number of critical components. 
  5. Certification support to help our customers comply with safety-critical standards and training on those standards. This implies a wide body of knowledge in the technical, normative and application domain. 

Typical projects include certification support for railway signalling systems, support for airborne software and hardware certification and training on standards such as DO-178C. The work in the Safety Critical technical area requires interest in safety aspects, the ability to analyse systems as a whole, to know that there is more than just software development and, of course, good reading and writing skills."

[INTERNAL] Source: CSW-QMS-2000-CPD-0174, VERSION: 13, 2017-08-09, Annex B.

segunda-feira, 30 de outubro de 2017

REPORT: 2017 State of DevOps report

https://puppet.com/resources/whitepaper/state-of-devops-report

Quoting:
"Over the past six years and more than 27,000 State of DevOps survey responses, we’ve found clear evidence that DevOps practices yield remarkable results for IT teams and organizations.

This year we also discovered new findings about transformational leadership, automation practices, continuous delivery, lean product management, and DevOps in not-for-profits and organizations that use off-the-shelf software.

Here are a few things you’ll learn in this year's report:

- How DevOps practices affect deployment frequency, lead time, change failure rate and MTTR
- The influence leadership has on DevOps transformations
- How high- and low-performing teams automate differently
- The impact of architecture and team structure on IT performance
- How DevOps helps organizations reach both their financial and non-financial goals."

sábado, 28 de outubro de 2017

Autonomous Vehicles: Open sourced? (Apollo 1.0 self-driving car software)

https://github.com/ApolloAuto

Source:
https://www.cnet.com/roadshow/news/open-source-apollo-speeds-up-baidus-self-driving-software-development/

Quoting:
"In July, Chinese technology company Baidu made its Apollo 1.0 self-driving car software available as open source on Github, using the Apache/BSD license. By Day 4 of the release, it was the most downloaded C++ software on the site.

At an Apollo meetup hosted by Baidu at its Sunnyvale, California, offices, company president Ya-Qin Zhang announced Apollo 1.5, a major iteration of the software, just three months after the initial release."

quinta-feira, 26 de outubro de 2017

Security: Sonar (Open Source MS Tool)

https://thenextweb.com/apps/2017/10/26/microsoft-launches-sonar-to-test-your-sites-performance-and-security/

Quoting:
"Enter your project’s URL, and Sonar will comb through it for accessibility, interoperability, performance, security and progressive web app-related issues. Once it’s done scanning, it’ll list the errors it’s found and do its best to explain what’s going wrong, highlighting the errant code snippets and offering possible solutions.
(...) Sonar improves on the capabilities of other linting tools by executing your website code in a container instead of simply performing a static analysis for more accurate results, as well as allowing for integration with other services. And if you don’t care to use Sonar in your browser, you can also invoke its command-line interface."

quarta-feira, 25 de outubro de 2017

BOOK: "The Road Map to Software Engineering: A Standards-Based Guide"

Another Software Development / Software Engineering book FFR:
The Road Map to Software Engineering: A Standards-Based Guide: 9780471683629: Computer Science Books @ Amazon.com

Quoting:
"The Road Map to Software Engineering: A Standards-Based Guide organizes relevant IEEE software and systems standards using two frameworks: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard. This useful guide is endorsed and recommended by the Software and Systems Engineering Standards Committee of the IEEE Computer Society for both practitioners and students."

BOOK: Software Engineering Standards: C. Mazza, J. Fairclough, B. Melton, D. De Pablo, A. Scheffer

A very good summary (the book is thin because topics are handled at a high level perspective and assume you are already a software engineer) of the ESA/ECSS standards:

Software Engineering Standards: C. Mazza, J. Fairclough, B. Melton, D. De Pablo, A. Scheffer: 9780131065680: Amazon.com: Books

Quoting:
"These standards define the essential aspects of software development and have been produced by removing all space-specific aspects from the European Space Agency's software engineering standards. They cover the whole software engineering process at a uniform level of abstraction."


Reuse: Global Mapper SDK (4DMapper)

4DMapper is a geospatial cloud-based SDK (referred in a press release):
https://www.suasnews.com/2017/10/4dmapper-chooses-global-mapper-software-development-kit-sdk-online-analytics/

More details, quoted:
"Global Mapper Software Development Kit (SDK) as the engine behind its online data analytics services. The company’s innovative cloud-based approach to geospatial data creation and distribution reduces the need for their customers to maintain high-end processing hardware and software and it simplifies and streamlines access to the processed data. By making use of a collection of Global Mapper’s powerful 3D data manipulation tools, 4DMapper users can quickly and easily convert a point cloud into contours, generate an elevation grid, and much more."
(...)
"Among the tools available to 4DMapper customers are LiDAR ground point identification and reclassification; DEM creation from a point cloud; custom contour generation; and delineation of ridgelines. Each of these workflows involves the uploading of the relevant source data and results in the creation of a derivative file that can be quickly and easily shared with a customer or client on a web browser."

terça-feira, 24 de outubro de 2017

BOOK: "Extreme Programming Explained: Embrace Change, 2nd Edition" (The XP Series) - Kent Beck

The definitive guide to XP is the book by the author (Kent Beck):
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
2nd Edition, ISBN-13: 978-0321278654, ISBN-10: 0321278658

PS. Additional info about XP, considered the first of the agile methodologies (long before Scrum):
https://martinfowler.com/bliki/ExtremeProgramming.html

segunda-feira, 23 de outubro de 2017

PT: Upyourstrategy (quality-related event at FEUP)

Just to let you know that a quality-related event (PT) will be hosted in FEUP in the next days, with respectable speakers:
upyourstrategy (https://www.upyourquality.com/)

BOOK: "Software Engineering: A Practitioner's Approach" (AKA SEPA)

Another bible on the subject of software engineering is:
Software Engineering: A Practitioner's Approach: Roger S. Pressman, Bruce Maxim: 9780078022128: Amazon.com: Books

Quoting:
"For almost three decades, Roger Pressman's Software Engineering: A Practitioner's Approach has been the world's leading textbook in software engineering. The new edition represents a major restructuring and update of previous editions, solidifying the book's position as the most comprehensive guide to this important subject. The chapter structure will return to a more linear presentation of software engineering topics with a direct emphasis on the major activities that are part of a generic software process. Content will focus on widely used software engineering methods and will de-emphasize or completely eliminate discussion of secondary methods, tools and techniques. The intent is to provide a more targeted, prescriptive, and focused approach, while attempting to maintain SEPA's reputation as a comprehensive guide to software engineering. The 39 chapters of this edition are organized into five parts - Process, Modeling, Quality Management, Managing Software Projects, and Advanced Topics. The book has been revised and restructured to improve pedagogical flow and emphasize new and important software engineering processes and practices."

PS. Kudos to M. Serra for pointing this out (used at ISEL, PT)
PS2. This is also the book being used at ISEC, PT here.

Some info about RUP (Rational Unified Process)

The Short Story

A summary on RUP (an iterative software development process) can be found here (FFR):
The typical summary image can be found in the site above:

The Long Story - The Rational Unified Process
Quoting the "Object Oriented Analysis and Design with Applications" book :
"In its simplest form, RUP consists of some fundamental workflows:
1. Business Engineering. Understanding the needs of the business.
2. Requirements. Translating business need into the behaviours of an automated system.
3. Analysis and Design. Translating requirements into a software architecture.
4. Implementation. Creating software that fits within the architecture and has the required behaviours.
5. Test. Ensuring that the required behaviours are correct, and that all required behaviours are present.
6. Configuration and change management. Keeping track of all the different versions of all the work products.
7. Project Management. Managing schedules and resources.
8. Environment. Setting up and maintaining the development environment.
9. Deployment. Everything needed to roll out the project.
These activities are not separated in time. Rather, they are executed concurrently throughout the lifetime of the project. As we see in [the RUP typical image process representation], not much code gets written early in the project lifecycle; but the amount is not zero. Late in the project, most of the requirements are known, but some new ones are still identified.
(…)
Iteration
A project governed by a RUP process moves forward in increments called iterations.
The goal of each iteration is to develop some working software that can be demonstrated to all the stakeholders, and that the stakeholders will find meaningful. The software developed by an iteration should cut through all or most of the major subsystems of the project.
(…)"
Source: [Object Oriented Analysis and Design with Applications, 2d. ed., Grady Booch, Robert C, Martin, James Newkirk]

RUP defends iterations and additional mandatory workflows (management ones for instance): Configuration and change management. Project Management. Environment is also an important issue (deployment deals with the change to production environment). There is an evident overlapping of Requirements and Design in the Elaboration phase (identification of architectural requirements).

sexta-feira, 20 de outubro de 2017

TOOLS: Pencil (rapid Prototyping tools - for mockups creation as well as live feature navigation)

A tool has been pointed out to me (free at the time of posting) and requiring installation (as opposed to some similar web-based tools):
https://pencil.evolus.vn/

Quoting:
"An open-source GUI prototyping tool that's available for ALL platforms.
Pencil is built for the purpose of providing a free and open-source GUI prototyping tool that people can easily install and use to create mockups in popular desktop platforms.
The latest stable version of Pencil is 3.0.4 which contains stability fixes and features a visual stencil builder. More details can be found in the release notes."

PS. About rapid prototyping (tools):
On Software Development (or "O Sr. SiIva disse..."): TOOLS: Rapid prototyping tools (for mockups creation as well as live feature navigation)

PS2. Also make sure to look at the MS tool (Sketchup in MS Expression Studio):
https://msdn.microsoft.com/en-us/library/ee341458(v=expression.40).aspx


PS. Kudos to Vera Moreira for pointing this one out.

quinta-feira, 19 de outubro de 2017

Books on Requirements?

For everything in life, there's a book. I even found some book for good friends of mine who ride the bicycle (that went something like "how to not ruin your sex life riding bikes"). Unfortunately a search for it in the Amazon store today does not yield results.

And then, there are good books on writing good requirements.

Some of them are pretty much old but they are still good books on the subject (this is an "old" art):
PS: Some classical papers on requirements:


Additional references (sources for the INTERNAL QMS ENG02 Process) 

The main conceptual references for the process description, back in 2003, were:
Guide to the user requirements definition phase, ESA PSS-05-02 Issue 1 Revision 1 (1995).
Guide to the software requirements definition phase, ESA PSS-05-03 Issue 1 Revision 1 (1995).
Space engineering – Software, ESA ECSS-E-40B Draft 1 (2002)
Some additional references used were:
Managing Software Requirements: a unified approach, Dean Leffingwell, Don Widrig, 2000, Addison-Wesley
Mastering the Requirements Process, Suzanne and James Robertson, 1999, Addison-Wesley
Modelling for requirement engineering, Dr. Eric Conquet, 2002, ESA / ESTEC TOS- EME
Specifying Good Requirements, Donald Firesmith, in Journal of Object Technology, vol. 2, no. 4, July-August 2003, pp. 77-87. http://www.jot.fm/issues/issue_2003_07/column7

@2017-11, additional sources for QMS PCS. 



terça-feira, 17 de outubro de 2017

BOOK: Essentials Of Software Engineering: Frank Tsui, Orlando Karam, Barbara Bernal

Essentials Of Software Engineering: Frank Tsui, Orlando Karam, Barbara Bernal: 9781284106008: Amazon.com: Books

Quoting:
"Written for the undergraduate, one-term course, Essentials of Software Engineering, Fourth Edition provides students with a systematic engineering approach to software engineering principles and methodologies. Comprehensive, yet concise, the Fourth Edition includes new information on areas of high interest to computer scientists, including Big Data and developing in the cloud.

In-depth coverage of key issues, combined with a strong focus on software quality, makes Essentials of Software Engineering, Fourth Edition the perfect text for students entering the fast-growing and lucrative field of software development. The text includes thorough overviews of programming concepts, system analysis and design, principles of software engineering, development and support processes, methodologies, software testing and quality, and product management, while incorporating real-world examples throughout."

PS. Kudos to G. Silva for pointing this out (being used at ISEC).


segunda-feira, 16 de outubro de 2017

LIST: RIA and Mobile Web Based frameworks

https://en.m.wikipedia.org/wiki/Multiple_phone_web-based_application_framework

A broader category list:
https://en.m.wikipedia.org/wiki/List_of_rich_Internet_application_frameworks

Mobile: Apache Cordova

https://en.m.wikipedia.org/wiki/Apache_Cordova

Quoting:
"Apache Cordova (formerly PhoneGap) is a mobile application development framework originally created by NitobiAdobe Systems purchased Nitobi in 2011, rebranded it as PhoneGap, and later released an open source version of the software called Apache Cordova.[3] Apache Cordova enables software programmers to build applications for mobile devices using CSS3HTML5, and JavaScript instead of relying on platform-specific APIs like those in AndroidiOS, or Windows Phone.[4] It enables wrapping up of CSS, HTML, and JavaScript code depending upon the platform of the device. It extends the features of HTML and JavaScript to work with the device. The resulting applications are hybrid, meaning that they are neither truly native mobile application (because all layout rendering is done via Web views instead of the platform's native UI framework) nor purely Web-based (because they are not just Web apps, but are packaged as apps for distribution and have access to native device APIs). Mixing native and hybrid code snippets has been possible since version 1.9."

Mobile: Ionic framework

https://en.m.wikipedia.org/wiki/Ionic_(mobile_app_framework)

Quoting:
"Ionic is a complete open-source SDK for hybrid mobile app development.[4] The original version was released in 2013 and built on top of AngularJSand Apache Cordova. The more recent releases, known as Ionic 2 or simply "Ionic", are built on Angular. Ionic provides tools and services for developing hybrid mobile apps using Web technologies like CSSHTML5, and Sass. Apps can be built with these Web technologies and then distributed through native app stores to be installed on devices by leveraging Cordova. Ionic was created by Max Lynch, Ben Sperry, and Adam Bradley of Drifty Co. in 2013.[5]"

See also: [Microsoft] Xamarin

Standards: NASA Technical Standards

And the family of standards for NASA - systems engineering, i.e. not only software development - can be found below (a similar roadmap to ESA ECSS standards can be found here).

https://standards.nasa.gov/nasa-technical-standards (following some links to the standards inside this link might require login)

Quoting:
"Each NASA Technical Standard is assigned to a Technical Discipline. Please select the respective link to access that discipline's standards.

0000 - Documentation and Configuration

1000 - Systems Engineering and Integration, Aerospace Environments, Celestial Mechanics

2000 - Computer Systems, Software, Information Systems

3000 - Human Factors and Health

4000 - Electrical and Electronics Systems,  Avionics/Control Systems, Optics

5000 - Structures/Mechanical Systems, Fluid Dynamics, Thermal, Propulsion, Aerodynamics

6000 - Materials and Processes, Parts

7000 - System and Subsystem Test, Analysis, Modeling, Evaluation

8000 - Safety, Quality, Reliability, Maintainability

9000 - Operations, Command, Control, Telemetry/Data Systems, Communications

Any questions on the above standards can be directed to the NTSS Curator at standards@msfc.nasa.gov"

And the relevant links are...

Maintenance categories (applicable to SW development, of course):

About SDP and life cycles (some not widely used nowadays):

ENG QMS Process example (for TOC analysis, INTERNAL):
  • https://quality.critical.pt/qmsunified/ENG-engineering/ENG01-requirements-analysis/CSW-QMS-2005-PCS-3424-requirements-analysis.pdf#search=eng01

STANDARDS: Recommended approach to software development, revision 3 : Landis, Linda : Free Download & Streaming : Internet Archive

The NASA JPL recommended approach to SW development (PDF) is "oldie but goldie" and stated as consistent with NASA/GSFC standards:



Quoting:
"Guidelines for an organized, disciplined approach to software development that is based on studies conducted by the Software Engineering Laboratory (SEL) since 1976 are presented.

It describes methods and practices for each phase of a software development life cycle that starts with requirements definition and ends with acceptance testing.

For each defined life cycle phase, guidelines for the development process and its management, and for the products produced and their reviews are presented.

Documentid 19930009672"

And some relevant links include...


The NASA report about the (failed Mars mission) Mars Climate Orbiter and the ICD/ICS problem:

About risk management in SW Development (a NASA doc) and why it is important to do it  - see next link:

And some relevant links include...

About software end of life (or not, and the 400 USD billions spent):
https://en.wikipedia.org/wiki/Year_2000_problem

Mars missions and the diffcult path to Mars:
https://en.wikipedia.org/wiki/List_of_missions_to_Mars
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
https://en.wikipedia.org/wiki/Deep_Impact_(spacecraft)#Contact_lost_and_end_of_mission

NASA report on the ICD/ICS problem:
https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf

About risk management (NASA):
http://csse.usc.edu/csse/event/2009/UARC/material/Macro%20Risk%20Model.pdf

And some relevant links include...


About SDP and life cycles (some not widely used nowadays): 
Make sure you also read about TDD, RUP, etc.

About risk management in SW Development (a NASA doc) and why it is important to do it  - see next link:

And the NASA report about the (failed Mars mission) Mars Climate Orbiter and the ICD/ICS problem:

Maintenance categories (applicable to SW development, of course):

ENG QMS Process example (for TOC analysis, INTERNAL):
  • https://quality.critical.pt/qmsunified/ENG-engineering/ENG01-requirements-analysis/CSW-QMS-2005-PCS-3424-requirements-analysis.pdf#search=eng01


sexta-feira, 13 de outubro de 2017

SW Design: Composable Apps vs. Monolithic COTS

http://www.computerweekly.com/feature/How-composable-application-can-improve-software-development

Quoting:
"They now talk about the merits of ‘composable’ applications.

Composable applications is the idea that the functional blocks of an application can be decoupled from the complete applications. These individual component parts can then be more finely tuned to create a new application that is ideologically, if not also functionally,  greater than the sum of its parts."

Agile: Allianz started using agile?

...And the team got to choose even the development stack (for the sake of productivity they are not using the company standard stack, Java-based):
http://www.computerweekly.com/news/450428018/Why-agile-teams-prefer-to-bring-their-own-development-tools-to-projects

A description of the technological stack (and the processes -and tools- being used by the team can be found above). A summary is quoted here:

Quoting:
""The team gets to decide which tools fit best with the way we work.”

Cool new language

For instance, the team chose to develop the Android version of its app using Kotlin, a new Android scripting language, rather than adopt the corporate standard, Java, he said. “We just though it was a cool new language and saw its potential to make us code faster.”
(...)
She said it is important for the toolsets to fit in with what the developer wants to do, rather than the developer needing to change their way of working to fit in with the toolset.

Insurer Allianz has begun shifting to a more flexible approach to software development. A project team at the company explained its approach to developing a new mobile app during the keynote presentation at the summit.

Sarah Heldt, product owner at Allianz, said: “Whenever a big company wants to launch a new product, there are a gazillion requirements – you have to fill in a tonne of documents, the application takes forever to deploy and by the time it goes to market, it is already outdated.”

Heldt said Allianz is on a journey to reduce this effort by moving from waterfall to lean software development. Its team, which comprises five developers and a designer and has Heldt as the team owner, began work 18 months ago. The company worked with Pivotal to change the way the team worked.

“We embraced a lean startup methodology, which means we produce work based on a minimal viable product,” said Heldt. “It’s our goal to achieve technical excellence and true customer-centricity. Before we start developing a user story, we think about the business value behind this story.”

Real users’ sentiment

The team also dovetails its developer process with user testing to gauge real users’ sentiment about the software development, which can then be fed back to improve the app in its next iterative release, she said.

Speaking about the shift in developer methodology, the team’s designer, Denis Kostic, said the team is organised so that everyone can sit along the same table to work together. Each team member’s opinion matters, he said.

Kostic said the team avoids having too many meetings, generally unplugs telephones to avoid having long meetings, and produces work based on short user stories. “We like to put Post-it notes on the wall and we literally have to stand up to present our ideas and learnings, not only to our team-mates but also to our stakeholders,” he said.

User tests take place at least once a month to enable the team to test new features before they are released to production. “Our number one priority is to provide further value in the app for customers,” said Kostic.

The team’s developer, Simon Neusser, said: “Although we are a small team, we use a large variety of tools and technologies. The improtant thing is that we are in charge of our development tool stack. The team gets to decide which tools fit best with the way we work.”

Cool new language

For instance, the team chose to develop the Android version of its app using Kotlin, a new Android scripting language, rather than adopt the corporate standard, Java, he said. “We just though it was a cool new language and saw its potential to make us code faster.”

The Allianz team operates with a DevOps mindset. The native Android and Apple apps use APIs (application programming interfaces) hosted on Cloud Foundry, to work as a service interaction layer to access customer and insurance agent information from back-end Allianz systems.

“After we build it, we have to be able to run it,” said Neusser. What is important here, he said, is the ability to optimise the parts of the DevOps process that do not add any value.

One example is the build pipeline, where Allianz has used automation tools such as Jenkins, said Neusser. When a story is completed, the resulting source code is pushed up to the team’s GitHub code repository, where the build pipeline automatically runs, building the project, and runs more than 1,000 automated tests. If the tests are completed successfully, the app is pushed on to Cloud Foundry or directly to the Android app store.

What the Cloud Foundry Summit shows is that now is the time for corporate developers to rise to the challenge and opportunity presented by digitisation. DevOps and agile are clearly key ingredients to success, but as the team from insurer Allianz has found, the flexibility to use its prefered tools rather than those set by the corporate standard is an important consideration.""

quinta-feira, 12 de outubro de 2017

Maintenance: The Y2K problem and the 417 Billion USD spent (!) because of the year 2000

And the eternal question: Were the millions spent to fix the Y2K bug well spent? Well, maybe so because in the end the world did not end!

Interesting details on the technical parts, the bugs that really caused some problems, and the government initiatives that were made to avoid problems from occurring:
https://en.wikipedia.org/wiki/Year_2000_problem

Quoting (interesting parts):
"The U.S. Government also established a Center for Year 2000 Strategic Stability, as a joint operation with the Russian Federation. It was a liaison operation designed to mitigate the possibility of false positive readings in each nation's nuclear attack early warning systems."
(...)
"No banks failed, no planes crashed, no wars or civil war started. And yet not one of these prophets of doom has ever apologised for their scare-mongering tactics."[55] Some prominent North American Christian ministries and leaders generated huge personal and corporate profits through sales of Y2K preparation kits, generators, survival guides, published prophecies and a wide range of other associated merchandise. Christian journalist, Rob Boston, has documented this[50] in his article "False Prophets, Real Profits Religious Right Leaders' Wild Predictions of Y2K Disaster Didn't Come True, But They Made Money Anyway""
(...)
"The total cost of the work done in preparation for Y2K is estimated at over US$300 billion ($417 billion today, once inflation is taken into account).[57][58] IDC calculated that the US spent an estimated $134 billion ($186 billion) preparing for Y2K, and another $13 billion ($18 billion) fixing problems in 2000 and 2001. Worldwide, $308 billion ($428 billion) was estimated to have been spent on Y2K remediation.[59]"

PS: A similar problem on a space mission that did have impact on the mission: 
"The Deep Impact space mission was lost when its internal clock reached exactly 232 one-tenth seconds since 2000 on 11 August 2013, 00:38:49."

SW Maintenance: Change request

A CR is what has to be written (by us or sent by the customer) every time a system is under Change Management (e.g. after delivery) and you need to keep track of what needs to be altered. If it is under the project/maintenance contract scope it will not be charged to the customer. Otherwise, there'll have to be a new proposal (sometimes also called "change requests (proposals)" - with a price tag on it - that the customer shall approve formally before we proceed with any change whatsoever):

Change request - Wikipedia

An impact analysis could have to be done (in all aspects/deliverables of the system). The sum of the hours accounted in the PIA will be used to reach the final cost. This is why later a CR appears in the waterfall lifecycle the more expensive it will be (more artifacts - already approved or still being developed - will have to be reworked accordingly).

Quoting the several names that the CRs can have (other than CR and Software Change Request - SCR and Contractual Change Notice - CCN):

"Change requests have many different names, which essentially describe the same concept:
  • Request For Change (RFC) by Rajlich (1999); RFC is also a common term in ITIL (Keller, 2005) and PRINCE2 (Onna & Koning, 2003).
  • Engineering Change (EC) by Huang and Mak (1999);
  • Engineering Change Request (ECR) at Aero (Helms, 2002);
  • Engineering Change Order (ECO) by Loch and Terwiesch (1999) and Pikosz and Malmqvist (1998). Engineering Change Order is a separate step after ECR. After ECR is approved by Engineering Department then an ECO is made for making the change;
  • Change Notice at Chemical (Helms, 2002); 
  • Action Request (AR) at ABB Robotics AB (Kajko-Mattson, 1999);
  • Change Request (CR) is, among others, used by Lam (1998), Mäkäräinen (2000), Dennis, et al. (2002), Crnkovic, Asklund and Persson-Dahlqvist (2003) and at ABB Automation Products AB (Kajko-Mattsson, 1999).
  • Operational Change Request (OCR).
  • Enterprise Change Request (ECR)."


quarta-feira, 11 de outubro de 2017

Design: When design goes wrong, bad things could happen (RB211 engine)

Entire projects and/or companies could go down the drain (or take years to recover from that). Innovative designs are hard to estimate (estimation frequently is based on experience from the past and if the design is new, there is no experience to "reuse"). Read a novel here:

https://en.wikipedia.org/wiki/Rolls-Royce_RB211

On the other side, why would you want to innovate?  To be faster, or to be more (fuel) efficient, to be more reliable, etc. In one word: to gain new customers.

terça-feira, 10 de outubro de 2017

Ethics and software development?

Sure! 2 examples of lack of ethic and the damage (to the image) done: Uber and Wolkswagen:
http://www.computerweekly.com/feature/Ethical-software-development-Ask-Uber-and-Volkswagen

Quoting:
"The software reportedly presents an alternative site to customers, or people wishing to book a ride from outside these buildings, which is used to prevent officials from booking an Uber ride.

Other cities have been concerned abut the use of Greyball software
(...)
This is not the first time a company has been found to have written software explicitly to get around official tests and audits.

In May 2014, Volkswagen was found to have modified its engine management software to detect when its diesel cars were being run on an official emissions test, so that it could dial down the emissions. The carmaker effectively wrote software specifically to cheat, according to the New York Times, which wrote: “Volkswagen admitted that 11 million of its vehicles were equipped with software that was used to cheat on emissions tests.”"
(...)
"The coder wrote: “I think we need to establish a code of ethics for programmers. Doctors, social workers and even lawyers have a code of ethics, with tangible consequences for skimping on them. Why not programmers as well?

“I want to live in a world where a programmer who hasn’t agreed to follow our code of ethics has a hard time getting employed. It is simply not acceptable to write code that is harmful to users. What the hell is wrong with these people?”"

I say: oh yeah! ;)

domingo, 8 de outubro de 2017

Reuse: Add 3D printing features?

https://www.tctmagazine.com/tct-events/tct-show-uk/tech-soft-additive-manufacturing-hoops-software/

Quoting:
"HOOPS software development toolkits and Polygonica.

The company reveals that many of their partners looking to add 3D printing capability to existing products or develop new innovative ones are using the modules in lieu of developing the technology in-house."

TBC: licensing and pricing

quarta-feira, 4 de outubro de 2017

Open Source: Mass spectrometer analysis API

Open source, the good parts (like not having to implement Fourier transformations in plain Java) include open source mass spectrometry APIs:
https://www.nature.com/articles/nmeth.3959.epdf

Project in GitHub:
https://github.com/OpenMS/OpenMS

CI: Continuous integration in science projects

About CI in scientific (development) projects:
http://www.nature.com/news/collaborative-software-development-made-easy-1.22729

Quoting:
"In 2015, in an effort to save time and resources, the team took inspiration from the technology industry, automating their testing using a process called 'continuous integration'.

In continuous integration, changes to software code automatically trigger repetitive tasks, such as error-checking. Fundamentally, the process simplifies a task that diligent coders already perform. Programmers usually write lists of tests that they will run periodically to ensure that their code still works, just as Neubert's team do.

But a busy team might forget or lack the time to run them, allowing errors to creep in. Continuous integration automates that process so those checks run whenever a change is proposed, saving team members the time they would spend hunting down an error. A team running genomic analyses could spend more time at the bench, while a group developing climate-prediction software could better refine its models. That said, the resulting peace of mind is only as good as the tests themselves: a poorly designed test can still allow mistakes to pass undetected.

The process is common in the commercial and open-source sectors. A study presented at the 2016 IEEE/ACM International Conference on Automated Software Engineering in Singapore found that about 40% of the 34,544 most-popular open-source projects hosted on the coding collaboration site GitHub used continuous integration in some form."

terça-feira, 3 de outubro de 2017

BOOK: The Complete Software Developer's Career Guide


Quoting:
"Key Takeaways:
"The Complete Software Developer's Career Guide" was written for all levels of software developers to answer most of the most common questions software developer have, regarding getting starting, getting a job, learning technical skills, succeeding in the workplace and advancing their careers.
The technical skills a software developer must possess to succeed in today's software development environment are immense, but fortunately, there are plenty of resources out there to learn them.
Not all developers should start their own companies, because the risks and lack of stability is not something everyone is comfortable with, but just about all software developers can benefit greatly from working on side projects.
Today, more than ever in the software development world, teamwork is critically important.
The best way to advance your career as a software developer is to become useful, by creating value in your team and outside of your team and to learn how to build a personal brand and market yourself."
Example of skills that the author States for a web developer:
"I mean if you want to be a web developer, think of all the things you need to know.
First, you need to know some programming language, then you need to know HTML and CSS so that you can make the actual user interface of a web application.
You need to know JavaScript to make the front-end interactive - possibly a JavaScript framework.
You need to understand the web itself and how data flows over the internet: HTTP protocol, statelessness, web servers, clients, browsers.
And that's just the tip of the iceberg.
You'll want to work on a team with other developers, so you'll need to understand some kind of source control system.
How to check in and check out code, merge, branch, etc.
You'll need to know about build system and continuous integration.
And I sure hope you are testing the code you wrote, so you'll definitely need to know about testing and most likely unit-testing.
Oh, and let's not forget about the software development life-cycle and Agile or Scrum.
And while we are at it, I suppose you should know SQL and how databases work, since you'll most likely need to store some data ..."