It has been quite awhile since I last posted to this blog, but I have completed the discussion about Software Engineering and will be posting more regularly. After the completion of my software engineering entries, I will be demonstrating real software engineering using XNA 2.0 (a toolkit from Microsoft for Game Programming) that works with VSTS and Team Foundation Server. So with that, here is the beginning of completing my Software engineering discussions. Let me know what you are think of it.
Design in Software Engineering is the process of requirements gathering and guiding the hardware and software team to stay within the constraints of the system environments and to insure that infrastructure elements are correctly implemented. Since in the current development process methodology does not close off the design component, the software engineer would be the archivist, reviewer, and connector between personnel. This is not a program manager or project manager job description, the software engineer would go beyond the project’s immediate effort and include the overall considerations of impact on the infrastructure. The following elements are the basic elements included in the design process. These elements are used in the design of the project, the SEI document title “The Architecture Based Design Method”, could lead to confusion about it’s inclusion in a document about Software Engineering. Like the Civil Engineer when building physical infrastructure, the Civil engineer works with architectures for the overall design, the civil engineer then coordinates the architect, who often represents the customer or end user, with the soils engineer, the general contractor and so forth. This is similar to the software engineer.
General design follows these basic topics, the CMMI/SEI document is an excellent source of guidance on these items (see the related endnote):
- Requirements analysis
- Functional requirements
- Quality requirements
- Environmental Constraints
- Abstract components
- Software templates
- Concrete component design
Software Design considerations[ii]:
Tools are important in the design of today’s complex systems.
- The ability of an application to protect its resources. This includes the hardware systems as well as the software systems. Security should be the most important considerations for all projects, followed by reliability.
- Link to securability
- The process of designing for reliability involves looking at the application's expected usage pattern, specifying the required reliability profile, and engineering the software architecture with the intention of meeting the profile. Reliability engineering requires in-depth consideration of an application's interactions with other system processes.
- Link to reliability
- The process of designing for reliability involves looking at the application's expected usage pattern, specifying the required reliability profile, and engineering the software architecture with the intention of meeting the profile. Reliability engineering requires in-depth consideration of an application's interactions with other system processes. You must take a long, slow look at how a particular service is provided, evaluate failure scenarios, and find preferred design alternatives.
- Link to: scalability
· The measure of an application's operation under load using standardized metrics.
- Link to: performance
- All applications are available at least some of the time, but Web-based applications and mission-critical enterprise applications must typically provide round-the-clock services.
- Link to: availability
- This is the ease of administrating the overall system. As the cost of hardware and software drops, the customer also expects that the cost of administration will drop as well.
- Software maintenance is the highest cost of software, your language needs to be upgradable and the code should be reusable and discoverable. This may seem obvious, as an example during the Y2K (when the clocks switched from 1999 to the year 2000) many software users were concerned that their systems would crash. At one insurance company when they investigated the number of lines code to change over, at an estimated price of $1 per line of code, they first found 3 million lines of code. Once they started the project, they discovered 2 more million lines of code, the corporate executives were not happy about this. What happened? The code had not been maintained well and was running on machines in processes that had not been documented. Infrastructure architects need to be included in the software engineering discipline and need to be able to incorporate the software.
- Decision making process:
- Does the language support automatic documentation tools?
- Are there visualization tools for the all members of the software development team? This includes the Infrastructure team members such as the CIO and server managers.
- Are there project management connections in the software development system?
- Collaboration, can the software team work in a collaborative manner?
- Is there support for future upgrades or new languages that may come in style?
- If is a government support effort does it support the documentation needs of this kind of customer?
- Does it support time reporting by the software team?
- Does the language support automatic documentation tools?
· Link to: manageability
- Link to hands on labs: System design and modeling[ix]
- Link to information on architecture design using Microsoft Visual Studio Team System[x]
- Link to a webcast on Java Interoperability with .NET[xi]
[ix] System modeling: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032302653&EventCategory=3&culture=en-US&CountryCode=US
[x] Link to architecture system design: http://msdn2.microsoft.com/en-us/library/57b85fsc(VS.90).aspx
[xi] Webcast on Java interoperability with .NET: http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032331986&EventCategory=5&culture=en-US&CountryCode=US