MAKING INDUSTRY LEVEL SOFTWARES whoami Andrs BorrosBakucz Section

MAKING INDUSTRY LEVEL SOFTWARES

whoami › András Boráros-Bakucz – Section manager, Ericsson Hungary – boraros-bakucz. andras@kvk. uni-obuda. hu Ericsson Internal | 2013 -04 -23 | Page 2

Topics › 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 Ericsson Internal | 2013 -04 -23 | Page 3

Motto › “Software has too many dimensions to combine within a single framework. ” http: //esriindia. com/Events/UC_2012/developers_meet. html Ericsson Internal | 2013 -04 -23 | Page 4

Software Industry › Development › Maintenance › Publication/deployement › Services (support, administration) › Training › Documentation › Consulting Ericsson Internal | 2013 -04 -23 | Page 5

Critics of Term: Software Industry › https: //www. gnu. org/philosophy/words-to-avoid. en. html#Software. Industry Ericsson Internal | 2013 -04 -23 | Page 6

History #1 › 1955: Computer Usage Company › 1960 s: Big Bang, computers mass-production › DEC low-priced microcomputer onto market Ericsson Internal | 2013 -04 -23 | Page 7

History #2 › IBM AS/400 › 1970 s: IBM PC, “desktop” › 1980 s: flip form factor, so laptops, notebooks, netbooks, tablets, handheld, smartphones Ericsson Internal | 2013 -04 -23 | Page 8

The Biggest Ones › Global Software Top 100 › http: //www. softwareto p 100. org/globalsoftware-top-100 edition-2011 Ericsson Internal | 2013 -04 -23 | Page 9

Evaluating software vendors #1 › 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. Ericsson Internal | 2013 -04 -23 | Page 10

Evaluating software vendors #2 › 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 Ericsson Internal | 2013 -04 -23 | Page 11

Evaluating software vendors #3 › 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 Ericsson Internal | 2013 -04 -23 | Page 12 headcount, governance, processes Project management, requirements costs non-functional requirements (architecture, ities, qualities, stability portability) Execution qualities Evolution qualities, such as testabilit maintainability, extensibility and

Types of Software › Operating system (system software) › Platform (middleware) › Application software › Embedded software Ericsson Internal | 2013 -04 -23 | Page 13

Software licensing › Proprietary (off-the-shelf, custom) › Freeware (free as a beer) › Open-source › Shareware › Malware › Adware Ericsson Internal | 2013 -04 -23 | Page 14

System Development Lifecycle Maintenance Project planning, feasibility study 7 Acceptance, installation, deployment Integration and testing 6 5 1 SDLC 4 Implementation, software design Ericsson Internal | 2013 -04 -23 | Page 15 2 Systems analysis, requirements definition 3 Systems design

System Development Lifecycle Maintenance Project planning, feasibility study 7 Acceptance, installation, deployment Integration and testing 6 5 Implementation, software design Ericsson Internal | 2013 -04 -23 | Page 16 1 . s SDLC 2 s v l l de l a f o r e m 4 3 t a ive W at r e Systems analysis, requirements definition Systems design

SDLC – Close to Reality Ericsson Internal | 2013 -04 -23 | Page 17

SDLC › Project planning, feasibility study: Establishes a highlevel 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. Ericsson Internal | 2013 -04 -23 | Page 18

SDLC › 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. Ericsson Internal | 2013 -04 -23 | Page 19

Activities and Steps › Requirements › Specification › Architecture › Construction › Design › Testing › Debugging › Deployment › Maintenance Ericsson Internal | 2013 -04 -23 | Page 20 › http: //www. computerworld. com/s/arti cle/71151/System_Development_Lif e_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 project plans

Problem of Processes › 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 Ericsson Internal | 2013 -04 -23 | Page 21 › Processes and regular activities (loops) always need additional efforts/people (cost) › Means expensive… › But quality is a “must”… – Or “good enough” quality?

Methodologies › Waterfall › Prototype model › Incremental › Iterative › V-Model › Spiral › Scrum › Cleanroom › RAD › DSDM Ericsson Internal | 2013 -04 -23 | Page 22 › RUP › XP › Agile › Lean › Dual Vee Model › TDD › FDD

Support Functions › 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 Ericsson Internal | 2013 -04 -23 | Page 23

Software Development Organizations › Ericsson’s answer – Product management – Project management – Program management – Product lines – Matrix organization – Line management › System management Ericsson Internal | 2013 -04 -23 | Page 24

Software Development Phases

Software Development Phases SDLC › Early phase – Pre-analysis, analysis › Execution phase – System, architectural design – Design (development) activities – Integration – Test or verification activities › Delivery and Deployment phase › Support and maintenance phase Ericsson Internal | 2013 -04 -23 | Page 26 Maintenance Acceptance, installation, deployment Project planning, feasibility study Integration and testing Systems analysis, requirements definition Implementation, software design System design

A Requirement is born › 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 to check if possible to implement 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 – Pj. M books always propose a kick-off meeting Ericsson Internal | 2013 -04 -23 | Page 27

Early Phase › 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 interface descriptions Ericsson Internal | 2013 -04 -23 | Page 28

Execution Phase, Design › 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 #include <ios › Libraries using namespa › Design patterns int main () › Editor and support tools (CPPCheck, Coverity) { cout << " › Requirement freeze, Code freeze return 0; } Ericsson Internal | 2013 -04 -23 | Page 29

Execution Phase Integration › 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 Ericsson Internal | 2013 -04 -23 | Page 31

Execution Phase, Verification › 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 Ericsson Internal | 2013 -04 -23 | Page 32

Delivery And Deployment › 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) › PRA – Product Release A › FOA – First Official Application › PRB/PRG – Product Release B/General availability › TLA – …? – http: //cygwin. com/acronyms Ericsson Internal | 2013 -04 -23 | Page 33

Support and Maintenance › WLA – Working Level Agreement › 3 rd line support › External/customer TR-s › Change requests › Correction packages – Content management › Emergency packages Ericsson Internal | 2013 -04 -23 | Page 34

Exploits of a Mom http: //xkcd. com/327/ Ericsson Internal | 2013 -04 -23 | Page 35