B333 IT Project Week 5 Lectures Internet Application Development By H.L. Hiew - My job this week is to talk about the issues and give advice on developing software specifically for the Internet. Assumption - You (or someone in your team) is familiar with software development methodologies such as those taught in B231 Systems Analysis and Design Difference between Standalone, Intranet and Internet Applications - Standalone apps are on a single machine - Intranet and Internet apps are networked - Major difference between is that intranet has a boundary place on it by an organisation. - So there is a boundary on - People - Software - Hardware - Policies - Requirements The Internet (unlike Intranet and standalone apps) has a very low cost of entry - The low cost of entry for users - anyone with ISP connection, and mainly with a web browser, can be a user - Applications are susceptible to fickle demands of users - The low cost of entry for developers - easy service delivery - easy service distribution/discovery - Applications susceptible to immediate competition from other developers - Involves a lot more less experienced developers: users, content creators. - This creates a rapidly changing environment - new perceived "needs", new supplied applications - Implications - CHAOS! Typical Internet application systems - developed by very small project teams, or even individuals - developed for immediate rather than long term needs - value time-to-market rather than quality vs cost trade-off Controlling the Chaos - Strategy 1: Limit the impact by stabilizing the components - eg. specify users MUST have certain browsers. - Strategy 2: Embrace the uncertainty - sacrifice quality for the sake of adaptability and extensibility - focus on the people - respect them to be able to adapt, rather try to protect them from change New software methodologies that embrace change: called Agile (or Light-weight) Methods - Very closely aligned with Rapid Application Development and Prototyping - Many of the development phases are fused into one Misconceptions - Myth: all traditional practices are irrelevant - Myth: "light-weight" methodologies means "no" methodology - Jettison good practice - Instead of adjusting the practices to suit the new environment, many inexperienced developers use the excuse of time and relevance to jettison the practices REQUIREMENTS GATHERING ---------------------- Constraints regarding Users - No access to all users - users defined by software owners (client/customer) - Do owners really know what users want? - If owners probably don't know it all, then first 2 system requirements should be 1) The system can monitor and gather user "needs" and "wants" 2) The system can adapt, or be modified, to what requirement (1) turns up. - Localizations issues when porting software to different locations. - Requirements for help system very important. But perhaps - Intuitive system is better - Idiot-crash-proof system is better Constraints regarding Developers - Many people besides development team could get involved with developing parts of the system, or involved with future modifications of the system. - This impacts on the requirements on deliverables - System descriptions have to cater for a very diverse audience. - Documentation for dummies. - Team building needs to be an integral part of process - Careful team selection (more on attitudes rather than skills) - Mentoring procedures - Conflict resolution very important Managing Volatile Functional Requirements - Involve customer as an integral part of the development process - Don't spend too much time trying to lock down requirements - not realistic - Frequent system delivery for client to try out - Frequent releases for users to try out Unnecessary Functional Requirements - How many requirements are "mandatory"? - Have you ranked your requirements properly? - If I ask you to produce a working software in 1 week, can you decide from your requirements which ones to develop? ANALYSIS -------- Feasibility Analysis - Remember to consider the feasibility AFTER delivery - operational - maintenance - support - Many components controlled by multiple authorities. Is it feasible for your client in the face of these? - Don't know what browsers users use and how they are configured - will this cause a problem in the future? - (Mostly in Unix environment) Common for one web server to be replaced with another - is your application specific to only be operational for one type of web server? - APIs used by scripts can undergo version change. - If application requires external services (eg SOAP services), are these external services likely to be available and reliable going into the future? - Will the support personnel be reliable? It is likely that your clients themselves will be the support personnel. - How much of your application assumes available ISP services? Is it likely to be available and reliable in the future? - In my experience, in the volatile environment such as the Internet: What can go wrong, will go wrong! - Worse-case scenario usually turns out to be the realistic case. - To consider what can go wrong, you cannot do so independent of design, implementation and deployment. That is why traditional Waterfall Model usually doesn't work in this type of project. DESIGN and ARCHITECTURE ----------------------- 3-Tier Web Application - Most common - Browser/Web Script/Database In reality - You have easy access to much more layers without much additional cost of understanding. - Eg - Plug-ins through browsers - can be invoked purely with using specific file types - Web server functionalities (eg. access restrictions) - Security infrastructure - eg client-side or server-side firewalls - make sure you understand what at what level the security infrastructure is operating at, and whether it is appropriate. In Internet applications, you usually have to decide first where things happen - on server - on client - handled by DB Deciding what to control - controlling hyperlinks (browser supports multidirectional web and not unidirectional sequence) - controlling browser options (back buttons, home buttons, pop-up windows) - controlling persistence (data that stays beyond one transaction) Application Outputs - to screen - most obvious - Make outputs persistent? - for - performance - transaction control - Write output to DB to store for future - caching through - browser and proxies - cookies - application-specific - eg. write to local XML file Application Inputs - from user manual entry - most obvious - Make inputs persistent? - for - performance - transaction control - usability (sometimes VERY important) - can't expect users who spent 10 minutes typing in data to redo all the typing if they happened to have typed in one invalid number. - caching through - browser and proxies - cookies - application-specific To design persistence, usually a state transition diagram will be useful. Designing for Performance - Current methodologies doesn't support modeling and designing of performance issues. - Performance issues (eg. how fast an video stream must be delivered) are specified in requirements constraints, but not propagated into design and implementation documents. - No methodologies have a useful way of modeling and describing performance issues - left to the implementors and deployment team to "remember" that requirement constraint. - I suggest you include performance issues in your design and achitecture documentation, even if you have to use plain English to do it. Designing for Maintenance and Support - Many components beyond your control, therefore - Use the KISS principle (Keep It Simple, Stupid) IMPLEMENTATION -------------- Implement for - Adaptability - Extensibility - Re-use - Generally following good programming practice will do - AVOID thinking you and your team are the ONLY relevant developers Following standards (mainly W3C's for most of you) - Benefits - Access to the most diverse user-base - most W3 standards are developed to be as inclusive as possible. - Future-proofing - most standards are backward compatible, and in cases where they are not (eg. XHTML and HTML) they provide mechanisms for handling the situation. - Drawbacks - less flexibility in options of technologies. - standards are usually will not incorporate lastest technologies. Standards - Which standards are safe to follow? - Some standards which are fully specified, and are very stable - eg. HTML4, XML - Some standards which are fully specified, and there are questions how stable they are - eg. SOAP, HTTP authentication - Some standards are under development and everyone KNOWS it is going to change - eg. UDDI, Wireless LAN - Some standards no developer ever really cared very much about - eg. JavaScript - How to tell? Read discussions in development forums, and ASK! TESTING ------- Remember to test for - high load - multiple user access The feasibility of proper testing - Manual testing may not be realistic. - Automated testing is preferable. - Does your team have a programmer who can develop clients and servers to test the application in a large scale? Limited release for user testing - Eg within an intranet, or restricted access by user authentication. Unit testing - Write test code BEFORE writing application code. - Ensures everything you write is immediately tested and correct. - Ensures you write application code specifically for what you need, not some pie-in-the-sky future benefits - eg. programmers have a tendency to build large classes and include methods and members they BELIEVE might be useful, rather than what the requirements and design specifies. - Are your programmers good enough to churn out test code for every few lines of application code? Testing as Requirements Analysis - Rapid development to produce simple prototypes. - Client is a much better position to clarify what they REALLY want. DEPLOYMENT ---------- There are always inconsistencies between development environment and deployment environment - Web server load. - Diversity of users. Problems that usually do not show up until system is deployed - Multiple user issues - multiple copies of the scripts running at once - multiple access to the same resources - Database integrity - Absolute addressing issues. - avoid using names like "localhost" all over your code. - avoid assuming addresses will be the same in the future. - Security - Deployment brings forward a whole set of possibilities for the system to be breached. - Security is a never ending issue. You can never COMPLETELY secure a system. - Traffic and bandwidth problems