MAKING INDUSTRY LEVEL SOFTWARES

transcript

Ericsson Internal | 2013-04-23 | Page 2

› András Boráros-Bakucz– Program manager, Ericsson Hungary– boraros-bakucz.andras@kvk.uni-obuda.hu– Phone: +3630 343 9136

› Presentation format is intentional

whoami

› Bevezetés, probléma megfogalmazás, megoldási paradigmák

› A szoftver mint termék előállításának folyamata, a szoftver életciklus modelljei

› Szoftverfejlesztés életciklus modellje, különféle modellek összehasonlítása (vízesés, V-modell, spirál modell, evolúciós modell)

› A szoftverfolyamat alapvető tevékenységei› A szoftverfejlesztés lehetőségei, tervezési módszerek

Topics

› “Software has too many dimensions to combine within a single framework.”http://esriindia.com/Events/UC_2012/developers_meet.html

› Development› Maintenance› Publication/deployement› Services (support, administration)› Training› Documentation› Consulting

Software Industry

› https://www.gnu.org/philosophy/words-to-avoid.en.html#SoftwareIndustry

Critics of Term: Software Industry

› 1955: Computer Usage Company

› 1960s: Big Bang, computers mass-production

› DEC low-priced microcomputer onto market

History #1

› IBM AS/400› 1970s: IBM PC, “desktop”› 1980s: flip form factor, so

laptops, notebooks, netbooks, tablets, handheld, smartphones

History #2

› Global Software Top 100

› http://www.softwaretop100.org/global-software-top-100-edition-2011

The Biggest Ones

› Core competency of the vendor - For example, when an organization is looking for vendors it would certainly be beneficial to go for vendors who specialize in these projects. However, giant IT companies could be an exception as they specialize in multiple technologies.

› Number of years in business - This helps organization understand the credibility of the business.

› Stock market listing - Important if the size of the project is huge as a listed software vendor is more likely to have better governance processes

› Overall and available vendor headcount - This can help organizations to decide how their resources requirements can be met by the software vendor.

Evaluating software vendors #1

› Vendor credentials - The software vendor's prior experience in similar projects can increase the confidence of the organization

› Industry Certifications/awards/Alliance partners - Industry recognition is another parameter for evaluating the software vendors

› Local and global offices - While local office is important for any meetings, follow ups etc. global offices show the reach of the vendor

› Project management/tracking processes - More robust the processes are, better will be quality of the software product

› Lead times to start development - The vendor might have a lot of projects on hand already and it is important for an organization to know the lead times

› Core solution and solution options - The software vendor should be made to make a presentation to showcase vendor's understanding of the requirements

› Development time and costs - The estimates for efforts, resources, schedule and costs (includes fees and expenses)

› Non functional requirements - The vendor's ability to meet non functional requirements

› Warranty support agreements - For post production break fixes› Post go live - Maintenance activities support costs

headcount, governance, processesProject management, requirementscostsnon-functional requirements (architecture, ities, qualities, stability, portability)Execution qualitiesEvolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system9999go live

› Operating system (system software)

› Platform (middleware)› Application software› Embedded software

Types of Software

› Proprietary (off-the-shelf, custom)› Freeware (free as a beer)› Open-source› Shareware› Malware› Adware

Software licensing

System Development Lifecycle

Project planning, feasibility study

Systems analysis, requirements

definition

Systems designImplementation,software design

Integrationand testing

Acceptance,installation,deployment

Maintenance

System Development Lifecycle

Project planning, feasibility study

Systems analysis, requirements

definition

Systems designImplementation,software design

Integrationand testing

Acceptance,installation,deployment

Maintenance

SDLC – Close to Reality

› Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.

› Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

› Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.

› Implementation: The real code is written here.

› Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

› Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.

› Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

› http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle

› Waterfall might be useful in case of well determined req.-s and plans, but extreme could be better for less well defined requirements and prject plans

› Requirements› Specification› Architecture› Construction› Design› Testing› Debugging› Deployment› Maintenance

Activities and Steps

› Processes and regular activities (loops) always need additional efforts/people (cost)

› Means expensive…› But quality is a “must”…

– Or “good enough” quality?

› Processes– Good designer, bad designer

› Prepare for average designers

– No need for process if SW developed by one person

– Quality is far less a question indeed if someone knows the whole software alone

Problem of Processes

› RUP› XP› Agile› Lean› Dual Vee Model› TDD› FDD

› Waterfall› Prototype model› Incremental› Iterative› V-Model› Spiral› Scrum› Cleanroom› RAD› DSDM

Methodologies

› Supporting organizations/activities– Configuration management

› Version control– Bugs handling, trouble report handling

› Internal end external– Documentation

› Storage space– Quality assurance (SQA)– Project management

› PNP or other stuff– User experience design

Support Functions

› Early phase› Execution

– Design– Integration– Test

› Delivery and Deployment› Support and maintenance

Software Development Phases

› Ericsson’s answer– Product management– Project management– Program management– Product lines– Matrix organization– Line management

› System management

Software Development Organizations

› A customer needs a new feature› Contact local market support office› Contact product management› Product management creates a requirement

– Preferably in a requirement handling tool

› Requirement screening, pre-analysis if possible at all– Worth to invest further analysis

› After a set of requirements collected a project is going to be started to implement the requirements

– A kind of formal decision is good to have– PjM books always propose a kick-off meeting

A Requirement is born

› Analyze and define more precise requirements – Requirement specification

› Make a technical analysis› Make an effort/cost/time estimation› Done by so called: system management› Output can be:

– Quick scan, One pager, Implementation Proposal, Technical Review

– Contains some design aspects but not fully details– Necessary contains interfaces

Early Phase

› Depending of project type customer or product management orders the implementation of the analyzed feature

› Teams and individuals start coding based on IP/TER etc.› Design rules› Code formatting› Libraries› Design patterns› Editor and support tools (CPPCheck, Coverity)› Requirement freeze, Code freeze

Execution Phase,Design

#include <iostream>using namespace std;

int main (){ cout << "Hello World!"; return 0;}

#include <iostream>using namespace std;

int main (){ cout << "Hello World!"; return 0;}

Editors

› Integrating the different elements done in different levels› Version control

– Choose a version control system for your project

› Labeling› LSV concept, LLV concept› Continuous integration

– Regular compilation– Regular legacy testing

› One-track concept

Execution PhaseIntegration

› Design Follow-up (DFU)› Verification types

– Unit test/Basic test– Component test– Function test– Early system test– Node system test (I&V)– Solution, multi-node system test

Execution Phase,Verification

› PRA– Product Release A

› FOA– First Official Application

› PRB/PRG– Product Release B/General

availability

› TLA– …?– http://cygwin.com/acronyms

› Release the software– Make it available for customer– Usually the dump and some

basic configuration– Upgrade and install package

(do not underestimate the importance of a smooth upgrade)

Delivery AndDeployment

› WLA– Working Level Agreement

› 3rd line support› External/customer TR-s› Change requests› Correction packages

– Content management

› Emergency packages

Support and Maintenance

Exploits of a Mom

http://xkcd.com/327/

MAKING INDUSTRY LEVEL SOFTWARES

Documents