1 / 48

WEEK 3

WEEK 3. 4/12/2005. TOPICS. Makeup class dates Application Development Procedures Development tools Sample C Application. Possible Dates. Topics - Linux Desktop, Sys-admin tasks 4/18 Mon 4/20 Wed 4/25 Mon 4/27 Wed. Application Development. Traditional Software Applications Env.

kenneth-smith
Download Presentation

WEEK 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WEEK 3 4/12/2005

  2. TOPICS • Makeup class dates • Application Development Procedures • Development tools • Sample C Application

  3. Possible Dates • Topics - Linux Desktop, Sys-admin tasks • 4/18 Mon • 4/20 Wed • 4/25 Mon • 4/27 Wed

  4. Application Development • Traditional Software Applications Env. - Client-server model (non-distributed) - Non-portable - Upgrades were tedious - Failure recovery wasn’t inbuilt - Process defined by experimentation - IT dept. personnel were “revered”

  5. Application Development (contd.) • Modern Software Applications Env. - Distributed Applications - Well defined process - Transparent Upgrades - Portable, clustering, load-balancing - IT “reduced” to commodity – think outsourcing

  6. Distributed Application • Deployment environment consists of more than one server (host, hardware box) • CORBA – Common Object Request Broker Architecture • J2EE – Java-2.0 Enterprise Edition • .NET – sponsored by Microsoft

  7. Software Applications • New Product • New Features (enhancements) to existing system • Migration of existing system (hardware vs software • Product support

  8. SDLC • Software Development Life Cycle • http://www.webopedia.com/TERM/S/SDLC.html • process of developing information systems through investigation, analysis, design, implementation and maintenance

  9. SDLC Phases • Requirements • Analysis • Design • Development • Testing • Deployment

  10. Kick-Off • Identify stakeholders • Ensure Mgmt buy-in - $$$ • Communicate high-level goals of new system • Sign-off on Statement of Work (SOW) • Agree upon time-lines • Cross-team resource allocation • Deliverable: Signed-off SOW and Project plan

  11. Kick-Off (contd.) • Identify product release strategy (phased?) • Identify migration plan from current system to new system (if necessary)

  12. Phased Delivery Feature 1 Feature 2 Feature 3 Common feature

  13. Phased Delivery (contd.) PHASE-2 PHASE-1

  14. Phased Delivery (contd.) PHASE-1 PHASE-2

  15. Phased Delivery (contd.) PHASE-1 PHASE-2

  16. MIGRATION STRATEGY NEW PRODUCT OLD PRODUCT T1 T2 T3 T2-T3: Co-exist period T2: New Product live T3: Old Product retire

  17. REQUIREMENTS • Identify high-level system requirements • Requirements to be categorized based on delivery phase • Involve cross-team resources in requirements gathering • Obtain sign-off from all teams on requirements document • Deliverables: • Signed off Requirements document • Signed off Use-case document

  18. REQUIREMENTS (contd.) • Requirements to include non-business requirements like security, presentation/UI, performance, scalability, redundancy …etc • Requirements to include external system interfaces clearly e.g. the feed from Chase shall be ftp • Requirements to cover migration issues • Avoid TBDs, Open Issues … etc

  19. ANALYSIS • Identify system components and owners • Assign requirements to corresponding components • Identify component level requirements (sub-requirements) • Analysis to include common components like security, presentation, performance …etc • Analysis document to be peer-reviewed • All TBDs/Open Issues to be resolved and/or signed-off • Deliverable: System Analysis Document

  20. DESIGN • Develop overall architecture of the system • Architecture to include all external interfaces (ftp, odbc … etc) • Identify internal interfaces (e.g. between commission and investment modules) • Develop requirements mapping matrix • Design to identify all COTS and dependencies

  21. DESIGN (contd.) • Identify data model • Identify individual modules (commission, receipts …etc) • Identify interface modules (ftp, odbc … etc) • Identify common modules/frameworks (db access, messaging, UI, security … etc)

  22. DOCUMENTATION • Identify list of design documents • High Level Design Documents • Low Level Design Documents • Unit Test Plans • Interface Control Documents • Pair-wise Test Plans • Sub-system Integration Test Plans • System Integration Test Plans • Performance Test Plans

  23. DOCUMENTATION (contd.) • UI Behavior Document • Identify document owners and schedules • Documents to be reviewed formally across teams and comments solicited

  24. DEVELOPMENT • Policies and Procedures • Documentation • Third-party COTS, Licenses, Dependencies • CM procedures • Repository • Development/Testing tools • Identify module owners

  25. DEVELOPMENT (contd.) • Identify development environment(s) • Development Guidelines • Coding standards and policies • Formal code inspection by peers • Resolve inter-module dependencies

  26. TESTING • Identify Test Environment(s) • Test process • Unit Level • Pair-wise • Sub-system • System (including external interfaces – all upstream, downstream and lateral systems) • Identify Test metrics • Develop test drivers where needed to minimize schedule impacts

  27. TESTING (contd.) • Ensure all requirements are met – obtain sign-off on test results • Operational Flows Testing • UI Testing • Performance Testing • Audit/Security Compliance Testing • Fail-over/Contingency Testing • Regression Testing

  28. TESTING (contd.) • Beta Release • Test User Group

  29. DEPLOYMENT • Product rollout plan • Deployment environments – production, contingency … • Run-time licenses, COTS issues

  30. COTS • Commercial Off the Shelf Software • Avoid “vendor-lockin” • Vendor reliability – market share, # of yrs in industry …etc • Support costs/structure (e.g. Gold/Silver/Bronze) • Upgrade costs/roadmap • Licensing structure • development vs runtime • Site license vs user license vs CPU license • Legalese – company sale, bankruptcy …etc

  31. OUTSOURCING • No formal process defined yet • Each company has its own customized process • Areas of concern • Quality • Security • Multi-site development • Ownership issues

  32. Websites • www.webopedia.com • www.acm.org (Association for Computing Machinery) • www.omg.org (Object Management Group) • www.ibm.com  Developers • www.pmi.org • www.howstuffworks.com

  33. Development Tools • Development languages • Editors • Compilers • Debuggers • Testing Tools • Configuration Management Tools

  34. Development Languages • Choice dictated by requirements esp. hardware requirements e.g.main-frame vs PC • Some languages blend well with certain methodologies or architecture e.g. C++ is an Object-oriented language suited for client-server and distributed applications Java is Object-oriented, suited for web applications i.e. applications deployed over the web

  35. EDITORS • IDE – Integrated Development Environment • User friendly, graphical tool to write code in a particular language • Provides syntax high-lighting and checking • Integrated with language compiler, debugger etc • e.g. Turbo-C, Turbo-Pascal • Usually free but some non-free products too • IDEs should not introduce any proprietary code into original source code

  36. COMPILERS • Convert human-readable code to machine-readable instructions • Both open-source and vendor supported • cc – C language compiler, part of Unix • CC – C++ compiler, part of Unix • gcc – GNU version of C/C++ compiler • Provide debuggers to analyze output code

  37. make • Utility for automating large compilations. • Very efficient - eliminates redundant recompilations i.e. compiles only needed modules • Rules are defined (by default) in a file called makefile or Makefile or a separate file can be specified

  38. DEBUGGERS • Utilities to trouble-shoot compiled code • Must be able to execute code in “trace” mode • Must be able to display internal system contents (stack, registers…etc) during program execution • dbx – Sun’s C/C++ debugger • gdb – GNU C/C++ debugger • Debuggers integrated with IDE

  39. TESTING TOOLS • Simulate various external conditions (“boundary” conditions) • Test-cases must align with requirements • Performance testing tools simulate traffic e.g. simultaneous website access WinRunner, LoadRunner from Mercury • Mostly commercial, some open-source (JUnit)

  40. Configuration Mgmt Tools • Manage source code • Different versions of code i.e. version A of code corresponds to version X of product • Multi-user development • Multi-site development • Commercial (IBM’s Clearcase, PVCS, SourceSafe) and open-source products (SCCS, cvs)

  41. RCS – Revision Control System • Maintain all versions of code • Prevent multiple users from changing code simultaneously • “Merge” two changes into a single change • Maintains change logs

  42. http://acelinux.tripod.com File: ace.tar.gz

  43. Sample Application mkdir sampleapp mv ace.tar.gz sampleapp cd sampleapp gunzip ace.tar.gz tar -xvf ace.tar cd ace

  44. Sample Application • Calculator program developed in C language. • The library libmath.a provides all the required arithmetic functions. • All .c files are C source files • makefile is for make utility – contains rules for compilation • Software is built using the make utility

  45. Sample Application • lib – directory contains the “libmath.a” library. • libmath.a contains addition.o, subtraction.o, multiplication.odivision.o modules • To build cd lib make clean make

  46. Sample Application • source – directory contains the main calculator application. • This application uses the libmath.a library • To build: cd ../source make clean make

  47. Sample Application cd ~/ace/source ./calculator

  48. Next Week • Revisiting the | operator • Version Control Demo/Exercise • User Management

More Related